Wyzwalacze programu SQL Server — część 2

W SQL Server wyzwalacze to obiekty bazy danych, które zostaną wykonane za każdym razem, gdy w bazie danych lub serwerze wystąpi zdarzenie wyzwalające. Wyzwalacze odgrywają kluczową rolę w spełnianiu wymagań biznesowych, takich jak ostrzeganie osób docelowych na podstawie osiągniętego stanu, rozpoczęcia pracy lub innych operacji. W poprzednim artykule na temat wyzwalaczy DML rozmawialiśmy o wyzwalaczach, typach wyzwalaczy i różnych opcjach wyzwalaczy dostępnych dla wyzwalaczy DML. W tym artykule omówimy wyzwalacze SQL DDL i LOGON.

Wyzwalacze DDL

Wyzwalacze DDL mogą być uruchamiane dla różnych zdarzeń serwera lub bazy danych, w tym poleceń DDL i DCL. DDL to skrót od Data Definition Language, który służy do tworzenia, zmieniania i upuszczania dowolnych obiektów, a DCL oznacza wyrażenia Data Control Language, takie jak polecenia GRANT, DENY i REVOKE. Poniżej znajduje się charakterystyka wyzwalaczy SQL DDL.

Wyzwalacze DDL mogą być tworzone na poziomie bazy danych lub instancji serwera, obejmujące szeroką gamę operacji DDL lub operacji podobnych do DDL, np. Polecenia DCL.
Wyzwalacze DDL można wywoływać lub uruchamiać tylko jako wyzwalacze typu FOR lub AFTER. SQL Server nie obsługuje INSTEAD OF DDL Trigger i możemy zobaczyć, jak zapobiec niektórym operacjom DDL za pośrednictwem wyzwalaczy DDL.
SQL Server ma wbudowane funkcje, takie jak EVENTDATA() i IS_MEMBER() do użycia w wyzwalaczach DDL, aby uzyskać więcej informacji związanych ze zdarzeniami wyzwalacza.
1. Funkcja EVENTDATA() zwraca pełne szczegóły dotyczące zdarzeń w zakresie bazy danych lub serwera w formacie XML w zakresie wyzwalaczy DDL w zakresie bazy danych lub serwera lub wyzwalaczy logowania. Funkcja EVENTDATA() zwraca pełne Szczegóły zdarzenia dla sesji, która wykonuje czynności DDL lub Logowanie. EVENTDATA() zwraca poniższe szczegóły
  - EventType – Typ zdarzenia, które uruchamia wyzwalacz DDL dostępny w tabeli sys.trigger_event_types.
  - PostTime – czas, w którym wydarzenie zostało wyzwolone lub opublikowane.
  - SPID – Identyfikator sesji wydarzenia.
  - ServerName – nazwa instancji SQL Server, w której zdarzenie zostało wyzwolone.
  - LoginName – nazwa logowania serwera SQL, który wykonał zdarzenie.
  - Nazwa użytkownika – nazwa użytkownika loginu, która domyślnie będzie dbo.
  - DatabaseName — nazwa bazy danych, pod którą został uruchomiony wyzwalacz DDL.
  - SchemaName – nazwa schematu obiektu, który został dotknięty.
  - ObjectName — nazwa obiektu, który został zmieniony.
  - ObjectType – typ obiektu SQL Server, taki jak tabela, widok, procedura składowana.
  - TSQLCommand – Skrypt T-SQL, który został wykonany przez użytkownika, który wywołał wyzwalacz DDL.
  - SetOptions – opcje SET używane przez użytkownika lub klienta, takie jak SSMS, podczas wykonywania polecenia TSQLCommand.
  - CommandText — rzeczywiste instrukcje DDL lub DCL ze zdarzeniem DDL określonym w tabeli sys.trigger_event_types.
