Wersje sterowników ODBC

Wersje sterowników ODBC wpływają na obsługiwane funkcje uwierzytelniania i typy danych podczas połączenia.

Rola wersji sterownika ODBC w połączeniu z bazą danych

ODBC, czyli Open Database Connectivity, jest standardowym interfejsem programistycznym umożliwiającym aplikacji korzystanie z baz danych za pośrednictwem sterownika dostawcy. Program nie komunikuje się bezpośrednio z konkretnym silnikiem bazy, lecz wywołuje funkcje ODBC, a sterownik tłumaczy je na protokół właściwy dla danego systemu. Wersja sterownika określa między innymi, jakie funkcje interfejsu są dostępne, jakie opcje połączenia można ustawić oraz w jaki sposób przekazywane są teksty, liczby, daty i wartości binarne.

Trzeba rozróżnić wersję samego standardu ODBC, wersję Driver Managera oraz wersję konkretnego sterownika dostarczonego przez producenta bazy lub aplikacji. Sterownik ODBC 3.x może obsługiwać interfejs ODBC 3.x, ale jego faktyczne możliwości zależą również od silnika bazy danych, biblioteki klienckiej i konfiguracji połączenia. Aktualizacja sterownika nie zmienia automatycznie struktury tabel ani zapytań, może jednak zmienić sposób negocjowania uwierzytelniania, kodowania znaków, szyfrowania i konwersji typów danych.

ODBC 2.x, ODBC 3.x i zgodność wywołań aplikacji

Współczesne aplikacje najczęściej korzystają z interfejsu ODBC 3.x. W tej rodzinie znajdują się między innymi uchwyty środowiska, połączenia, instrukcji i deskryptora, a komunikacja z Driver Managerem odbywa się przez funkcje takie jak SQLAllocHandle, SQLConnect lub SQLDriverConnect, SQLPrepare, SQLExecute oraz SQLFetch. Starszy interfejs ODBC 2.x wykorzystywał między innymi funkcję SQLAllocEnv, dlatego aplikacja lub warstwa kompatybilności może wymagać sterownika poprawnie obsługującego mapowanie starszych wywołań na nowszy model uchwytów.

Wersja interfejsu nie jest równoznaczna z wersją protokołu sieciowego ani wersją serwera bazy danych. Aplikacja może używać ODBC 3.x, a sterownik może łączyć się z określonym silnikiem przez jego własny protokół klient-serwer. O zgodności decyduje zestaw kilku elementów: aplikacja, Driver Manager, sterownik, biblioteka klienta oraz serwer. Błąd pojawia się na przykład wtedy, gdy aplikacja żąda atrybutu połączenia niedostępnego w danym sterowniku albo przekazuje typ danych, którego sterownik nie potrafi poprawnie zamienić na typ obsługiwany przez bazę.

Uwierzytelnianie, Unicode i typy danych zależne od sterownika

Nowsze wydania sterowników mogą obsługiwać metody uwierzytelniania wymagające dodatkowych bibliotek, określonych parametrów połączenia albo negocjacji szyfrowanego kanału. Sam fakt zainstalowania nowszej wersji nie gwarantuje jednak sukcesu: metoda musi być dostępna po stronie serwera, a konto użytkownika musi mieć odpowiednie uprawnienia. W konfiguracji warto odróżnić nazwę sterownika widoczną w systemie od nazwy sterownika używanej w łańcuchu połączenia, ponieważ literówka lub wskazanie nieistniejącego wariantu często kończy się komunikatem o braku źródła danych albo niemożności załadowania sterownika.

Istotna jest także obsługa znaków Unicode. Aplikacje korzystające z funkcji szerokoznakowych, takich jak SQLDriverConnectW czy SQLPrepareW, potrzebują sterownika i Driver Managera, które prawidłowo obsługują wersję Unicode używaną przez system. Różnice między wydaniami mogą dotyczyć również mapowania typów SQL_CHAR, SQL_WCHAR, SQL_DECIMAL, SQL_TYPE_DATE, SQL_TYPE_TIMESTAMP, typów dużych obiektów oraz danych binarnych. Nieprawidłowe mapowanie może skutkować obcięciem tekstu, zmianą precyzji liczby, błędną strefą czasu albo odrzuceniem parametru zapytania.

Rozpoznawanie wersji i bezpieczna weryfikacja konfiguracji

W systemie Windows zainstalowane sterowniki można sprawdzać za pomocą narzędzia Administrator źródeł danych ODBC, uruchamianego odpowiednio jako odbcad32.exe. W systemie 64-bitowym istnieją osobne narzędzia dla aplikacji 64-bitowych i 32-bitowych, dlatego lista sterowników może różnić się zależnie od użytej wersji programu. Aplikacja 32-bitowa nie korzysta bezpośrednio z 64-bitowego sterownika przeznaczonego dla innego procesu, nawet jeśli oba sterowniki mają podobną nazwę.

Weryfikacja powinna obejmować nazwę i wersję sterownika, architekturę aplikacji, nazwę źródła danych DSN lub pełny łańcuch połączenia, obecność wymaganych bibliotek oraz wynik testu połączenia. W kodzie można odczytywać informacje zwracane przez sterownik, między innymi za pomocą SQLGetInfo, a po błędzie analizować kody SQLSTATE oraz komunikaty diagnostyczne funkcją SQLGetDiagRec. Przy zmianie wersji należy sprawdzić przygotowane zapytania, parametry, kodowanie znaków i sposób obsługi transakcji, ponieważ zgodność podstawowego logowania nie oznacza zgodności całej aplikacji. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, w tym diagnozowaniem problemów z oprogramowaniem, sterownikami oraz konfiguracją urządzeń.