ERROR_STATE()

ERROR_STATE() to funkcja Transact-SQL zwracająca numer stanu ostatnio wystąpionego błędu, pomocny przy jego dokładnej diagnostyce.

ERROR_STATE() jako element obsługi błędów w Transact-SQL

ERROR_STATE() należy do funkcji dostępnych w języku Transact-SQL i służy do odczytania stanu błędu obsługiwanego wewnątrz konstrukcji TRY...CATCH. Zwracana wartość ma postać liczby całkowitej, która pomaga odróżnić kilka wariantów tego samego komunikatu lub tego samego numeru błędu. Dzięki temu można dokładniej ustalić, na którym etapie wykonania procedury, wyzwalacza albo partii instrukcji wystąpiła nieprawidłowość.

Sama funkcja nie wykrywa błędu, nie zatrzymuje zapytania i nie naprawia danych. Jej zadaniem jest dostarczenie dodatkowej informacji w chwili, gdy sterowanie znajduje się w bloku CATCH. W praktyce ERROR_STATE() stosuje się razem z ERROR_NUMBER(), ERROR_MESSAGE(), ERROR_SEVERITY(), ERROR_LINE() oraz ERROR_PROCEDURE(). Każda z tych funkcji opisuje inny wymiar problemu, a ich połączenie tworzy znacznie pełniejszy zapis diagnostyczny niż sam tekst komunikatu.

Przykładowy schemat obsługi może wyglądać następująco:

• BEGIN TRY otwiera fragment kodu, w którym spodziewane jest wykonanie operacji;
• BEGIN CATCH przejmuje sterowanie po wystąpieniu błędu;
• ERROR_STATE() odczytuje stan przypisany bieżącemu błędowi;
• wartość może zostać zapisana w dzienniku, zwrócona aplikacji albo wykorzystana w dalszej logice.

ERROR_STATE() na tle numeru błędu i treści komunikatu

Numer błędu oraz stan błędu nie oznaczają tego samego. ERROR_NUMBER() wskazuje rodzaj zdarzenia według numeracji silnika bazy danych, natomiast ERROR_STATE() dostarcza dodatkowego oznaczenia konkretnego wariantu sytuacji. Jednemu numerowi błędu może towarzyszyć więcej niż jedna wartość stanu. Taki układ pozwala rozróżnić przyczyny, które z punktu widzenia ogólnego komunikatu wyglądają podobnie, lecz wymagają odmiennych działań.

Wartość stanu jest przede wszystkim informacją diagnostyczną. Nie należy traktować jej jako kodu opisującego wszystkie szczegóły problemu ani jako gwarantowanego, uniwersalnego identyfikatora biznesowego. Interpretacja zależy od rodzaju błędu, wersji środowiska, miejsca jego zgłoszenia oraz sposobu napisania procedury. Dlatego w dzienniku powinny być przechowywane także inne dane: czas zdarzenia, nazwa procedury, numer wiersza, użytkownik lub proces wywołujący oraz bezpieczny kontekst operacji.

Istotna jest również różnica między błędem przechwyconym a błędem, który nie trafia do bloku CATCH. ERROR_STATE() ma sens w ramach aktywnej obsługi wyjątku. Wywołanie funkcji poza właściwym kontekstem nie zastępuje mechanizmu TRY...CATCH i nie pozwala odtworzyć dowolnego, historycznego błędu. Jeżeli wartość ma być dostępna później, należy jawnie zapisać ją do zmiennej lub tabeli logów przed zakończeniem obsługi.

ERROR_STATE() przy typowych problemach z procedurami

Problemy związane z ERROR_STATE() zwykle wynikają nie z samej funkcji, lecz z niewłaściwego odczytu informacji o błędzie. Częstym przypadkiem jest zapisanie wyłącznie ERROR_MESSAGE(). Tekst bywa wystarczający do ręcznej analizy, ale przy automatycznym monitoringu może być zbyt ogólny, zależny od języka lub zmienny między wersjami środowiska. Dodanie numeru i stanu zwiększa możliwość grupowania zdarzeń oraz porównywania powtarzających się incydentów.

Inny problem pojawia się wtedy, gdy obsługa błędu wykonuje dodatkowe instrukcje przed pobraniem wartości. Jeżeli kod CATCH uruchamia kolejną operację, wywołuje pomocniczą procedurę albo nadpisuje zmienne, trudniej ustalić, z którego zdarzenia pochodzi zarejestrowana informacja. Zaleca się pobranie wszystkich funkcji ERROR_* na początku bloku CATCH i dopiero później wykonywanie logowania, wycofania transakcji lub przekazania komunikatu.

