Wyzwalacz DML

Wyzwalacz DML reaguje na operacje INSERT, UPDATE lub DELETE wykonywane na tabeli.

Rodzaje wyzwalaczy i tabele pomocnicze

Wyzwalacz w wariancie AFTER uruchamia się po zakończeniu operacji modyfikującej dane, ale jeszcze w obrębie tej samej transakcji, natomiast wariant INSTEAD OF zastępuje pierwotną operację i wykonuje wyłącznie kod z ciała wyzwalacza — ten drugi jest jedynym sposobem, by zapis do widoku łączącego kilka tabel w ogóle miał sens. W obu przypadkach silnik udostępnia dwie wirtualne tabele: inserted z nowym stanem wierszy i deleted ze stanem sprzed zmiany. Przy operacji aktualizującej wypełnione są obie, co pozwala porównać wartość przed i po. Dostępna jest też funkcja sprawdzająca, czy konkretna kolumna brała udział w aktualizacji, dzięki czemu można ograniczyć kosztowną logikę tylko do istotnych pól.

Najczęstszy błąd: założenie, że kod wykona się dla każdego wiersza

Wyzwalacz uruchamia się raz na całe polecenie, a nie raz na wiersz. Kod napisany tak, jakby w tabeli inserted zawsze siedział dokładnie jeden rekord — z przypisaniem wartości do zmiennej i użyciem jej dalej — działa poprawnie przy ręcznym dodawaniu pojedynczego dokumentu i cicho gubi dane przy imporcie stu pozycji naraz. Poprawny wyzwalacz operuje zbiorowo, złączeniem z tabelą inserted, bez pętli i bez kursora. Druga sprawa to zagnieżdżanie: wyzwalacz modyfikujący inną tabelę uruchamia jej wyzwalacz, a głębokość takiego łańcucha jest ograniczona i po przekroczeniu limitu cała operacja kończy się błędem. Rekurencja bezpośrednia, czyli wyzwalacz wywołujący sam siebie zmianą własnej tabeli, jest domyślnie wyłączona na poziomie ustawień bazy.

Wpływ na transakcje i wydajność

Ponieważ wyzwalacz pracuje wewnątrz transakcji polecenia, wycofanie zmian w jego wnętrzu przerywa całą operację — użytkownik programu handlowego zobaczy wtedy komunikat o przerwanej transakcji, często zupełnie nieczytelny, bo pochodzący z warstwy bazy, a nie z aplikacji. Dlatego komunikaty w wyzwalaczach warto formułować tak, by dało się je rozpoznać w logu. Drugi problem to koszt: wyzwalacz zapisujący historię zmian do tabeli audytu podwaja liczbę zapisów, a przy masowym imporcie potrafi wydłużyć operację wielokrotnie i rozdąć dziennik transakcji. Na czas jednorazowej migracji danych zwykle wyłącza się je jawnie, pamiętając o włączeniu z powrotem — zapomniany wyłączony wyzwalacz to jedna z trudniejszych do wykrycia usterek, bo baza działa, tylko przestaje pilnować spójności.

Modyfikacje logiki w bazach programów handlowych

W bazach systemów typu Subiekt, WAPRO czy Comarch producent ma własne wyzwalacze i własne struktury, a dopisywanie do nich cudzego kodu bywa ryzykowne — aktualizacja programu potrafi podmienić obiekty albo zmienić schemat tabeli, na której nasz kod się opierał. Kiedy klient potrzebuje własnej logiki, na przykład rejestru zmian cen albo blokady kasowania dokumentów rozliczonych, robimy to ostrożnie: na osobnych tabelach, z nazwami odróżniającymi nasze obiekty od producenckich, po wykonaniu kopii bazy i po testach na jej klonie. Diagnozujemy również sytuacje odwrotne, gdy program nagle zgłasza błąd przy zapisie dokumentu, a przyczyną jest wyzwalacz odziedziczony po poprzednim wdrożeniowcu, o którym nikt w firmie już nie pamięta.