2. Funkcja IS_MEMBER() zwraca, czy bieżący użytkownik jest członkiem grupy Windows lub roli bazy danych SQL Server, czy nie.
Systemowe wyzwalacze DMV sys.triggers przechowują listę wszystkich wyzwalaczy w zakresie bazy danych. Możemy użyć poniższego zapytania, aby pobrać szczegóły wszystkich wyzwalaczy DDL w zakresie bazy danych.

SELECT * 
FROM sys.triggers
WHERE type = 'TR';

System DMV sys.server_triggers przechowuje listę wszystkich wyzwalaczy w zakresie serwera i możemy użyć poniższego zapytania, aby pobrać szczegóły dotyczące wszystkich wyzwalaczy DDL w zakresie serwera.

SELECT * 
FROM sys.server_triggers;

Definicje wyzwalacza DDL można wyświetlić, jeśli wyzwalacz nie jest zaszyfrowany, przy użyciu dowolnej z poniższych opcji z sys.sql_modules lub funkcji OBJECT_DEFINITION() lub procedury składowanej sp_helptext.

SELECT OBJECT_SCHEMA_NAME(object_id, db_id()) Schema_name, OBJECT_NAME(object_id) Trigger_Name, definition
FROM sys.sql_modules  
WHERE object_id = OBJECT_ID(<trigger_name>);   

SELECT OBJECT_DEFINITION (OBJECT_ID(<trigger_name>)) AS ObjectDefinition; 

EXEC sp_helptext '<trigger_name>';

Wszystkie możliwe zdarzenia DDL są dostępne w tabeli sys.trigger_event_types i można je wyświetlić za pomocą poniższego zapytania.

SELECT *
FROM sys.trigger_event_types;

Składnia wyzwalacza DDL to:

CREATE TRIGGER <trigger_name>
ON < ALL SERVER | DATABASE > 
[ WITH <DDL_trigger_option> [ ,...n ] ]  
{ FOR | AFTER } <event_type>
AS { sql_statement | EXTERNAL NAME <method specifier> }

Tworzenie wyzwalacza DDL ograniczonego do bazy danych

Utwórzmy wyzwalacz o zakresie bazy danych, aby śledzić wszystkie kreacje tabel i logować się do tabeli Logging o nazwie Track_DDL_Changes za pomocą poniższego skryptu.

CREATE TABLE Track_DDL_Changes (EventData xml, PostDtm datetime)
GO
CREATE TRIGGER TR_D_CREATETABLE
ON DATABASE
FOR CREATE_TABLE
AS
BEGIN
	INSERT INTO Track_DDL_Changes
	SELECT EVENTDATA(),GETDATE()
END
GO

Utwórzmy nową tabelę o nazwie trigger_test i zweryfikujmy, czy zdarzenie CREATE TABLE było kontrolowane, czy nie, używając poniższego skryptu.

CREATE TABLE Trigger_Test ( a int, b datetime);

Wybranie danych z tabeli Track_DDL_Changes pokazuje, że powyższe zdarzenie CREATE_TABLE zostało pomyślnie przechwycone, jak pokazano poniżej:

Kliknięcie wartości EventData otworzy wartość XML EVENTDATA() w nowym oknie, jak pokazano poniżej.

Jesteśmy w stanie zweryfikować pełne szczegóły zdarzenia wyzwalającego za pomocą funkcji EVENTDATA(), a zatem funkcja EVENTDATA() będzie odgrywać znaczącą rolę dla dowolnych wyzwalaczy DDL lub LOGON.

Możemy jeszcze bardziej ulepszyć nasz wyzwalacz DDL za pomocą funkcji EVENTDATA() i parsowania XML i uniemożliwić każdemu tworzenie tabeli w testowej bazie danych za pomocą skryptu podanego poniżej:

CREATE TRIGGER TR_D_PREVENT_CREATETABLE
ON DATABASE
FOR CREATE_TABLE
AS
BEGIN
   SELECT EVENTDATA().value  
        ('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(max)')  
   RAISERROR ('Creation of New tables restricted in this database, Kindly contact DBA.', 16, 1)   
   ROLLBACK  
END
GO

