Wyzwalacz z instrukcją BEGIN...END

Wyzwalacz z instrukcją BEGIN...END grupuje kilka poleceń w jeden blok logiki wykonywanej po zdarzeniu.

Rola bloku BEGIN...END w wyzwalaczu

Wyzwalacz, czyli trigger, jest obiektem bazy danych uruchamianym automatycznie po wystąpieniu określonego zdarzenia na wskazanej tabeli lub widoku. Zdarzeniem może być wstawienie wiersza, jego modyfikacja albo usunięcie. W zależności od silnika wyzwalacz może działać przed operacją, po niej albo zamiast niej. Gdy logika wyzwalacza obejmuje tylko jedną instrukcję, niektóre języki pozwalają zapisać ją bez dodatkowego bloku. Jeżeli jednak reakcja ma składać się z kilku poleceń, stosuje się konstrukcję BEGIN...END.

BEGIN rozpoczyna blok instrukcji, a END wskazuje jego koniec. Wewnątrz mogą znajdować się między innymi instrukcje warunkowe, przypisania wartości do zmiennych, operacje na innych tabelach, wywołania funkcji oraz polecenia obsługi błędów, jeśli dany silnik je obsługuje. Taki blok nie zmienia momentu uruchomienia wyzwalacza. Określa przede wszystkim zakres instrukcji należących do jednej procedury lub funkcji wykonywanej w reakcji na zdarzenie.

Jak przebiega wykonanie kilku instrukcji

Podczas obsługi zdarzenia silnik bazy danych wywołuje kod przypisany do wyzwalacza. Instrukcje w bloku BEGIN...END są wykonywane zgodnie z kolejnością zapisu, chyba że konstrukcja sterująca, na przykład IF, CASE albo pętla, zmieni przebieg programu. Jeśli pierwsza instrukcja ustali wartość zmiennej, następne polecenie może wykorzystać tę wartość do podjęcia decyzji lub zapisania wyniku w innej tabeli. Dzięki temu kilka powiązanych czynności tworzy jeden spójny fragment logiki.

Wyzwalacz może korzystać z danych dotyczących wiersza, który jest dodawany, zmieniany albo usuwany. Sposób odwołania do wartości starej i nowej zależy od używanego systemu baz danych, dlatego kod triggera powinien być pisany zgodnie z dokumentacją konkretnego silnika. W praktyce blok może najpierw sprawdzić warunek, następnie zapisać zdarzenie pomocnicze, a na końcu zwrócić odpowiednią wartość wymaganą przez mechanizm wyzwalacza. Nie wszystkie wyzwalacze zwracają wiersz; w części systemów funkcja wyzwalacza musi zwrócić specjalny typ lub wartość sterującą dalszym wykonaniem operacji.

Transakcje, błędy i skutki uboczne

Instrukcje wykonywane przez wyzwalacz są związane z operacją, która go uruchomiła. Jeżeli kod wyzwalacza zgłosi błąd, nadrzędne polecenie może zostać przerwane, a zmiany mogą zostać wycofane w ramach tej samej transakcji. Szczegółowe zachowanie zależy od silnika, rodzaju błędu i ustawień transakcyjnych. Z tego powodu każdy krok bloku powinien mieć jasno określony cel, a warunki wejściowe i możliwe wartości puste powinny być uwzględnione w kodzie.

Rozbudowany trigger może wykonywać dodatkowe zapisy, co utrudnia śledzenie zależności między tabelami. Jeśli taki zapis uruchamia kolejny wyzwalacz, powstaje łańcuch wywołań, a w niektórych konfiguracjach także rekurencja. Może to zwiększać czas trwania operacji oraz ryzyko blokad. Warto więc ograniczać blok BEGIN...END do logicznie uzasadnionych czynności, unikać niepotrzebnych zapytań i sprawdzać planowane indeksy na tabelach modyfikowanych przez kod. Testy powinny obejmować zarówno poprawne dane, jak i przypadki powodujące odrzucenie operacji.

Diagnostyka i utrzymanie kodu wyzwalacza

Problemy z wyzwalaczem często pojawiają się jako pozornie nieoczekiwane zmiany w bazie: dodatkowy wpis w tabeli, odrzucona aktualizacja albo błąd widoczny dopiero przy zapisie danych. Diagnostykę rozpoczyna się od ustalenia, jaki wyzwalacz jest przypisany do obiektu, na jakie zdarzenie reaguje i w którym momencie jest wykonywany. Następnie analizuje się instrukcje pomiędzy BEGIN i END, warunki sterujące, odwołania do nowych i poprzednich wartości oraz polecenia modyfikujące inne obiekty.

Przy wdrażaniu zmian należy sprawdzić składnię właściwą dla używanego silnika, ponieważ delimitery, sposób definiowania funkcji wyzwalacza, nazwy wartości przejściowych i zasady zwracania wyniku nie są identyczne we wszystkich bazach danych. Pomocne jest uruchomienie testu w osobnej transakcji, zapisanie oczekiwanego stanu tabel oraz porównanie go ze stanem po wykonaniu operacji. W dokumentacji technicznej powinny znaleźć się: zdarzenie uruchamiające trigger, kolejność wykonywania, zakres modyfikowanych tabel, warunki błędów i informacja, czy blok może wywołać inne wyzwalacze.