Avtrassel de nya Microsoft SQL Server ODBC- och OLEDB-drivrutinerna

Vissa av er kanske redan vet att Microsoft backade på sin planerade utfasning av OLEDB och tillhandahöll en ny OLEDB-drivrutin. Däremot kan det vara svårt att komma på vad du ska använda. När vi använde SQL Server Native Client var det ganska enkelt - Native Client hade både OLEDB och ODBC levererade i en enda DLL-fil, vilket gjorde installationen enkel. Allt du behövde för att se till att du använde rätt version av Native Client.

Med SQL Server nu tillgänglig på Linux, är det inte längre meningsfullt att distribuera Native Client, eftersom Linux i allmänhet inte stöder OLEDB, som huvudsakligen är en Windows-teknologi som huvudsakligen används av Microsoft-produkter. Av den anledningen har Microsoft inte valt att kombinera både ODBC och OLEDB till en enda DLL. Om din applikation innehåller VBA-kod som använder både DAO och ADO, måste du installera två olika leverantörer för att få den senaste funktionen och stöd för både ODBC respektive OLEDB.

Namnkonventionen kan vara lite förvirrande eftersom många människor löst hänvisar till olika drivrutiner som helt enkelt bara "ODBC-drivrutin" eller "OLEDB-leverantör". Så låt oss ta reda på namnen. Vi börjar med att identifiera de föråldrade versionerna och tittar sedan på de aktuella versionerna.

Utfasade versioner

Som standard kommer alla versioner av Windows med två SQL Server-dataåtkomstklientbibliotek förinstallerade:

Microsoft OLE DB Provider för SQL Server (även känd som SQLOLEDB)
Microsoft SQL Server ODBC-drivrutin (även känd som SQLODBC)

Det är mycket Det är viktigt att notera att de är UTFASNADE . De är inriktade på SQL Server 2000 och saknar nya funktioner som introducerats sedan dess. Windows kommer inte skicka alla nya drivrutiner eller uppdatera dem via dess Windows Update. Framöver måste du, applikationsutvecklaren, tillhandahålla drivrutinerna för lämplig version att använda med din applikation, snarare än att förlita dig på de som tillhandahålls av Windows. Gör INTE använd dem i din nuvarande utveckling.

Aktuella versioner

Med det ur vägen, låt oss titta på rätt ODBC-drivrutin och OLEDB-leverantör som vi kanske vill använda.

ODBC-drivrutin 17 för SQL Server

I skrivande stund är ODBC Driver 17 för SQL Server den senaste drivrutinen och kan laddas ner i den medföljande länken. Anslutningssträngen ser ut så här:

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

OLE DB-drivrutin 18 för SQL Server

I skrivande stund är OLEDB-drivrutinen 18 den senaste drivrutinen. Även om versionen är en högre, är funktionsuppsättningen likvärdig med ODBC Driver 17 för SQL Server. Anslutningssträngen ser ut så här:

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

32-bitars eller 64-bitars?

En vanlig fråga som dyker upp är om man ska installera 64-bitars eller 32-bitarsversionerna av drivrutinen. Svaret är detsamma oavsett vilka versioner vi diskuterar och det är alltid beroende av operativsystemet, inte kontoret. Därför, om du kör 32-bitars Access på 64-bitars Windows, skulle du vilja installera 64-bitars drivrutiner. Detta kommer att inkludera de 32-bitars komponenter som behövs för att 32-bitars Access ska köras med.

Kan jag använda SQL Server Native Client?

Officiellt stöds SQL Server Native Client upp till SQL Server 2012. Du kan dock fortfarande använda den för att ansluta till nyare versioner av SQL Server. Det finns flera funktioner som saknas i Native Client. Allt eftersom tiden går kommer de att bli allt mer olämpliga för dina behov, särskilt med Azure-teknik. Även om du kanske kan fortsätta använda det för dina befintliga applikationer, rekommenderar vi att du planerar nya utvecklingar med hjälp av de separata ODBC- och OLEDB-drivrutinerna och migrerar dina befintliga applikationer när det är möjligt. Du måste migrera när det finns ett behov av att använda ny teknik som endast stöds av de nyare drivrutinerna (exempel inkluderar Azure Authentication eller Always Encrypted-funktionen).

Behöver jag båda?

Endast om du använder både DAO och ADO. Generellt sett använder alla formulär och rapporter och Access-frågor alltid DAO. Den enda gången du kan använda ADO är inom VBA-koden. Så om du inte använder ADO kan du komma undan med bara ODBC-drivrutinen och det borde räcka för ditt behov. Det betyder att när du normalt länkar dina tabeller, använder du kod som liknar följande:

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

Set db =CurrentDb
Set tdf =db.CreateTableDef

tdf.Name =“MyRemoteTable”
tdf.SourceTableName =“dbo.MyRemoteTable”
tdf.Connect =“ODBC;DRIVER=ODBC-drivrutin 17 för SQL Server;SERVER=minServer;DATABASE=mindatabas;”

db.TableDefs.Append

Syntaxen som används för tdf.Connect fungerar för pass-through querydef eller till och med för DAO.Workspace.OpenDatabase-metodens Connect-egenskap.

Det är lagligt att öppna ADO-anslutningar med ODBC men nackdelen är att du till slut går igenom fler lager eftersom du skulle använda OLEDB-leverantör för ODBC för att ansluta till ODBC-drivrutinen 17 för SQL Server. Om du ändå hellre vill använda ODBC, kan du använda följande kod för att använda ODBC över 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 är bättre att undvika det extra lagret och använda OLEDB direkt. Du kan använda den här koden för att få bästa prestanda med din ADO-kod:

Dim con As ADODB.Connection

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

Den enda gången du faktiskt behöver och använder den nya OLEDB-drivrutinen för SQL Server är alltså när du har ADO-kod i din applikation och vill använda den fulla kapaciteten hos ADO, som måste aktiveras av den underliggande OLEDB-drivrutinen.

Ytterligare referens

Färdkarta för Microsoft Data Access Technology