Utworzenie wyzwalacza o zakresie bazy danych zakończyło się pomyślnie i zweryfikujmy go, tworząc kolejną tabelę za pomocą poniższego skryptu.

CREATE TABLE Trigger_Test1 (a int, b datetime);

Wyzwalacz uniemożliwił nam utworzenie nowych tabel w tej bazie danych i zostawił również sensowną wiadomość użytkownikom. W podobny sposób możemy obsłużyć dowolne inne zdarzenia DDL lub w zakresie serwera, aby spełnić wymagania.

Aby usunąć wyzwalacz DDL w zakresie bazy danych, musimy użyć poniższej składni:

DROP TRIGGER <trigger_name> ON DATABASE;

Aby zrezygnować z wyzwalacza, który właśnie stworzyliśmy, skrypt byłby

DROP TRIGGER TR_D_PREVENT_CREATETABLE ON DATABASE;

Aby wyświetlić wyzwalacze DDL w zakresie bazy danych w SSMS, rozwiń Test bazy danych -> Programowalność -> Wyzwalacze bazy danych, jak pokazano poniżej.

Podobnie jak w przypadku wyzwalaczy SQL DML, wyzwalacze DDL można usuwać, wyłączać lub włączać, klikając prawym przyciskiem myszy nazwę wyzwalacza, jak pokazano poniżej.

Za pomocą T-SQL możemy usunąć lub wyłączyć lub włączyć wyzwalacz DDL w zakresie bazy danych, używając poniższej składni:

-- DROP Database scoped DDL Trigger
DROP TRIGGER <trigger_name> ON DATABASE;
-- Enable Database scoped DDL Trigger
ENABLE TRIGGER <trigger_name> ON DATABASE;
-- Disable Database scoped DDL Trigger
DISABLE TRIGGER <trigger_name> ON DATABASE;

Aby wyłączyć utworzony przez nas wyzwalacz, może być konieczne użycie poniższego skryptu.

-- DROP Database scoped DDL Trigger
DROP TRIGGER TR_D_PREVENT_CREATETABLE ON DATABASE;
-- Enable Database scoped DDL Trigger
ENABLE TRIGGER TR_D_PREVENT_CREATETABLE ON DATABASE;
-- Disable Database scoped DDL Trigger
DISABLE TRIGGER TR_D_PREVENT_CREATETABLE ON DATABASE;

Tworzenie wyzwalacza DDL o zasięgu serwera

Wyzwalacz DDL o zasięgu serwera ma taką samą składnię, jak wyzwalacz DDL o zakresie bazy danych, z wyjątkiem tego, że zdarzenia będą oparte na zakresie serwera.

Spróbujmy utworzyć wyzwalacz DDL o zasięgu serwera, aby uniemożliwić każdemu użytkownikowi tworzenie nowej bazy danych na tej instancji serwera za pomocą poniższego skryptu.

CREATE TRIGGER TR_S_PREVENT_CREATEDATABASE
ON ALL SERVER
FOR CREATE_DATABASE
AS
BEGIN
   SELECT EVENTDATA().value  
        ('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(max)')  
   RAISERROR ('Creation of New Databases restricted in this Instance, Kindly contact DBA.', 16, 1)   
   ROLLBACK  
END
GO

Podczas próby utworzenia nowej bazy danych za pomocą poniższego polecenia otrzymamy błąd, jak pokazano poniżej.

CREATE DATABASE DATABASE_TEST;

W SSMS, wyzwalacze DDL w zakresie serwera w sekcji Wyzwalacze w sekcji Obiekty serwera, jak pokazano poniżej.

Możemy usunąć, wyłączyć lub włączyć wyzwalacz DDL o zakresie serwera, po prostu klikając prawym przyciskiem myszy wyzwalacz DDL o zakresie serwera, jak pokazano poniżej.

Za pomocą T-SQL możemy usunąć lub wyłączyć lub włączyć za pomocą poniższego polecenia.

