SQL Server Native Client

SQL Server Native Client to wycofywany sterownik dostępu do bazy, zastępowany przez ODBC i OLE DB.

SQL Server Native Client — czym jest i do czego służył

SQL Server Native Client, często skracany do SNAC, był pakietem składników programistycznych przeznaczonych do komunikacji aplikacji z bazami danych Microsoft SQL Server. Łączył w sobie sterownik ODBC oraz dostawcę OLE DB, dzięki czemu jedna instalacja mogła obsługiwać różne sposoby nawiązywania połączeń. Rozwiązanie stosowano między innymi w aplikacjach napisanych w językach korzystających z interfejsów Windows Data Access, w narzędziach administracyjnych, systemach obiegu dokumentów, programach magazynowych i aplikacjach tworzonych dla środowiska Windows.

W praktyce SQL Server Native Client nie był bazą danych ani osobnym programem do zarządzania tabelami. Stanowił warstwę komunikacyjną pomiędzy aplikacją a instancją SQL Server. Odpowiadał za otwarcie połączenia, uwierzytelnienie, przesyłanie zapytań, odbieranie wyników oraz obsługę części funkcji charakterystycznych dla produktów Microsoft. W zależności od użytego interfejsu aplikacja mogła korzystać z obiektów OLE DB albo z klasycznych połączeń ODBC.

Znaczenie tego komponentu wynikało także z tego, że przez pewien czas udostępniał funkcje niedostępne w starszych, ogólnych sterownikach. Dotyczyło to między innymi obsługi typów danych, szyfrowania połączenia, parametrów specyficznych dla SQL Server oraz mechanizmów związanych z nowszymi wersjami bazy. Z biegiem czasu rozwój SNAC został jednak zakończony, a w nowych wdrożeniach zaleca się używanie aktualnych sterowników Microsoft ODBC Driver for SQL Server lub współczesnych dostawców OLE DB.

SQL Server Native Client a ODBC, OLE DB i nowsze sterowniki

Porównując SQL Server Native Client z nowszymi rozwiązaniami, należy rozdzielić sam interfejs komunikacyjny od konkretnego sterownika. ODBC jest standardem dostępu do danych, który pozwala aplikacjom używać jednolitego modelu połączenia z różnymi bazami. Sterownik Microsoft ODBC Driver for SQL Server realizuje ten standard i jest obecnie rozwijany niezależnie od SNAC. OLE DB jest innym modelem dostępu, opartym na dostawcach danych i obiektach COM. W przypadku nowych aplikacji można używać aktualnego dostawcy Microsoft OLE DB Driver for SQL Server.

SNAC bywa mylony z nazwą biblioteki dostarczanej razem z konkretną wersją SQL Server. Jest to o tyle istotne, że instalacja składników wraz z jedną wersją programu nie zawsze oznacza pełną zgodność ze wszystkimi aplikacjami. Program może wymagać określonej nazwy sterownika, konkretnej biblioteki DLL, właściwego dostawcy OLE DB albo odpowiedniego wpisu w konfiguracji systemu. Sam fakt, że w komputerze znajduje się nowszy sterownik ODBC, nie gwarantuje, że starsza aplikacja zacznie go automatycznie wykorzystywać.

Różnice dotyczą również architektury aplikacji. Program 32-bitowy potrzebuje właściwego sterownika 32-bitowego, nawet jeśli system Windows jest 64-bitowy. Program 64-bitowy wymaga natomiast komponentu zgodnego ze swoją architekturą. W systemie mogą więc występować równolegle dwa menedżery źródeł danych ODBC. Uruchomienie niewłaściwego narzędzia konfiguracyjnego może sprawić wrażenie, że wcześniej utworzone źródło danych zniknęło, choć w rzeczywistości zostało zapisane dla innej architektury.

Przy modernizacji aplikacji warto sprawdzić, czy możliwa jest zmiana samego ciągu połączenia oraz biblioteki dostępu do danych. Czasami wystarczy zastąpienie nazwy starego sterownika nazwą aktualnego sterownika ODBC. W innych przypadkach konieczna jest modyfikacja kodu, szczególnie gdy aplikacja odwołuje się do specyficznych właściwości SNAC, przestarzałych nazw dostawców lub zachowania, którego nie gwarantują nowsze komponenty.

SQL Server Native Client — typowe problemy z połączeniem

Jednym z najczęstszych problemów jest komunikat o braku sterownika, dostawcy albo biblioteki. Taka sytuacja może pojawić się po reinstalacji systemu, migracji programu na inny komputer, aktualizacji aplikacji lub usunięciu starszych składników. Program może wtedy uruchamiać się prawidłowo, ale nie otwierać danych, wyświetlać błąd inicjalizacji albo zatrzymywać się przy ekranie logowania.

Inną przyczyną jest niezgodność 32-bitowej i 64-bitowej wersji komponentu. Objawem bywa możliwość skonfigurowania połączenia w jednym narzędziu, lecz brak połączenia w samej aplikacji. Weryfikacja powinna obejmować architekturę programu, wersję sterownika, nazwę źródła danych oraz miejsce zapisania konfiguracji. Należy również sprawdzić, czy aplikacja korzysta z DSN, czy z bezpośredniego ciągu połączenia.

Problemy mogą dotyczyć także uwierzytelniania. Połączenie skonfigurowane dla logowania systemowego może nie działać w sytuacji, gdy program uruchamiany jest z innym kontem użytkownika. Z kolei logowanie za pomocą loginu i hasła może zostać odrzucone z powodu nieprawidłowych danych, wyłączonego trybu uwierzytelniania albo ograniczeń ustawionych po stronie bazy. Nie powinno się bez potrzeby kopiować haseł do plików konfiguracyjnych ani umieszczać ich w publicznie dostępnych skryptach.

