Funkcja ERROR_SEVERITY()

Funkcja ERROR_SEVERITY() zwraca poziom istotności ostatnio wystąpionego błędu.

Co dokładnie zwraca ta funkcja w Transact-SQL

ERROR_SEVERITY() to funkcja systemowa SQL Servera zwracająca liczbę całkowitą typu int — poziom istotności błędu przechwyconego w bloku CATCH konstrukcji BEGIN TRY … BEGIN CATCH. Wywołana poza blokiem CATCH nie zgłasza błędu, tylko zwraca NULL, co bywa źródłem cichych pomyłek w procedurach składowanych. Można ją użyć wielokrotnie w jednym bloku i za każdym razem dostać tę samą wartość, dopóki nie wystąpi kolejny błąd.

Skala istotności obejmuje wartości od 0 do 25. Zakres 11–16 to błędy, które użytkownik jest w stanie naprawić sam — naruszenie klucza obcego, dzielenie przez zero, konwersja typu. Poziomy 17–19 sygnalizują wyczerpanie zasobów serwera, na przykład brak miejsca w pliku bazy. Od 20 wzwyż mówimy o błędach krytycznych, które kończą połączenie i trafiają do dziennika SQL Servera.

Rodzina funkcji błędu i jej ograniczenia

ERROR_SEVERITY() występuje zawsze w towarzystwie ERROR_NUMBER(), ERROR_MESSAGE(), ERROR_STATE(), ERROR_LINE() i ERROR_PROCEDURE(). Klasyczny wzorzec loguje komplet tych wartości do tabeli diagnostycznej, po czym zgłasza błąd dalej. Tu pojawia się pułapka: RAISERROR z parametrem istotności powyżej 18 wymaga uprawnień sysadmin i klauzuli WITH LOG, więc przekazanie oryginalnej wartości 20 kończy się kolejnym błędem, tym razem o braku uprawnień. Instrukcja THROW bez argumentów tego problemu nie ma — powtarza oryginalny błąd z zachowanym poziomem, ale ustawia istotność 16 dla własnych komunikatów.

Druga pułapka to błędy, których CATCH w ogóle nie widzi: błędy kompilacji, niepoprawne nazwy obiektów rozpoznane przy późnym wiązaniu nazw oraz przerwanie sesji po stronie klienta.

Gdzie to się psuje w systemach handlowych

W bazach obsługujących Subiekta, WAPRO czy Comarcha najczęściej spotykamy procedury, które w bloku CATCH logują wyłącznie ERROR_MESSAGE(), a poziom istotności pomijają. Przy analizie awarii nie da się wtedy odróżnić literówki w zapytaniu od zapełnionego dysku z plikiem MDF, bo obie sytuacje wyglądają w logu tak samo. Drugi błąd to CATCH bez sprawdzenia XACT_STATE() — po błędzie krytycznym transakcja jest wyłącznie do wycofania i każda próba COMMIT kończy się kolejnym wyjątkiem, przez co pierwotna przyczyna ginie.

Wsparcie przy bazach Subiekta, WAPRO i Comarch

Zajmujemy się wdrażaniem i utrzymaniem oprogramowania handlowego opartego o SQL Server, więc czytanie dzienników błędów i procedur składowanych jest u nas codziennością. Przy zgłoszeniu przeglądamy log instancji, ustawienia trybu odzysku i przyrostu plików bazy, a przy powtarzających się błędach z wysokim poziomem istotności sprawdzamy nośnik pod kątem sektorów oczekujących na realokację. Firmy obsługujemy tak samo jak klientów indywidualnych, o każdej porze dnia i nocy.