-- DROP Server scoped DDL Trigger
DROP TRIGGER TR_S_PREVENT_CREATEDATABASE ON ALL SERVER;
-- Disable Server scoped DDL Trigger
DISABLE TRIGGER TR_S_PREVENT_CREATEDATABASE ON ALL SERVER;
-- Enable Server scoped DDL Trigger
ENABLE TRIGGER TR_S_PREVENT_CREATEDATABASE ON ALL SERVER;

Cel wyzwalaczy DDL

Aby kontrolować wszelkie zdarzenia DDL zachodzące na poziomie bazy danych lub serwera.
Aby zapobiec wszelkim zdarzeniom DDL na poziomie bazy danych lub serwera.
Aby zaalarmować, gdy wystąpią jakiekolwiek zdarzenia DDL na poziomie bazy danych lub serwera.

Wyzwalacze logowania

Wyzwalacze logowania, jak sama nazwa wskazuje, są wykonywane dla zdarzeń LOGON w SQL Server. Po zakończeniu fazy uwierzytelniania dla zdarzenia logowania, oprócz aktywności logowania zostanie wykonany skrypt wyzwalacza LOGON. Jeśli logowanie nie zostanie pomyślnie uwierzytelnione, wyzwalacze LOGON nie zostaną uruchomione. Wyzwalacze logowania będą wymienione w SSMS w sekcji Wyzwalacze obiektów serwera. Składnia wyzwalacza LOGON jest następująca:

CREATE TRIGGER <schema_name.trigger_name>
ON ALL SERVER
{ FOR| AFTER } LOGON    
AS { sql_statement  [ ; ] [ ,...n ] | EXTERNAL NAME < method specifier >  [ ; ] }

Utwórz wyzwalacze

Stwórzmy prosty wyzwalacz LOGON, aby przechwycić więcej informacji o zdarzeniu LOGON z funkcji EVENTDATA(), jak pokazano poniżej.

CREATE TABLE Track_LOGON_EVENTS (EventData xml, PostDtm datetime)
GO
CREATE TRIGGER TR_LOGON
ON ALL SERVER
FOR LOGON
AS
BEGIN
	INSERT INTO Track_LOGON_EVENTS
	SELECT EVENTDATA(),GETDATE();
END
GO

Powyższy wyzwalacz LOGON przechwyci wszystkie szczegóły dotyczące aktywności logowania podobne do tego, co zauważyliśmy podczas korzystania z funkcji EVENTDATA() w wyzwalaczu DDL. Powinniśmy być ostrożni, planując użycie wyzwalaczy LOGON, ponieważ gdyby wewnątrz wyzwalacza były jakieś błędy logiczne, nie pozwoliłoby to nikomu lub większości użytkowników na połączenie się z instancją SQL Server.

Aby upuścić, wyłączyć lub włączyć wyzwalacze LOGON, możemy użyć poniższego skryptu.

-- DROP LOGON Trigger
DROP TRIGGER TR_LOGON ON ALL SERVER;
-- Disable LOGON Trigger
DISABLE TRIGGER TR_LOGON ON ALL SERVER;
-- Enable LOGON Trigger
ENABLE TRIGGER TR_LOGON ON ALL SERVER;

Cel wyzwalaczy LOGON

Aby kontrolować wszelkie zdarzenia LOGON zachodzące na serwerze.
Aby zapobiec wszelkim zdarzeniom LOGON na serwerze
Aby zaalarmować, gdy na serwerze wystąpią jakiekolwiek zdarzenia LOGON.

Właściwości wyzwalacza

sp_settriggerorder

sp_settriggerorder służy do definiowania kolejności wykonywania wyzwalacza tylko dla pierwszego i ostatniego wyzwalacza. Jeśli w tabeli są więcej niż 2 wyzwalacze DML, powiedzmy 5 wyzwalaczy DML, możemy zdefiniować pierwszy wyzwalacz DML i ostatni wyzwalacz DML, ale nie możemy zdefiniować kolejności środkowych 3 wyzwalaczy.

