Udvikling af de nye Microsoft SQL Server ODBC- og OLEDB-drivere

Nogle af jer ved måske allerede, at Microsoft gik tilbage på deres planlagte udfasning af OLEDB og leverede en ny OLEDB-driver. Det kan dog være en hovedskraber at finde ud af, hvad du skal bruge. Da vi brugte SQL Server Native Client, var det ret nemt - Native Client havde både OLEDB og ODBC sendt i en enkelt DLL-fil, hvilket gjorde installationen nem. Alt hvad du havde for at sikre dig, at du brugte den rigtige version af Native Client.

Med SQL Server nu tilgængelig på Linux, giver det ikke længere mening at distribuere Native Client, da Linux generelt ikke understøtter OLEDB, som hovedsageligt er en kun Windows-teknologi, der hovedsageligt bruges af Microsoft-produkter. Af den grund har Microsoft ikke valgt at kombinere både ODBC og OLEDB til en enkelt DLL. Hvis din applikation indeholder VBA-kode, der bruger både DAO og ADO, skal du installere to forskellige udbydere for at få den nyeste funktion og understøttelse af henholdsvis ODBC og OLEDB.

Navnekonventionen kan være lidt forvirrende, fordi mange mennesker løst vil henvise til forskellige drivere som blot "ODBC-driver" eller "OLEDB-udbyder". Så lad os få navnene på det rene. Vi starter med at identificere de forældede versioner og ser derefter på de aktuelle versioner.

Udgåede versioner

Som standard leveres alle versioner af Windows med to SQL Server-dataadgangsklientbiblioteker forudinstalleret:

Microsoft OLE DB Provider til SQL Server (også kendt som SQLOLEDB)
Microsoft SQL Server ODBC Driver (også kendt som SQLODBC)

Det er meget Det er vigtigt at bemærke, at disse er UDFORDERET . De er rettet mod SQL Server 2000 og mangler nye funktioner introduceret siden. Windows vil ikke send eventuelle nye drivere eller opdater dem via deres Windows Update. Fremover skal du, applikationsudvikleren, levere driverne af passende version til brug med din applikation, i stedet for at stole på dem, der leveres af Windows. Gør IKKE brug dem i din nuværende udvikling.

Nuværende versioner

Med det ude af vejen, lad os se på den korrekte ODBC-driver og OLEDB-udbyder, vi måske vil bruge.

ODBC Driver 17 til SQL Server

I skrivende stund er ODBC Driver 17 til SQL Server den nyeste driver og kan downloades i det medfølgende link. Forbindelsesstrengen ser sådan ud:

ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=myServer;DATABASE=myDatabase;

OLE DB Driver 18 til SQL Server

I skrivende stund er OLEDB-driveren 18 den nyeste driver. Selvom versionen er en højere, svarer funktionssættet til ODBC Driver 17 til SQL Server. Forbindelsesstrengen ser sådan ud:

Provider=MSOLEDBSQL;Server=myServer; Database=myDataBase;

32-bit eller 64-bit?

Et almindeligt spørgsmål, der dukker op, er, om man skal installere 64-bit eller 32-bit versionerne af driveren. Svaret er det samme, uanset hvilke versioner vi diskuterer, og det er altid afhængigt af operativsystemet, ikke kontoret. Derfor, hvis du kører 32-bit Access på 64-bit Windows, vil du derfor gerne installere 64-bit drivere. Dette vil inkludere de 32-bit komponenter, der er nødvendige for, at 32-bit Access kan køre med.

Kan jeg bruge SQL Server Native Client?

Officielt understøttes SQL Server Native Client op til SQL Server 2012. Du kan dog stadig bruge den til at oprette forbindelse til nyere versioner af SQL Server. Der er flere funktioner, der mangler fra Native Client. Som tiden går, vil de blive mere og mere uegnede til dine behov, især med Azure-teknologi. Selvom du muligvis kan fortsætte med at bruge det til dine eksisterende applikationer, opfordrer vi til, at du planlægger nye udviklinger ved hjælp af de separate ODBC- og OLEDB-drivere og migrerer dine eksisterende applikationer, når det er muligt. Du skal migrere, når der er behov for at gøre brug af nye teknologier, der kun understøttes af de nyere drivere (eksempler inkluderer Azure Authentication eller Always Encrypted-funktionen).

Har jeg brug for begge dele?

Kun hvis du bruger både DAO og ADO. Generelt bruger alle formularer og rapporter og Access-forespørgsler altid DAO. Den eneste gang, du måske bruger ADO, er inden for VBA-koden. Så hvis du ikke bruger ADO, kan du slippe afsted med kun ODBC-driveren, og det burde være tilstrækkeligt til dit behov. Det betyder, at når du normalt forbinder dine tabeller, vil du bruge kode svarende til følgende:

Dim db As DAO.Database
Dim tdf As DAO.TableDef

Indstil db =CurrentDb
Indstil tdf =db.CreateTableDef

tdf.Name =“MyRemoteTable”
tdf.SourceTableName =“dbo.MyRemoteTable”
tdf.Connect =“ODBC;DRIVER=ODBC Driver 17 til SQL Server;SERVER=minServer;DATABASE=minDatabase;”

db.TableDefs.Append

Syntaksen, der bruges til tdf.Connect, fungerer for pass-through querydef eller endda for DAO.Workspace.OpenDatabase-metodens Connect-egenskab.

Det er lovligt at åbne ADO-forbindelser ved hjælp af ODBC, men ulempen er, at du ender med at gå gennem flere lag, fordi du ville bruge OLEDB-udbyder til ODBC til at oprette forbindelse til ODBC-driveren 17 til SQL Server. Hvis du alligevel hellere vil bruge ODBC, kan du bruge følgende kode til at bruge ODBC over OLEDB:

Dim con As ADODB.Connection

Set con =New ADODB.Connection
con.ConnectionString =“DRIVER=ODBC Driver 17 for SQL Server;SERVER=myServer;DATABASE=myDatabase;”
con.Open

Det er bedre at undgå det ekstra lag og bruge OLEDB direkte. Du kan bruge denne kode til at få den bedste ydeevne med din ADO-kode:

Dim con As ADODB.Connection

Set con =New ADODB.Connection
con.ConnectionString =“Provider=MSOLEDBSQL;Server=minServer; Database=myDataBase;”
con.Open

Den eneste gang, du faktisk får brug for og bruge den nye OLEDB-driver til SQL Server, er, når du har ADO-kode i din applikation og ønsker at bruge den fulde kapacitet af ADO, som skal aktiveres af den underliggende OLEDB-driver.

Yderligere reference

Køreplan for Microsoft Data Access Technology