Rozwiązywanie nowych sterowników ODBC i OLEDB Microsoft SQL Server

Niektórzy z was mogą już wiedzieć, że Microsoft wycofał się z planowanego wycofania OLEDB i udostępnił nowy sterownik OLEDB. Jednak zastanawianie się, czego powinieneś używać, może być trudne. Kiedy używaliśmy SQL Server Native Client, było to całkiem proste — Native Client miał zarówno OLEDB, jak i ODBC dostarczane w jednym pliku DLL, co ułatwiało instalację. Musisz tylko upewnić się, że używasz odpowiedniej wersji klienta natywnego.

Ponieważ SQL Server jest teraz dostępny w systemie Linux, dystrybucja klienta natywnego nie ma już sensu, ponieważ Linux ogólnie nie obsługuje OLEDB, która jest głównie technologią tylko dla systemu Windows, używaną głównie przez produkty firmy Microsoft. Z tego powodu firma Microsoft nie zdecydowała się na połączenie ODBC i OLEDB w jedną bibliotekę DLL. Jeśli Twoja aplikacja zawiera kod VBA, który używa zarówno DAO, jak i ADO, musisz zainstalować dwa różnych dostawców, aby uzyskać najnowszą funkcję i wsparcie odpowiednio dla ODBC i OLEDB.

Konwencja nazewnictwa może być nieco myląca, ponieważ wiele osób luźno odnosi się do różnych sterowników jako po prostu „sterownik ODBC” lub „dostawca OLEDB”. Więc wyjaśnijmy nazwy. Zaczniemy od zidentyfikowania przestarzałych wersji, a następnie przyjrzymy się bieżącym.

Przestarzałe wersje

Domyślnie wszystkie wersje systemu Windows są dostarczane z dwiema preinstalowanymi bibliotekami klienckimi dostępu do danych SQL Server:

Dostawca Microsoft OLE DB dla SQL Server (znany również jako SQLOLEDB)
Sterownik ODBC Microsoft SQL Server (znany również jako SQLODBC)

Jest bardzo należy pamiętać, że są one WYCOFANE . Są one skierowane do SQL Server 2000 i nie mają od tego czasu nowych funkcji. Windows nie wyślij nowe sterowniki lub zaktualizuj je za pośrednictwem witryny Windows Update. W przyszłości twórca aplikacji musi dostarczyć sterowniki odpowiedniej wersji do użycia z aplikacją, zamiast polegać na sterownikach dostarczonych przez system Windows. NIE wykorzystaj je w swoim obecnym rozwoju.

Aktualne wersje

Pomijając to, spójrzmy na właściwy sterownik ODBC i dostawcę OLEDB, którego możemy chcieć użyć.

Sterownik ODBC 17 dla serwera SQL

W chwili pisania tego tekstu sterownik ODBC 17 dla programu SQL Server jest najnowszym sterownikiem i można go pobrać pod podanym łączem. Ciąg połączenia wygląda tak:

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

Sterownik OLE DB 18 dla SQL Server

W chwili pisania tego tekstu sterownik OLEDB 18 jest najnowszym sterownikiem. Mimo że wersja jest o jeden wyższa, zestaw funkcji jest odpowiednikiem sterownika ODBC 17 dla programu SQL Server. Ciąg połączenia wygląda tak:

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

32-bitowy czy 64-bitowy?

Często pojawia się pytanie, czy należy zainstalować 64-bitową czy 32-bitową wersję sterownika. Odpowiedź jest taka sama bez względu na to, o których wersjach rozmawiamy i zawsze zależy to od systemu operacyjnego, a nie od pakietu Office. Dlatego jeśli używasz 32-bitowego programu Access w 64-bitowym systemie Windows, warto zainstalować 64-bitowe sterowniki. Obejmuje to 32-bitowe komponenty potrzebne do uruchomienia 32-bitowego programu Access.

Czy mogę używać SQL Server Native Client?

Oficjalnie SQL Server Native Client jest obsługiwany do SQL Server 2012. Jednak nadal można go używać do łączenia się z nowszymi wersjami SQL Server. W kliencie natywnym brakuje kilku funkcji. W miarę upływu czasu będą one coraz bardziej nieprzystosowane do Twoich potrzeb, zwłaszcza w przypadku technologii Azure. Chociaż możesz nadal używać go w istniejących aplikacjach, zachęcamy do planowania nowych rozwiązań przy użyciu oddzielnych sterowników ODBC i OLEDB oraz do migracji istniejących aplikacji, gdy jest to możliwe. Musisz przeprowadzić migrację, gdy istnieje potrzeba skorzystania z nowych technologii, które są obsługiwane tylko przez te nowsze sterowniki (przykłady obejmują funkcję Azure Authentication lub Always Encrypted).

Czy potrzebuję obu?

Tylko jeśli używasz zarówno DAO, jak i ADO. Ogólnie rzecz biorąc, wszystkie formularze i raporty oraz zapytania programu Access zawsze korzystają z DAO. Jedyny czas, w którym możesz użyć ADO, znajduje się w kodzie VBA. Więc jeśli nie używasz ADO, możesz uciec tylko ze sterownikiem ODBC i to powinno wystarczyć dla twoich potrzeb. Oznacza to, że kiedy zwykle łączysz swoje tabele, użyjesz kodu podobnego do następującego:

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

Ustaw db =CurrentDb
Ustaw tdf =db.CreateTableDef

tdf.Name =“MyRemoteTable”
tdf.SourceTableName =“dbo.MyRemoteTable”
tdf.Connect =“ODBC;DRIVER=ODBC Driver 17 dla SQL Server;SERVER=myServer;DATABASE=myDatabase;”

db.TableDefs.Append

Składnia użyta dla tdf.Connect działa dla tranzytowego querydef, a nawet dla właściwości Connect metody DAO.Workspace.OpenDatabase.

Otwieranie połączeń ADO za pomocą ODBC jest legalne, ale wadą jest to, że przechodzisz przez więcej warstw, ponieważ używasz dostawcy OLEDB dla ODBC, aby połączyć się ze sterownikiem ODBC 17 dla SQL Server. Jeśli mimo wszystko wolisz używać ODBC, możesz użyć następującego kodu, aby używać ODBC przez OLEDB:

Dim con As ADODB.Connection

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

Lepiej unikać dodatkowej warstwy i używać bezpośrednio OLEDB. Możesz użyć tego kodu, aby uzyskać najlepszą wydajność z kodem ADO:

Dim con As ADODB.Connection

Set con =New ADODB.Connection
con.ConnectionString =„Dostawca=MSOLEDBSQL;Server=mójSerwer; Database=myDataBase;”
con.Open

Tak więc jedyny moment, w którym faktycznie będziesz potrzebować i używać nowego sterownika OLEDB dla SQL Server, jest wtedy, gdy masz kod ADO w swojej aplikacji i chcesz korzystać z pełnych możliwości ADO, które muszą być włączone przez podstawowy sterownik OLEDB.

Dodatkowe informacje

Mapa drogowa technologii dostępu do danych firmy Microsoft