Dość częste są również błędy certyfikatów i szyfrowania. Nowsze sterowniki mogą domyślnie wymagać bezpieczniejszego sposobu negocjowania połączenia niż starszy SNAC. W efekcie aplikacja, która przez wiele lat działała bez zmian, po wymianie komponentu może zgłosić problem z zaufaniem do certyfikatu lub z negocjacją protokołu. W takim przypadku trzeba ustalić, czy problem wynika z certyfikatu, daty systemowej, magazynu zaufanych urzędów, ustawień szyfrowania, czy z niezgodności starego programu z aktualnymi zasadami bezpieczeństwa.

Nie każdy błąd oznacza uszkodzenie bazy. Komunikaty o przekroczeniu czasu oczekiwania mogą wskazywać na niedostępność sieci, błędną nazwę instancji, zaporę blokującą port, nieaktywną usługę albo opóźnienia w działaniu samej aplikacji. Warto odróżnić błąd warstwy połączenia od błędu zapytania. Jeżeli program nawiązuje połączenie, lecz nie może pobrać konkretnego zestawu danych, przyczyna może znajdować się w uprawnieniach, strukturze tabel lub logice programu.

SQL Server Native Client — praktyczne wskazówki diagnostyczne

Diagnozę najlepiej rozpocząć od zebrania dokładnego komunikatu, nazwy programu i informacji o momencie wystąpienia problemu. Znaczenie ma to, czy błąd pojawia się podczas uruchamiania, przy logowaniu użytkownika, przy zapisie dokumentu, czy dopiero przy wykonywaniu określonej operacji. Warto zanotować, czy przed awarią zmieniono system, hasło, konfigurację sieci, certyfikat lub wersję aplikacji.

Następnie należy sprawdzić, jakie sterowniki są faktycznie zainstalowane. W systemie Windows można przejrzeć listę sterowników ODBC dla właściwej architektury oraz zweryfikować, czy aplikacja odwołuje się do nazwy znajdującej się w konfiguracji. Przy połączeniach OLE DB trzeba ustalić, jakiego identyfikatora dostawcy używa program. Sama obecność pliku DLL na dysku nie potwierdza poprawnej rejestracji ani zgodności z aplikacją.

Pomocne jest wykonanie kontrolnego połączenia z użyciem tej samej nazwy hosta, instancji, bazy i metody logowania, które wykorzystuje program. Test powinien być przeprowadzony na tym samym komputerze i z konta mającego podobne uprawnienia. Jeżeli połączenie testowe działa, a aplikacja nadal zgłasza błąd, podejrzenie pada na jej konfigurację, bibliotekę używaną w kodzie albo sposób przekazywania parametrów.

Przy przechodzeniu z SQL Server Native Client na aktualny sterownik należy wykonać kopię konfiguracji i zaplanować testy przed zmianą na komputerach używanych do pracy. Nie powinno się usuwać starego składnika bez sprawdzenia, czy korzystają z niego inne programy. Dobrą praktyką jest spisanie dotychczasowej nazwy sterownika, typu uwierzytelniania, ustawień szyfrowania oraz sposobu wskazywania instancji. Ułatwia to odtworzenie konfiguracji, jeśli modernizacja wymaga dodatkowych zmian.

Ważne jest również rozdzielenie problemu z aplikacją od problemu z systemem. Aktualizacja sterownika nie naprawi uszkodzonego profilu użytkownika, błędnego wpisu w zmiennej środowiskowej, niesprawnej karty sieciowej ani konfliktu zapory. Z kolei przywrócenie starego komponentu może tylko odsunąć konieczność modernizacji i pozostawić aplikację zależną od nieaktualnego rozwiązania.

Kiedy zgłosić SQL Server Native Client do serwisu

Do serwisu warto zgłosić się wtedy, gdy aplikacja przestała łączyć się z bazą po aktualizacji systemu, wymianie komputera, zmianie ustawień sieciowych albo instalacji innego programu. Pomoc może być potrzebna również wtedy, gdy kilka aplikacji korzysta z różnych sterowników, występuje konflikt architektur 32-bit i 64-bit, pojawiają się błędy certyfikatów lub nie wiadomo, czy można bezpiecznie zastąpić SNAC nowszym komponentem.

Przed przekazaniem urządzenia warto przygotować nazwę aplikacji, wersję systemu, treść komunikatu oraz informację, czy problem dotyczy wszystkich użytkowników. Jeżeli baza znajduje się poza komputerem, przydatne są także dane dotyczące sposobu połączenia, bez ujawniania haseł. Takie informacje skracają rozpoznanie i ułatwiają odtworzenie warunków występowania błędu.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się rozpoznawaniem problemów z komputerami, aplikacjami i konfiguracją dostępu do danych, w tym z przypadkami, w których starszy komponent SQL Server Native Client koliduje z aktualnym środowiskiem Windows. W sytuacji, gdy połączenie nie działa, a samodzielna zmiana sterownika mogłaby przerwać pracę programu, bezpieczniej jest najpierw ustalić zależności i dopiero potem wykonać modernizację.

W wielu przypadkach przywrócenie działania nie wymaga ingerencji w dane. Możliwe jest sprawdzenie konfiguracji, dopasowanie właściwego sterownika, korekta ciągu połączenia, rozdzielenie ustawień dla różnych architektur albo przygotowanie planu przejścia na aktualne rozwiązanie. Jeżeli aplikacja jest bardzo stara i nie ma już wsparcia producenta, należy dodatkowo ocenić ryzyko pozostawienia przestarzałego komponentu oraz zaplanować stopniową zmianę oprogramowania.