SQL Server API

SQL Server API to zbiorcze określenie interfejsów programistycznych, w tym ADO.NET i ODBC, do łączenia się z bazą.

SQL Server API jako warstwa komunikacji z bazą

SQL Server API to zbiorcze określenie interfejsów programistycznych, za pomocą których aplikacja nawiązuje połączenie z aparatem Microsoft SQL Server, uwierzytelnia użytkownika, wysyła instrukcje Transact-SQL oraz odbiera wyniki. Nie jest to jedna, odrębna biblioteka ani pojedynczy protokół. W praktyce nazwa obejmuje między innymi ADO.NET, ODBC, OLE DB oraz sterowniki używane przez konkretne języki programowania i środowiska uruchomieniowe. Interfejs API określa sposób wywoływania operacji z poziomu kodu, natomiast komunikacja z serwerem odbywa się za pośrednictwem mechanizmów klienta SQL Server.

Program korzystający z takiego interfejsu nie musi znać wewnętrznej implementacji silnika bazy danych. Otrzymuje obiekty reprezentujące połączenie, polecenie, transakcję i wynik zapytania. Kod może więc otworzyć sesję, ustawić parametry, wykonać zapytanie i odczytać wiersze bez bezpośredniego zarządzania pakietami sieciowymi. SQL Server API nie zastępuje jednak języka Transact-SQL. API dostarcza transportu i modelu obsługi żądań, a instrukcje SQL określają, jakie dane mają zostać odczytane lub zmodyfikowane.

ADO.NET, ODBC i dobór sterownika

ADO.NET jest interfejsem używanym przede wszystkim w aplikacjach platformy .NET. Dla SQL Server typowym dostawcą jest Microsoft.Data.SqlClient, a starsze aplikacje mogą korzystać z System.Data.SqlClient. Oba dostawcy udostępniają obiekty takie jak SqlConnection, SqlCommand, SqlDataReader i SqlTransaction. SqlConnection opisuje sesję z bazą, SqlCommand wykonuje instrukcję lub procedurę składowaną, SqlDataReader pozwala odczytywać wynik w trybie strumieniowym, a SqlTransaction grupuje operacje w transakcję. W nowym kodzie istotne jest sprawdzenie, którego dostawcy wymaga dana wersja aplikacji, ponieważ nie są to identyczne pakiety i nie należy bezrefleksyjnie zamieniać ich nazw.

ODBC jest ustandaryzowanym interfejsem dostępu do danych, który oddziela aplikację od konkretnego dostawcy bazy przez sterownik ODBC. W przypadku SQL Server sterownik tłumaczy wywołania ODBC na komunikację z aparatem SQL Server. Aplikacja może używać funkcji ODBC bezpośrednio albo korzystać z biblioteki języka, która zapewnia wyższą warstwę abstrakcji. Połączenie ODBC jest zwykle opisywane przez parametry sterownika, serwera, bazy, trybu uwierzytelniania i szyfrowania. Niezgodna wersja sterownika, brak sterownika w systemie lub błędna nazwa źródła danych może uniemożliwić nawiązanie sesji, zanim serwer otrzyma właściwe zapytanie.

Sesja, parametry i transakcje w praktyce

Poprawna obsługa SQL Server API wymaga rozdzielenia kilku etapów: utworzenia konfiguracji połączenia, otwarcia sesji, przygotowania polecenia, przekazania parametrów, wykonania operacji oraz zamknięcia zasobów. Parametry zapytania powinny być przekazywane jako parametry API, a nie przez sklejanie wartości z tekstem SQL. Dzięki temu sterownik zna typ danych i może przekazać wartość niezależnie od składni tekstowej polecenia. Ogranicza to ryzyko błędnej interpretacji apostrofów, formatów dat i znaków specjalnych, a także zapobiega klasycznym błędom wynikającym z wstrzykiwania kodu SQL.

Transakcja definiuje granicę, w której kilka operacji ma zostać zatwierdzonych albo wycofanych jako całość. W ADO.NET można rozpocząć ją na obiekcie połączenia, wykonać polecenia z przypisaną transakcją, a następnie wywołać zatwierdzenie lub wycofanie. Jeżeli aplikacja otwiera transakcję i nie kończy jej w każdej ścieżce obsługi błędu, sesja może utrzymywać blokady dłużej, niż zakładano. Równie ważne jest zamykanie czytników, poleceń i połączeń. W wielu bibliotekach połączenie jest zwracane do puli po zamknięciu, dlatego brak zwolnienia zasobu może doprowadzić do wyczerpania puli i pozornych błędów połączeń przy większej liczbie równoległych żądań.

API przekazuje także informacje o błędach zwracanych przez sterownik lub SQL Server. Należy odróżnić błąd uwierzytelnienia, błąd sieciowy, przekroczenie limitu czasu, błąd składni Transact-SQL, naruszenie ograniczenia oraz deadlock. Każda z tych sytuacji wymaga innej analizy. Sam komunikat „nie można połączyć z bazą” nie wskazuje jeszcze, czy problem dotyczy adresu serwera, portu, certyfikatu, konta, uprawnień, dostępności instancji czy treści zapytania.

Diagnostyka problemów z połączeniem SQL Server

Diagnostykę należy rozpocząć od ustalenia, z jakiego API i sterownika korzysta aplikacja, jaki jest dokładny ciąg połączenia oraz czy problem występuje podczas otwierania sesji, wykonywania polecenia czy odczytu wyniku. Następnie można sprawdzić rozwiązywanie nazwy hosta, osiągalność usługi SQL Server, konfigurację instancji, ustawienia szyfrowania i sposób uwierzytelniania. W przypadku ODBC trzeba dodatkowo potwierdzić, że sterownik jest zainstalowany w tej samej architekturze co aplikacja, ponieważ aplikacja 32-bitowa i 64-bitowa mogą korzystać z odrębnych konfiguracji sterowników.

Jeżeli połączenie jest ustanawiane, ale zapytanie działa nieprawidłowo, analiza powinna objąć typy parametrów, kodowanie znaków, uprawnienia konta, zakres transakcji oraz sposób konsumowania wyników. Problemy z wydajnością mogą wynikać z pobierania zbyt dużego zestawu danych, braku stronicowania, zbyt długiego utrzymywania czytnika albo nieprawidłowego czasu oczekiwania. Przy błędach przerywanych warto zapisać kod błędu, pełny komunikat, etap operacji i czas wystąpienia, zachowując ostrożność, aby nie utrwalać haseł ani pełnych danych uwierzytelniających w logach. Diagnostyka sprzętu używanego do uruchamiania aplikacji może obejmować pamięć, nośnik danych, system operacyjny i sterowniki, ponieważ awarie tych elementów również potrafią objawiać się niestabilnością programu korzystającego z SQL Server API.