- Każdy wiersz łączy treść błędu z kontekstem: kto go wywołał, na którym dokumencie i w którym module.
- Kolumna
TYTULpełni funkcję kategorii zdarzenia i pozwala grupować powtarzające się problemy. - Cztery indeksy obsługują trzy podstawowe pytania: co się dziś wydarzyło, co dotyczyło danego dokumentu i co działo się określonego dnia.
- Rejestr ma wartość tylko wtedy, gdy ktoś go regularnie przegląda — sam zapis błędu niczego nie naprawia.
Do czego służy tabela [dbo].[_error]
Użytkownik zgłaszający problem rzadko potrafi powtórzyć komunikat, który zobaczył. Zwykle pamięta, że „coś wyskoczyło przy zapisie” i mniej więcej o której godzinie. Tabela [dbo].[_error] zamienia taką relację w konkret: przechowuje pełną treść komunikatu razem z loginem, numerem referencyjnym dokumentu i dokładnym czasem zdarzenia.
Podział na kolumny TYTUL i KOMUNIKAT jest tu istotny. Tytuł opisuje rodzaj zdarzenia i powtarza się dla podobnych przypadków, dzięki czemu nadaje się do grupowania. Komunikat zawiera szczegóły konkretnego wystąpienia — treść wyjątku, wartość, która nie przeszła kontroli, albo odpowiedź usługi zewnętrznej. Pierwsza kolumna służy do znalezienia wzorca, druga do rozwiązania pojedynczego przypadku.
Kolumny PRX i REFNO wiążą błąd z modułem i konkretnym dokumentem, a DDOWOD przechowuje datę zdarzenia gospodarczego, która nie zawsze pokrywa się z datą zapisu. Ta różnica bywa istotna przy błędach ujawniających się dopiero podczas przetwarzania wsadowego.
ZdarzenieAplikacja przerywa operację i zapisuje komunikat w rejestrze
GrupowanieKolumna TYTUL pozwala policzyć wystąpienia tego samego problemu
AnalizaREFNO i LOGIN wskazują dokument oraz warunki wystąpienia
WeryfikacjaSpadek liczby wpisów potwierdza skuteczność poprawki
Ostatni krok bywa pomijany. Bez sprawdzenia, czy błąd przestał się pojawiać, poprawka pozostaje domysłem.
Budowa tabeli — wykaz kolumn
Struktura jest zwięzła: identyfikacja wpisu, treść zdarzenia oraz trzy kolumny wiążące błąd z jego kontekstem biznesowym.
| Kolumna | Typ | Wymagana | Znaczenie |
|---|---|---|---|
DDOWOD | date data | nie | Data powstania błędu |
ID_ERROR | int liczba całkowita | tak | Uniklany identyfikator wiersza tabeli |
KIEDY | datetime data i godzina | tak | Data i czas zapisu błędu |
KOMUNIKAT | varchar(max) tekst bez limitu długości | nie | Opis błędu powodującego zapis w tabeli |
LOGIN | varchar(50) tekst do 50 znaków | nie | Nazwa użytkownika który wykonał błędną operację - zapis do tabeli |
PRX | varchar(5) tekst do 5 znaków | nie | Kod PRX dokumentu |
REFNO | varchar(20) tekst do 20 znaków | tak | Numer referencyjny dokumentu / kartoteki |
STAMP | timestamp znacznik wersji wiersza | tak | Unikalny identyfikator wiersza / stanu |
TYTUL | varchar(max) tekst bez limitu długości | tak | Tytuł zdarzenia |
Kolumny KOMUNIKAT i TYTUL mają typ varchar(max), co pozwala zapisać pełny ślad wyjątku. W praktyce warto ograniczyć zapisywaną treść do fragmentu istotnego diagnostycznie — pełne ślady stosu potrafią zdominować objętość tabeli.
Indeksy i wydajność zapytań
Indeksy odpowiadają trzem najczęstszym punktom wyjścia przy diagnozie: czasowi, dacie zdarzenia gospodarczego i konkretnemu dokumentowi.
| Indeks | Kolumny | Rodzaj |
|---|---|---|
DDOWOD | DDOWOD | zwykły |
KIEDY | KIEDY | zwykły |
PK__error | ID_ERROR | klucz główny |
REFNO | REFNO | zwykły |
Indeks na kolumnie KIEDY obsługuje pytanie o ostatnie godziny pracy systemu i jest w praktyce używany najczęściej. Indeks na REFNO pozwala zebrać wszystkie błędy dotyczące jednego dokumentu — przydaje się, gdy użytkownik zgłasza, że „ten dokument w ogóle się nie zapisuje”.
Jak czytać rejestr, żeby coś z niego wynikało
Rejestr błędów bez ustalonego rytmu przeglądania zamienia się w archiwum, do którego nikt nie zagląda. Poniższe podejście sprawdza się przy utrzymaniu instalacji StudioSystem i wymaga kilkunastu minut tygodniowo.
- Zacznij od liczby, nie od treści. Zestawienie liczby wystąpień w podziale na tytuł zdarzenia od razu pokazuje, co jest problemem systemowym, a co jednorazową awarią.
- Oddziel błędy użytkownika od błędów systemu. Nieudana kontrola poprawności danych to informacja o procesie albo o szkoleniu, nie o wadzie oprogramowania.
- Sprawdź rozkład w czasie. Skupienie wpisów w jednej godzinie zwykle wskazuje na zdarzenie zewnętrzne — restart serwera, przerwę w łączu, przeciążenie usługi.
- Powiąż z jednym użytkownikiem. Błędy występujące wyłącznie u jednej osoby częściej wynikają z uprawnień lub konfiguracji stanowiska niż z kodu.
- Zamknij pętlę. Po wdrożeniu poprawki wróć do zestawienia za tydzień i sprawdź, czy dana kategoria zniknęła.
Warto też ustalić próg, powyżej którego wpis przestaje być informacją, a staje się zgłoszeniem. Kilka wystąpień miesięcznie mieści się w normalnej pracy systemu; kilkadziesiąt dziennie oznacza, że użytkownicy nauczyli się obchodzić problem i przestali go zgłaszać — co jest gorsze niż awaria, bo pozostaje niewidoczne.
Jak korzystać z tabeli w praktyce
Przy korzystaniu z rejestru błędów sprawdzają się następujące zasady:
- Grupuj po kolumnie
TYTUL, zanim zaczniesz czytać pojedyncze komunikaty — skala problemu jest ważniejsza od jego pierwszego wystąpienia. - Ustaw cykliczne zestawienie liczby błędów z ostatniej doby; nagły wzrost jest sygnałem szybszym niż zgłoszenie użytkownika.
- Wiąż wpis z dziennikiem zdarzeń przez
REFNO, jeśli chcesz ustalić, co działo się z dokumentem tuż przed błędem. - Zwracaj uwagę na różnicę między
KIEDYaDDOWOD— rozbieżność wskazuje na błąd ujawniony przy przetwarzaniu wsadowym, nie przy pracy operatora. - Nie zapisuj w komunikacie danych osobowych ani zawartości pól, które im podlegają; rejestr bywa udostępniany szerzej niż dane operacyjne.
- Archiwizuj wpisy starsze niż kilka miesięcy — do analizy trendów wystarczą liczby, a pełne treści zajmują najwięcej miejsca.
Zestawienie kategorii błędów z ostatniego tygodnia uporządkowane według liczby wystąpień — punkt wyjścia do przeglądu:
SELECT TYTUL,
COUNT(*) AS WYSTAPIEN,
COUNT(DISTINCT LOGIN) AS UZYTKOWNIKOW,
MIN(KIEDY) AS PIERWSZY,
MAX(KIEDY) AS OSTATNI
FROM dbo._error
WHERE KIEDY >= DATEADD(DAY, -7, GETDATE())
GROUP BY TYTUL
HAVING COUNT(*) > 1
ORDER BY WYSTAPIEN DESC;Kolumna UZYTKOWNIKOW jest tu istotna: błąd występujący u wielu osób wskazuje na problem systemowy, a u jednej — częściej na uprawnienia albo konfigurację stanowiska.
Rejestr błędów nie naprawia niczego samodzielnie. Jego wartość zaczyna się w momencie, gdy ktoś regularnie zestawia liczby i reaguje na zmiany — a kończy, gdy staje się wyłącznie miejscem, w którym błędy są zapisywane i zapominane.
Powiązane tabele i dokumentacja
Rejestr błędów najczęściej analizuje się razem z pozostałymi zapisami diagnostycznymi systemu: