API zapytań T-SQL

API zapytań T-SQL to interfejs umożliwiający programowe wykonywanie i zarządzanie poleceniami w tym dialekcie języka SQL.

Rola API w wykonywaniu zapytań T-SQL

API zapytań T-SQL to warstwa programistyczna, która pozwala aplikacji nawiązać połączenie z aparatem Microsoft SQL Server, przesłać instrukcję napisaną w języku Transact-SQL oraz odebrać wynik jej wykonania. Sam T-SQL nie jest interfejsem komunikacyjnym. Jest rozszerzeniem języka SQL używanym przez SQL Server, zawierającym między innymi instrukcje zapytań, modyfikacji danych, obsługi transakcji, procedur składowanych, zmiennych i konstrukcji sterujących.

Program korzystający z takiego API zwykle wykonuje kilka odrębnych operacji: tworzy połączenie, uwierzytelnia użytkownika, przygotowuje polecenie, przekazuje parametry, uruchamia zapytanie, odczytuje zbiór wynikowy oraz obsługuje błędy i zamknięcie zasobów. Interfejs może udostępniać zarówno wykonywanie pojedynczych poleceń, jak i pracę z procedurami składowanymi, transakcjami oraz wieloma zestawami wyników zwracanymi przez jedną procedurę.

Biblioteki i protokoły komunikacji z SQL Server

W aplikacjach platformy .NET często stosuje się dostawcę Microsoft.Data.SqlClient albo starszy System.Data.SqlClient. Biblioteki te udostępniają klasy takie jak SqlConnection, SqlCommand, SqlParameter i SqlDataReader. SqlConnection reprezentuje połączenie z SQL Server, SqlCommand opisuje instrukcję lub procedurę do wykonania, a SqlDataReader umożliwia sekwencyjny odczyt wierszy bez konieczności ładowania całego wyniku do pamięci. W kodzie asynchronicznym dostępne są również metody oparte na wzorcu async/await, takie jak OpenAsync lub ExecuteReaderAsync.

Poza środowiskiem .NET aplikacje mogą korzystać z innych sterowników zgodnych z konkretnym sposobem dostępu. ODBC używa sterownika SQL Server i standardowego interfejsu funkcji bazodanowych, JDBC jest interfejsem dla aplikacji Java, natomiast OLE DB zapewnia dostęp przez komponenty tego modelu. Niezależnie od biblioteki, komunikacja obejmuje przesłanie polecenia do SQL Server i zwrócenie odpowiedzi zawierającej dane, liczbę zmodyfikowanych wierszy, komunikat albo błąd. Szczegóły konfiguracji, uwierzytelniania i szyfrowania zależą od użytego sterownika oraz ustawień instancji SQL Server.

Parametry, transakcje i wyniki zapytań

Bezpieczne API powinno przekazywać wartości wejściowe jako parametry, a nie przez sklejanie tekstu SQL z danymi otrzymanymi od użytkownika. Parametryzacja pozwala sterownikowi przekazać wartość oddzielnie od treści polecenia i ogranicza ryzyko wstrzyknięcia SQL. W bibliotekach dla SQL Server parametry mogą mieć jawnie określony typ, rozmiar i kierunek działania. Ma to znaczenie szczególnie dla wartości typu data i czas, liczb dziesiętnych, danych binarnych oraz długich tekstów, ponieważ nieprawidłowe rozpoznanie typu może prowadzić do konwersji, błędów albo niekorzystnego planu wykonania.

API może także sterować transakcją obejmującą kilka instrukcji T-SQL. Transakcja rozpoczyna się po stronie klienta albo w samym T-SQL, a następnie kończy zatwierdzeniem przez COMMIT lub wycofaniem przez ROLLBACK. Jeżeli aplikacja utraci połączenie przed zakończeniem transakcji, zachowanie zależy od stanu sesji i ustawień serwera, dlatego kod powinien prawidłowo obsługiwać wyjątki oraz zwalniać połączenia. Wynik zapytania może być odczytywany jako strumień wierszy, zmapowany do obiektów albo pobrany jako pojedyncza wartość, na przykład za pomocą odpowiednika ExecuteScalar. Dla instrukcji INSERT, UPDATE i DELETE często odczytuje się liczbę zmienionych rekordów.

Diagnostyka błędów w warstwie API T-SQL

Błąd zgłoszony przez aplikację nie musi oznaczać błędu składni samego zapytania. Problem może wynikać z niepoprawnego łańcucha połączenia, niedostępnej instancji SQL Server, odrzuconego uwierzytelnienia, braku uprawnień do obiektu, przekroczenia limitu czasu albo zerwania połączenia sieciowego. Po stronie SQL Server istotne są komunikaty błędów, numer błędu, poziom ważności, stan oraz procedura i wiersz, w których wystąpił problem. Po stronie klienta należy sprawdzić typ wyjątku i jego wewnętrzne komunikaty, ponieważ jeden wyjątek może zawierać kilka błędów zwróconych przez serwer.

Podczas analizy warto rozdzielić problemy transportowe od problemów wykonania T-SQL. Jeżeli połączenie nie powstaje, należy sprawdzić nazwę serwera, port, metodę uwierzytelniania i wymagania szyfrowania. Jeżeli połączenie działa, ale zapytanie trwa zbyt długo, przyczyną może być blokada, brak odpowiedniego indeksu, niekorzystny plan wykonania, duży zakres odczytu albo oczekiwanie na zasób. Pomocne są identyfikatory korelacyjne w logach aplikacji, czas rozpoczęcia i zakończenia polecenia, nazwa procedury oraz informacja, czy operacja została zatwierdzona. Nie powinno się zapisywać w logach haseł, pełnych ciągów połączeń ani nieograniczonych treści parametrów.