Uwaga: Ustawienie opcji PIERWSZY lub OSTATNI jest specyficzny dla określonej kategorii zdarzenia dla wyzwalaczy DML. Na przykład w tabeli zawierającej 3 wyzwalacze INSERT możemy zdefiniować, który wyzwalacz INSERT jest PIERWSZY, a który OSTATNI. Jeśli masz 3 wyzwalacze w tabeli, takie jak INSERT, UPDATE i DELETE, nie ma potrzeby ustawiania warunku kolejności wyzwalania.

Składnia do ustawiania kolejności wyzwalania wyglądałaby następująco:

exec sp_settriggerorder @triggername = '<trigger_schema_name.trigger_name>' 
    , @order = 'FIRST' | 'LAST'   
    , @stmttype = '<trigger event type>'   
    , @namespace = 'DATABASE' | 'SERVER' | 'NULL'

W przypadku wyzwalaczy DDL możemy zdefiniować pierwszy i ostatni wyzwalacz o zakresie serwera, a następnie zdefiniować pierwszy i ostatni wyzwalacz o zasięgu bazy danych. Na przykład, jeśli mamy 5 wyzwalaczy o zakresie serwera i 5 wyzwalaczy o zakresie bazy danych, kolejność można zdefiniować w następujący sposób:

Pierwszy wyzwalacz dla wyzwalacza DDL o zakresie serwera
3 inne wyzwalacze DDL o zasięgu serwera w kolejności losowej
Ostatni wyzwalacz dla wyzwalacza DDL o zakresie serwera.
Pierwszy wyzwalacz dla wyzwalacza DDL ograniczonego do bazy danych (jeden na bazę danych)
3 inne wyzwalacze DDL w zakresie bazy danych w kolejności losowej
Ostatni wyzwalacz dla wyzwalacza DDL o zakresie bazy danych.

W odniesieniu do ustawienia pierwszej lub ostatniej opcji wyzwalacze DDL w zakresie bazy danych można uporządkować w bazie danych, a wyzwalacze DDL w zakresie serwera na poziomie instancji.

Mimo że SQL Server pozwala nam tworzyć wiele wyzwalaczy w tabeli, zaleca się dokładne przeanalizowanie wymagań wyzwalacza w celu lepszej konserwacji i rozwiązywania problemów.

Wyzwalacze rekurencyjne

SQL Server obsługuje również rekurencyjne wywoływanie wyzwalaczy dla wyzwalaczy DML. Wyzwalacze rekurencyjne można sklasyfikować jako bezpośrednie lub pośrednie, jak pokazano poniżej.

Bezpośrednie wyzwalacze rekurencyjne – Użytkownik lub aplikacja aktualizuje rekord w Tabeli A. UPDATE Triger A w Tabeli A zostaje uruchomiony i ponownie aktualizuje Tabelę A. Ponieważ rekord w tabeli A został zaktualizowany za pomocą wyzwalacza, ponownie wywoła on wyzwalacz AKTUALIZUJ A i będzie się to odbywać cyklicznie.

Utwórzmy bezpośrednie wyzwalacze rekurencyjne w tabeli Sales za pomocą poniższego skryptu:

CREATE TRIGGER TR_UPD_Recursive_Sales ON Sales
FOR UPDATE 
AS
BEGIN
  UPDATE Sales 
  SET SalesDate = GETDATE() 
  WHERE SalesId = (SELECT SalesId FROM Inserted)
END
GO

Wykonaj poniższy skrypt:

UPDATE Sales 
SET SalesDate = GETDATE() 
WHERE SalesId = 3;

Pośrednie wyzwalacze rekurencyjne – Użytkownik lub aplikacja aktualizuje rekord w Tabeli A. Wyzwalacz UPDATE A w Tabeli A zostaje uruchomiony i aktualizuje rekord w Tabeli B. Jeśli Tabela B ma wyzwalacz UPDATE do aktualizacji rekordów z powrotem do Tabeli A, wywoła wyzwalacz UPDATE w Tabeli A Tabela A, która będzie się powtarzać.