Ostrożność jest potrzebna także przy transakcjach. Sam stan błędu nie mówi, czy transakcja nadal może zostać zatwierdzona, czy wymaga wycofania. Do oceny sytuacji służą między innymi mechanizmy kontroli stanu transakcji. ERROR_STATE() może pomóc wskazać wariant błędu, ale nie powinien być jedyną podstawą decyzji o COMMIT albo ROLLBACK.

Podczas diagnozowania aplikacji warto sprawdzić, czy warstwa pośrednia nie skraca komunikatu i nie gubi pól diagnostycznych. Sterownik, biblioteka, procedura API albo własny moduł logowania może przekazywać tylko tekst błędu, pomijając numer, stan i położenie. W takim przypadku informacja odczytana w bazie może być bogatsza niż ta widoczna w interfejsie użytkownika.

ERROR_STATE() w praktycznym logowaniu i testach

Najbardziej użyteczne zastosowanie ERROR_STATE() polega na budowaniu spójnego rejestru błędów. W tabeli logów można przechowywać osobne kolumny na numer błędu, stan, poziom ważności, numer wiersza, nazwę procedury, komunikat oraz czas wystąpienia. Rozdzielenie tych pól ułatwia filtrowanie i pozwala odróżnić zmianę treści komunikatu od rzeczywistej zmiany rodzaju zdarzenia.

Nie należy jednak zapisywać bezpośrednio do logu danych poufnych znalezionych w komunikacie. Tekst błędu może zawierać fragment zapytania, nazwę obiektu, identyfikator rekordu albo inne informacje, których nie powinno się ujawniać użytkownikowi końcowemu. Lepszym rozwiązaniem jest rozdzielenie zapisu technicznego od komunikatu prezentowanego aplikacji. Operator otrzymuje ogólną informację i identyfikator zgłoszenia, a szczegóły pozostają w kontrolowanym rejestrze.

W testach warto sprawdzać nie tylko to, czy błąd został przechwycony, ale także czy komplet danych trafił do logu. Test może obejmować przewidywalne naruszenie ograniczenia, nieprawidłowy parametr, próbę wykonania operacji na nieistniejącym obiekcie albo konflikt podczas modyfikacji. Następnie sprawdza się, czy ERROR_STATE() został pobrany w CATCH, czy zapisano go w odpowiednim polu i czy dalsza obsługa nie zatarła pierwotnego kontekstu.

Ważne jest również rozróżnienie wartości zerowej, wartości nieoczekiwanej oraz braku danych wynikającego z wywołania poza obsługą błędu. Przy projektowaniu raportów diagnostycznych należy unikać założenia, że każdy stan będzie miał tę samą wartość albo że konkretna liczba zawsze oznacza identyczną przyczynę we wszystkich procedurach.

ERROR_STATE() a moment zgłoszenia się do serwisu

Jeżeli błąd dotyczący ERROR_STATE() pojawia się cyklicznie, towarzyszy mu utrata danych, zatrzymanie procedur albo niejasne zachowanie aplikacji, wskazane jest zebranie pełnego komunikatu przed rozpoczęciem zmian. Przydatne są: nazwa bazy, fragment procedury obejmujący TRY...CATCH, numer błędu, stan zwrócony przez ERROR_STATE(), numer wiersza oraz informacja, po jakiej operacji pojawia się problem. Nie powinno się publikować haseł, pełnych danych klientów ani poufnych fragmentów konfiguracji.

W przypadku problemów wynikających z komputera, systemu bazodanowego lub środowiska pracy można skorzystać z pomocy Warszawskiego Pogotowia Komputerowego 24/7. Przy zgłoszeniu warto przekazać uporządkowane informacje diagnostyczne, ponieważ ułatwiają odtworzenie warunków wystąpienia błędu i rozdzielenie problemu aplikacyjnego od problemu sprzętowego.

Do serwisu warto zgłosić się również wtedy, gdy komunikat ERROR_STATE() występuje po awarii zasilania, aktualizacji systemu, wymianie podzespołów albo nagłym spowolnieniu pracy. W takich sytuacjach przyczyną może być nie tylko kod Transact-SQL, lecz także uszkodzenie plików, błędy nośnika, nieprawidłowa konfiguracja środowiska lub przerwanie transakcji. Sama wartość stanu jest ważną wskazówką, ale prawidłowa diagnoza wymaga zestawienia jej z pełnym kontekstem zdarzenia.