ERROR_PROCEDURE()

ERROR_PROCEDURE() to funkcja Transact-SQL zwracająca nazwę procedury, w której wystąpił błąd.

ERROR_PROCEDURE() jako informacja o źródle błędu

ERROR_PROCEDURE() jest funkcją języka Transact-SQL używaną przede wszystkim w obsłudze błędów. Zwraca nazwę procedury składowanej albo wyzwalacza, w którym wystąpiła sytuacja błędna. Dzięki temu możliwe staje się ustalenie, jaki element kodu był wykonywany w chwili przerwania operacji. Sama funkcja nie naprawia problemu, nie ponawia instrukcji i nie zmienia danych. Dostarcza jedynie informacji diagnostycznej, którą można zapisać w tabeli logów, zwrócić aplikacji albo wykorzystać podczas analizy przebiegu transakcji.

Funkcja ma postać ERROR_PROCEDURE() i nie przyjmuje argumentów. Jej użycie jest związane z kontekstem obsługi błędu, czyli z blokiem TRY...CATCH. Po wystąpieniu błędu wykonanie przechodzi do części CATCH, gdzie można odczytać między innymi numer błędu, komunikat, poziom ważności, stan, nazwę obiektu oraz numer wiersza. ERROR_PROCEDURE() uzupełnia ten zestaw o nazwę procedury lub wyzwalacza. Takie rozdzielenie informacji pozwala odróżnić miejsce wykrycia błędu od miejsca, w którym rozpoczęto wywołanie.

Jeżeli błąd wystąpił w procedurze składowanej lub w wyzwalaczu, funkcja zwykle zwraca nazwę tego obiektu. Jeżeli wyjątek pojawił się poza takim obiektem, na przykład w bezpośrednio wykonanym skrypcie, wynikiem może być wartość NULL. Nie oznacza to automatycznie, że funkcja działa nieprawidłowo. Oznacza jedynie brak procedury lub wyzwalacza, który można wskazać jako źródło błędu.

ERROR_PROCEDURE() na tle innych funkcji diagnostycznych

W praktycznym kodzie ERROR_PROCEDURE() rzadko występuje samodzielnie. Najczęściej łączy się ją z funkcjami ERROR_NUMBER(), ERROR_MESSAGE(), ERROR_SEVERITY(), ERROR_STATE(), ERROR_LINE() oraz ERROR_PROCEDURE(). Każda z nich opisuje inny aspekt zdarzenia. ERROR_NUMBER() wskazuje numer błędu, ERROR_MESSAGE() przedstawia jego opis, ERROR_LINE() podaje numer wiersza, a ERROR_PROCEDURE() pomaga ustalić nazwę wykonywanego obiektu. Dopiero zestawienie tych informacji tworzy pełniejszy obraz sytuacji.

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

BEGIN TRY
  EXEC dbo.PrzetworzZamowienie;
END TRY
BEGIN CATCH
  SELECT
    ERROR_NUMBER() AS NumerBledu,
    ERROR_MESSAGE() AS Komunikat,
    ERROR_PROCEDURE() AS Procedura,
    ERROR_LINE() AS Wiersz;
END CATCH;

W takim przykładzie ERROR_PROCEDURE() może zwrócić nazwę obiektu, w którym błąd wystąpił, a niekoniecznie nazwę procedury wywołującej. To ważne rozróżnienie. Gdy procedura A wywołuje procedurę B, a błąd powstaje w procedurze B, wynik funkcji zazwyczaj odnosi się do B. Jeżeli błąd zostanie przechwycony i ponownie zgłoszony w procedurze A, końcowa informacja może już dotyczyć A, zależnie od miejsca wykonania kodu i sposobu przekazania wyjątku.

W porównaniu z ręcznym wpisywaniem nazwy procedury w komunikacie funkcja zapewnia większą spójność. Przy zmianie nazwy obiektu nie trzeba aktualizować tekstu diagnostycznego w wielu miejscach. W porównaniu z samym ERROR_MESSAGE() daje także wskazanie lokalizacji logicznej, co ułatwia filtrowanie logów i wyszukiwanie powtarzających się awarii. Warto jednak pamiętać, że nazwa procedury nie zastępuje informacji o wierszu, parametrach ani danych wejściowych.

ERROR_PROCEDURE() a typowe problemy w obsłudze wyjątków

Jednym z częstych problemów jest wywołanie ERROR_PROCEDURE() poza blokiem CATCH. Funkcje ERROR_* mają użyteczny kontekst przede wszystkim podczas obsługi błędu. Poza nim mogą zwrócić wartość NULL, ponieważ nie istnieje aktywne zdarzenie, którego opis można odczytać. Z tego powodu odczyt informacji powinien nastąpić bezpośrednio w części CATCH albo zostać przekazany do osobnej procedury wywołanej z tego miejsca.