Utwórzmy pośredni wyzwalacz rekurencyjny na tabelach IDR_Test1 i IDR_Test2 za pomocą poniższego skryptu:

DROP TABLE IDR_Test1
DROP TABLE IDR_Test2

CREATE TABLE IDR_Test1 (PK int NOT NULL);
GO
INSERT INTO IDR_Test1 
values (10),(20)
GO
CREATE TABLE IDR_Test2 (PK int NOT NULL);
GO
INSERT INTO IDR_Test2
values (10),(20)
GO

CREATE TRIGGER TR_IDR_Test1
ON IDR_Test1
FOR UPDATE 
AS
BEGIN
	UPDATE IDR_Test2
	SET PK = 30
	WHERE PK IN (SELECT PK FROM inserted);
END
GO
 
CREATE TRIGGER TR_Temp2
ON IDR_Test2
FOR UPDATE 
AS
BEGIN
	UPDATE IDR_Test1
	SET PK = 30
	WHERE PK IN (SELECT PK FROM inserted);
END
GO

Wykonaj poniższy skrypt:

UPDATE IDR_Test1
SET PK = 1
WHERE PK = 10;

Aby uniknąć tego rodzaju wywoływania wyzwalaczy rekurencyjnych na poziomie bazy danych, SQL Server ma opcję o nazwie RECURSIVE_TRIGGERS na każdym poziomie bazy danych, która przerywa wyzwalanie wyzwalacza rekurencyjnego. Domyślnie opcja wyzwalacza rekurencyjnego jest ustawiona na wartość Fałsz dla bazy danych. Włącz tylko w razie potrzeby po dokładnym rozważeniu wpływu na wydajność lub związanych z tym zmian danych.

W programie SSMS kliknij prawym przyciskiem myszy naszą Testową bazę danych -> Wybierz Właściwości -> Kliknij Opcje i przewiń w dół, aby zobaczyć, czy opcja Wyzwalacze rekurencyjne jest włączona lub nie, jak pokazano poniżej. W przypadku testowej bazy danych jest ustawiona na Fałsz, ponieważ Fałsz jest wartością domyślną opcji Wyzwalacze rekurencyjne. Aby włączyć opcję Wyzwalacze rekurencyjne dla określonej bazy danych, po prostu kliknij wartość listy rozwijanej, zmień ją na Prawda i kliknij OK.

Za pomocą T-SQL możemy zweryfikować opcję Recursive Trigger bazy danych Test, sprawdzając kolumnę is_recursive_triggers_on w sys.databases DMV, jak pokazano poniżej.

select name, is_recursive_triggers_on
from sys.databases
where name = 'test'

Aby zmienić opcję wyzwalaczy rekurencyjnych dla bazy danych (Test w moim przykładzie), możemy wykonać poniższy skrypt.

ALTER DATABASE [Test] SET RECURSIVE_TRIGGERS ON WITH NO_WAIT
GO

Aby wyłączyć go z powrotem do stanu fałszywego (stan domyślny) dla bazy danych (w moim przykładzie Test), wykonaj poniższy skrypt.

ALTER DATABASE [Test] SET RECURSIVE_TRIGGERS OFF WITH NO_WAIT
GO

Wyzwalacze zagnieżdżone

Wyzwalacze rekurencyjne są klasycznym przykładem wyzwalaczy zagnieżdżonych, ale może być kilka innych przypadków powodujących zagnieżdżanie wielu wyzwalaczy. SQL Server umożliwia zagnieżdżanie wyzwalaczy do maksymalnie 32 poziomów, a każdy wyzwalacz przekraczający ten poziom zagnieżdżenia zostanie anulowany przez SQL Server. SQL Server ma konfigurację obejmującą całe wystąpienie, aby wyłączyć opcję zagnieżdżonych wyzwalaczy. Należy zauważyć, że zagnieżdżanie wyzwalaczy SQL Server przy użyciu kodu CLR lub kodu zarządzanego nie mieści się w limicie 32 poziomów, ponieważ znajduje się poza zakresem SQL Server. Domyślnie opcja zagnieżdżonych wyzwalaczy będzie włączona we wszystkich instancjach SQL Server i możemy ją wyłączyć w razie potrzeby.

Możemy zweryfikować, czy opcja zagnieżdżonych wyzwalaczy jest włączona na poziomie instancji w SSMS, wykonując poniższe czynności:

Kliknij prawym przyciskiem myszy Serwer -> Wybierz Właściwości -> Kliknij Zaawansowane

Aby wyłączyć lub wyłączyć opcję zagnieżdżonych wyzwalaczy, kliknij menu i zmień je na Fałsz, a następnie kliknij OK .

Za pomocą T-SQL możemy sprawdzić, czy opcja Nested triggers jest włączona, sprawdzając kolumnę value_in_use w sys.configurations DMV dla nazwy konfiguracji zagnieżdżonych wyzwalaczy.

Aby wyłączyć tę opcję, musimy użyć sp_configure systemowej procedury składowanej, jak pokazano poniżej:

EXEC sp_configure 'nested triggers', 0;  
GO  
RECONFIGURE;  
GO

W ramach dowolnych wyzwalaczy DML lub DDL, aby znaleźć bieżący poziom zagnieżdżenia, SQL Server ma wbudowaną funkcję o nazwie TRIGGER_NESTLEVEL, która zwraca liczbę wyzwalaczy wykonanych dla bieżącej instrukcji, która uruchomiła wyzwalacz, łącznie z nim samym. Składnia funkcji TRIGGER_NESTLEVEL wyglądałaby następująco:

SELECT TRIGGER_NESTLEVEL ( object_id, <trigger_type> , <trigger_event_category> )

Gdzie object_id jest identyfikatorem obiektu wyzwalacza, trigger_type będzie miał wartość PO dla wyzwalacza i IOT dla wyzwalacza INSTEAD OF, a trigger_event_category będzie miał wartość DML lub DDL.

Na przykład, jeśli musimy zezwolić tylko na zagnieżdżanie poziomu do 10 i podnieść błąd po 10 poziomach, możemy to zrobić za pomocą wyzwalacza testowego, jak tutaj:

IF ((SELECT TRIGGER_NESTLEVEL(OBJECT_ID('test_trigger'), 'AFTER’, 'DML’)) > 10)  
   RAISERROR ('Trigger test_trigger nested more than 10 levels.',16, -1)

SZYFROWANIE

Aby zaszyfrować logikę lub definicję wyzwalacza, można użyć opcji Z SZYFROWANIEM w definicji wyzwalacza, podobnie jak w przypadku wszystkich innych obiektów SQL Server.

WYKONAJ JAKO klauzula

Aby wykonać wyzwalacz przy użyciu określonego kontekstu bezpieczeństwa, w definicji wyzwalacza można użyć klauzuli EXECUTE AS.

NIE DO REPLIKACJI

Aby określić, że wyzwalacz DML nie powinien być wywoływany podczas wykonywania przez zmiany replikacji, właściwość NOT FOR REPLICATION zostanie ustawiona dla wszystkich obiektów w bazie danych subskrybenta.

Wniosek

Dziękujemy za zapoznanie się z rozbudowanym artykułem na temat wyzwalaczy DDL i wyzwalaczy logowania, w którym zrozumieliśmy przeznaczenie wyzwalaczy DDL i logowania, jak tworzyć, usuwać, wyłączać lub włączać te wyzwalacze oraz jak używać funkcji EVENTDATA() dla śledzenie działań DDL lub logowania. Oprócz tego nauczyliśmy się szczegółowo ustawiać kolejność wykonywania wielu wyzwalaczy SQL DML lub DDL wraz z wyzwalaczami rekurencyjnymi i zagnieżdżonymi oraz jak ostrożnie obchodzić się z wyzwalaczami rekursywnymi lub zagnieżdżonymi.