Drugim problemem jest mylenie nazwy obiektu z miejscem rozpoczęcia operacji. Jeśli jedna procedura wywołuje kolejną, ERROR_PROCEDURE() służy do wskazania obiektu powiązanego z błędem, a nie do przedstawienia pełnego stosu wywołań. Przy bardziej złożonych zależnościach sama nazwa może więc nie wystarczyć. Przydatne staje się wtedy logowanie identyfikatora operacji, danych wejściowych, czasu rozpoczęcia, numeru wiersza i kolejnych etapów działania.

Ryzyko błędnej diagnozy pojawia się również wtedy, gdy kod w bloku CATCH sam powoduje kolejny błąd. Jeżeli zapis do tabeli logów zależy od niedostępnej tabeli, ograniczenia integralności lub nieaktywnej transakcji, pierwotny komunikat może zostać przesłonięty. Warto zatem projektować rejestrację błędów tak, aby była możliwie prosta, a jej awaria nie utrudniała odczytu podstawowych danych.

Znaczenie ma także użycie transakcji. Po błędzie część operacji może wymagać wycofania, a funkcja XACT_STATE() może pomóc określić, czy transakcję da się zatwierdzić, czy należy ją cofnąć. ERROR_PROCEDURE() wskazuje wtedy miejsce związane z błędem, lecz nie decyduje o dalszym losie transakcji. Te dwa obszary należy analizować oddzielnie.

ERROR_PROCEDURE() w codziennym diagnozowaniu bazy danych

Przy projektowaniu obsługi błędów warto ustalić jednolity format logu. W jednym rekordzie można przechowywać nazwę procedury uzyskaną przez ERROR_PROCEDURE(), numer błędu, komunikat, numer wiersza, datę zdarzenia oraz identyfikator użytkownika lub procesu. Tak przygotowane dane pozwalają grupować awarie według obiektu i oceniać, czy problem dotyczy pojedynczego fragmentu kodu, konkretnego przepływu danych czy większej części aplikacji.

Nie należy zapisywać bez kontroli całej zawartości parametrów. Parametry mogą obejmować dane osobowe, informacje finansowe albo dane uwierzytelniające. Bezpieczniej jest rejestrować identyfikatory techniczne, skrócone wartości lub informacje o typie danych. Sama nazwa procedury zwykle nie zawiera danych użytkownika, dlatego dobrze nadaje się do podstawowego katalogowania błędów.

Warto również rozróżnić błąd oczekiwany od błędu programistycznego. Naruszenie reguły biznesowej może zostać obsłużone komunikatem przeznaczonym dla aplikacji, natomiast nieprawidłowa konwersja, brak obiektu albo błąd składni wymaga analizy kodu. ERROR_PROCEDURE() może pomóc w obu przypadkach, lecz sposób prezentacji informacji powinien zależeć od odbiorcy. Użytkownik końcowy nie zawsze powinien otrzymywać techniczną nazwę procedury, podczas gdy osoba odpowiedzialna za utrzymanie systemu potrzebuje pełnego wpisu diagnostycznego.

Podczas testów dobrze jest sprawdzić kilka scenariuszy: błąd bezpośrednio w procedurze, błąd w procedurze wywołanej przez inną procedurę, błąd w wyzwalaczu oraz wyjątek występujący poza obiektem składowanym. Takie testy pokazują, kiedy funkcja zwraca nazwę, a kiedy NULL. Pomagają też wykryć różnicę między błędem przechwyconym lokalnie a błędem ponownie zgłoszonym wyżej.

ERROR_PROCEDURE() i moment zgłoszenia się do serwisu

Jeżeli użycie ERROR_PROCEDURE() wiąże się z powtarzającymi się błędami aplikacji bazodanowej, niestabilnym działaniem programu, zatrzymywaniem operacji lub problemami z dostępem do danych, przydatne staje się zebranie komunikatu, nazwy procedury, numeru wiersza i czasu wystąpienia. W przypadku komputera przeznaczonego do pracy z bazą znaczenie mogą mieć również objawy systemowe, takie jak samoczynne restarty, spowolnienia, przegrzewanie albo problemy z dyskiem. Przekazanie uporządkowanych informacji ułatwia rozdzielenie usterki sprzętowej od błędu konfiguracji lub kodu.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się diagnostyką i naprawą laptopów oraz komputerów PC, dlatego przy zgłoszeniu można opisać zarówno objawy urządzenia, jak i komunikaty pochodzące z aplikacji. Bezpłatna diagnoza laptopa pozwala ustalić, czy źródła problemu należy szukać w sprzęcie, systemie, środowisku uruchomieniowym czy w samej bazie danych. Warto przygotować kopię komunikatu, nazwę używanego programu oraz informację, po jakiej czynności błąd się pojawia.