Завдання

1. Створити таблицю, що містить П.І.Б. (прізвище - повністю, ім'я та по батькові - скорочено) і групу всіх студентів, які можуть стати фахівцями (4 - ий курс, 3<= середній бал <= 4.56). При виконанні завдання використовувати курсори.

2. Вивести на екран П.І.Б. (прізвище - повністю, ім'я та по батькові - скорочено) і групу всіх студентів, які мають заборгованості (негативну оцінку по якому-небудь предмету). При виконанні завдання використовувати курсори.

3. Вивести на екран П.І.Б. (прізвище - повністю, ім'я та по батькові - скорочено) і групу всіх студентів, які мають 3 заборгованості (негативну оцінку по якому-небудь предметі) і для кожного студента список предметів, по яких у нього заборгованості, а також отриману ним негативну оцінку. При виконанні завдання використовувати курсори.

4. Вивести на екран П.І.Б. (прізвище - повністю, ім'я та по батькові - скорочено) і посаду викладача, у якого найбільше статей, а також назви статей і список співавторів для кожної статті. При виконанні завдання використовувати курсори.

5. Вивести на екран П.І.Б. (прізвище - повністю, ім'я та по батькові - скорочено) всіх студентів, які вчаться в 2 або більше групах (наприклад, учаться на денному і вечірньому відділеннях), а також назви груп для кожного студента, у яких він учиться. Знайти одну з найбільш популярних спеціальностей (її код), що люблять одержувати студенти в якості додатковоїо (другої) вищої освіти. При виконанні завдання використовувати курсори.

Лабораторна робота № 6 Створення тригерів бд

Ціль роботи: познайомитися з поняттям та видами видами тригерів, вивчити процес створення і використання тригерів в MS SQL Server 2005. Розглянути приклади застосування тригерів, як реакцію на виконання різних SQL запитів.

Теоретична частина.

Тригер - це збережена процедура, що починає свою роботу у випадку виконання дії, на яку тригер настроєний. Тригери застосовуються для рішення завдань підтримки цілісності (коректності) даних, коли за якимись причинами неможливо (незручно) використовувати обмеження FOREIGN KEY (або обмеження на значення стовпців), і безпеки, коли, наприклад, неприпустимі які-небудь зміни в даних. Тригери бувають декількох типів: DML, DDL і LOGON. DML тригери можуть спрацьовувати при виконанні (після виконання або замість виконання) команд INSERT, UPDATE і DELETE для таблиць або подань. Цей тип тригерів був присутній і в MS SQL Server 2000. DDL тригери можуть спрацьовувати при виконанні, після виконання команд CREATE, ALTER, DROP, GRANT, DENY, REVOKE, UPDATE STATISTICS і деяких системних процедур. LOGON тригери спрацьовують після установки з'єднання з MS SQL Server. DDL і LOGON тригери можна використовувати тільки в MS SQL Server 2005, якщо рівень сумісності для БД установлений у значення 90.

Оператор створення / зміни DML тригера має вигляд:

CREATE TRIGGER [простір_імен.]назва_тригера

ON {назва_таблиці | назва_подання}

[WITH

{ ENCRYPTION |

EXEC[UTE] AS {CALLER | SELF | OWNER | ‘ім'я_користувача’}

}[,]

]

{ FOR [AFTER] | INSTEAD OF}

{[INSERT] [,] [UPDATE] [,] [DELETE]}

[WITH APPEND]

[NOT FOR REPLICATION]

AS

{

Перелік_команд_SQL |

EXTERNAL NAME ім'я_складання.ім'я_класу.назва_методу [;]

}

Слід зазначити, що під терміном «простір_імен» (schema) мається на увазі виділений простір імен, що є по суті «контейнером» для об'єктів. Користувачі можуть володіти схемами, мати права на доступ до схеми, але не є синонімом поняття схеми, на відміну від попередніх версій MS SQL Server. У випадку зміни вже існуючого тригера замість команди CREATE необхідно використовувати команду ALTER, причому при завданні імені тригера використання компоненти простір_імен стає обов'язковим.

Розглянемо загальний вид створення / зміни DDL і LOGON тригерів:

DDL тригер:

CREATE TRIGGER назва_тригера

ON { ALL SERVER | DATABASE }

[WITH

{ ENCRYPTION |

EXEC[UTE] AS {CALLER | SELF | {‘ім'я_користувача’ | ‘login_name’}}

}[,]

]

{ FOR [AFTER]}

{тип_події | група подій}[,]

AS

{

Перелік_команд_SQL |

EXTERNAL NAME ім'я_складання.ім'я_класу.назва_методу [;]

}

LOGON тригер:

CREATE TRIGGER назва_тригера

ON ALL SERVER

[WITH

{ ENCRYPTION |

EXEC[UTE] AS {CALLER | SELF ‘login_name’}

}[,]

]

{ FOR [AFTER]} LOGON

AS

{

Перелік_команд_SQL |

EXTERNAL NAME ім'я_складання.ім'я_класу.назва_методу [;]

}

У випадку зміни вже існуючого DDL або LOGON тригера замість команди CREATE необхідно використовувати команду ALTER.

Розглянемо більш докладно синтаксис створення | зміни тригерів, причому слід зазначити подібність синтаксису команди CREATE | ALTER при створенні | зміні для всіх видів тригерів:

1. ON ім'я_об'єкта. Ця секція команди показує для якого об'єкта(ів) створюється тригер. У випадку DML тригерів необхідно вказати або ім'я таблиці (не можна вказувати локальні або глобальні тимчасові таблиці), або ім'я подання, причому для подання можна створити тільки INSTEAD OF тригер (виконується замість обраної дії(й)). Для DDL тригерів як ім'я об'єкта можна вказати або рівень бази даних (DATABASE), або рівень сервера БД (ALL SERVER). Залежно від обраного рівня будуть доступні різні події (групи), для яких можна створити тригер. Для LOGON тригерів як ім'я об'єкта можна вказати тільки рівень сервера БД (ALL SERVER).

2. WITH список_опцій. Використання опції ENCRIPTION приводить до того, що текст команди створення тригера шифрується, що не дозволяє його переглядати. Ця опція не може бути зазначена для CLR тригерів (тригерів, написаних мовою, що підтримує технологію .NET Framework).

3. EXEC[UTE] AS. Визначає контекст виконання для тригера. Можливі наступні опції: CALLER (значення за замовчуванням) - показує, що всі команди в модулі (тригері) виконуються від імені користувача, дії якого привели до виклику тригера. Слід зазначити, що цей користувач повинен мати відповідні права на доступ не тільки до тригера, але й до всіх об'єктів, з якими тригер працює під час свого виконання. SELF - еквівалентно вказівці імені користувача, що створив або змінив даний тригер. OWNER - показує, що всі команди даного тригера виконуються в контексті (від імені) користувача, що є власником тригера. Якщо тригер не має власника, то ним є той користувач, що є власником схеми даних, у яку входить тригер. Ця опція не може бути використана для DDL і LOGON тригерів. ІМ'Я_КОРИСТУВАЧА | LOGIN_NAME - указує ім'я користувача (для LOGON тригерів необхідно використовувати ім'я login(ім'я, під яким користувач з'єднується із СУБД)) від імені якого будуть виконуватися команди тригера. Цей користувач повинен мати відповідні права доступу до використовуваних об'єктів.

4. {FOR [AFTER] | INSTEAD OF} – показує, коли буде виконаний тригер: після дії, на яку тригер реагує (FOR [AFTER], причому слово AFTER є необов'язковим) або замість цієї дії (INSTEAD OF). Слід зазначити, що DML тригери для подань можуть бути тільки INSTEAD OF, у той час як DDL і LOGON тригери можуть виконувати тільки після дії (FOR [AFTER]).

5. ДІЯ показує в якому випадку(ах) тригер буде виконуватися. Для DML тригерів дією може бути виконання однієї з команд INSERT, UPDATE, DELETE, причому тригер може реагувати як на одну з перерахованих команд, так і на будь-яку пару команд або навіть на всі команди. Для DDL тригерів вказується ідентифікатор групи подій (нумерація груп проставлена з урахуванням вкладеності груп) або події (Табл.1):

Таблиця 1.

Перелік ідентифікаторів груп подій і подій,

використовуваних при створенні (зміні) DDL тригерів.

№	Ідентифікатор групи	Опис	Підлеглі ідентифікатори подій
1	DDL_SERVER_LEVEL_EVENTS	Команди створення/зміни/видалення БД: {CREATE | ALTER | DROP} DATABASE	CREATE_DATABASE
			ALTER_DATABASE
			DROP_DATABASE
1.1	DDL_ENDPOINT_EVENTS	Команди над точками доступу (програмна одиниця, доступна по зазначених мережних протоколах і яка має певні властивості): {CREATE | ALTER | DROP} ENDPOINT	CREATE_ENDPOINT
			ALTER_ENDPOINT
			DROP_ENDPOINT
1.2	DDL_EVENTS_SEQURITY_EVENTS	Операції, пов'язані з авторизацією користувачів і питаннями безпеки
1.2.1	DDL_LOGIN_EVENTS	Команди для створення/зміни/видалення логінів користувачів: {CREATE | ALTER | DROP} LOGIN або системні процедури: sp_addlogin, sp_grantlogin, xp_grantlogin, sp_denylogin (для неіснуючого login) | sp_defaultdb, sp_defaultlanguage, sp_password, sp_change_user_login (коли зазначено Auto_Fix) | sp_droplogin, sp_revokelogin, xp_revokelogin	CREATE_LOGIN
			ALTER_LOGIN
			DROP_LOGIN
1.2.2	DDL_GDR_SERVER_EVENTS	Операції з дозволу або заборони дій для користувача стосовно сервера БД (DENY - позбавляє користувача використовувати якусь можливість; REVOKE - видаляє для користувача інформацію про заборону / дозвіл використання якої-небудь можливості): {GRANT | DENY | REVOKE} SERVER	GRANT_SERVER
			DENY_SERVER
			REVOKE_SERVER
1.2.3	DDL_AUTORIZATION_SERVER_EVENTS	Зміна власника для сервера: ALTER AUTORIZATION … ON SERVER	ALTER_AUTHORIZATION_SERVER
1.3	DDL_DATABASE_LEVEL_EVENTS	Дії в межах якої-небудь БД
1.3.1	DDL_TABLE_VIEW_EVENTS	Команди для створення/зміни/видалення таблиць, подань, індексів, статистик
1.3.1.1	DDL_TABLE_EVENTS	Команди для створення/зміни/видалення структури таблиць: {CREATE | ALTER | DROP} TABLE	CREATE_TABLE
			ALTER_TABLE
			DROP_TABLE
1.3.1.2	DDL_VIEW_EVENTS	Команди для створення/зміни/видалення подань: {CREATE | ALTER | DROP} VIEW	CREATE_VIEW
			ALTER_VIEW
			DROP_VIEW
1.3.1.3	DDL_INDEX_EVENTS	Команди для створення/зміни/видалення індексів: {CREATE | ALTER | DROP | CREATE XML} INDEX	CREATE_INDEX
			ALTER_INDEX
			DROP_INDEX
1.3.1.4	DDL_STATISTICS_EVENTS	Команди для створення/зміни/видалення статистики: {CREATE | UPDATE | DROP} STATISTICS	CREATE_STATISTICS
			ALTER_STATISTICS
			DROP_STATISTICS
1.3.2.	DDL_SYNONYM_EVENTS	Команди створення / видалення синонімів для яких-небудь об'єктів: {CREATE | DROP} SYNONYM	CREATE_SYNONYM
			DROP_SYNONYM
1.3.3.	DDL_FUNCTION_EVENTS	Команди для створення/зміни/видалення функцій: {CREATE | ALTER | DROP} FUNCTION	CREATE_FUNCTION
			ALTER_FUNCTION
			DROP_FUNCTION
1.3.4	DDL_PROCEDURE_EVENTS	Команди для створення/зміни/видалення збережених процедур: {CREATE | ALTER | DROP} PROCEDURE	CREATE_PROCEDURE
			ALTER_PROCEDURE
			DROP_PROCEDURE
1.3.5	DDL_TRIGGER _EVENTS	Команди для створення/зміни/видалення тригерів: {CREATE | ALTER | DROP} TRIGGER	CREATE_TRIGGER
			ALTER_TRIGGER
			DROP_TRIGGER
1.3.6	DDL_EVENT_NOTIFICATION_EVENTS	Команди створення / видалення об'єктів, які посилають інформацію про події в межах сервера або БД обраному сервісу (broker service): {CREATE | DROP} EVENT NOTIFICATION	CREATE_EVENT_NOTIFICATION
			DROP_EVENT_NOTIFICATION
1.3.7	DDL_ASSEMBLY_EVENTS	Команди для створення/зміни/ видалення зборок (створення модуля, що містить інформацію про метадані і «керований» код (написаний з використанням CLR)): {CREATE | ALTER | DROP} ASSEMBLY	CREATE_ASSEMBLY
			ALTER_ASSEMBLY
			DROP_ASSEMBLY
1.3.8	DDL_TYPE_EVENTS	Команди створення / видалення користувальницьких типів даних: {CREATE | DROP} TYPE або системні процедури: sp_addtype | sp_droptype	CREATE_TYPE
			DROP_TYPE
1.4	DDL_DATABASE_SEQURITY_EVENTS	Команди керування безпекою на рівні БД
1.4.1	DDL_CERTIFICATE_EVENTS	Команди для створення/зміни/видалення сертифікатів (програмна одиниця, відповідальна за безпеку та використовує стандарт X.509): {CREATE | ALTER | DROP} CERTIFICATE	CREATE_CERTIFICATE
			ALTER_CERTIFICATE
			DROP_CERTIFICATE
1.4.2	DDL_USER_EVENTS	Команди для створення/зміни/ видалення користувача: {CREATE | ALTER | DROP} USER або системні процедури: sp_adduser, sp_grantdbaccess | | sp_dropuser, sp_revokerdbaccess	CREATE_USER
			ALTER_USER
			DROP_USER
1.4.3	DDL_ROLE_EVENTS	Команди для створення/зміни/ видалення ролі (набору припустимих привілеїв): {CREATE | ALTER | DROP} ROLE або системні процедури: sp_addrole і sp_addgroup | | sp_droprole і sp_dropgroup	CREATE_ROLE
			ALTER_ROLE
			DROP_ROLE
1.4.4	DDL_APPLICATION_ROLE_EVENTS	Команди для створення/зміни/ видалення ролі для додатка (набору припустимих привілеїв): {CREATE | ALTER | DROP} APPLICATION ROLE або аналогічні системні процедури: sp_addapprole | sp_approlepassword | sp_dropapprole	CREATE_APPLICATION_ROLE
			ALTER_APPLICATION_ROLE
			DROP_APPLICATION_ROLE
1.4.5	DDL_SCHEMA_EVENTS	Команди для створення/зміни/видалення простору імен (схеми): {CREATE | ALTER | DROP} SCHEMA або системні процедури: sp_addrole, sp_adduser, sp_addgroup, sp_grantdbaccess | sp_changeobjectowner	CREATE_SCHEMA
			ALTER_SCHEMA
			DROP_SCHEMA
1.4.6	DDL_GDR_DATABASE_EVENTS	Операції з дозволу або забороні дій для користувача стосовно БД (DENY - позбавляє користувача використовувати якусь можливість; REVOKE - видаляє для користувача інформацію про заборону / дозвіл використання якої-небудь можливості): {GRANT | DENY | REVOKE} DATABASE	GRANT_DATABASE
			DENY_DATABASE
			REVOKE_DATABASE
1.4.7	DDL_AUTHORIZATION_DATABASE_EVENTS	Зміна власника для БД: ALTER AUTORIZATION … ON DATABASE або системна процедура sp_changedbowner	ALTER_AUTHORIZATION_DATABASE
1.5	DDL_SSB_EVENTS	Команди для роботи з повідомленнями, чергами, сервісами й т.п.
1.5.1	DDL_MESSAGE_TYPE_EVENTS	Команди для створення/зміни/ видалення нових типів повідомлень, які можуть використовувати сервіси: {CREATE | ALTER | DROP} MESSAGE TYPE	CREATE_MESSAGE_TYPE
			ALTER_MESSAGE_TYPE
			DROP_MESSAGE_TYPE
1.5.2	DDL_CONTRACT_EVENTS	Команди створення / видалення контрактів (контракт визначає тип повідомлень, якими можна обмінюватися з Service Broker, а також визначає, яка сторона може відправляти ці повідомлення): {CREATE | DROP} CONTRACT	CREATE_CONTRACT
			DROP_CONTRACT
1.5.3	DDL_QUEUE_EVENTS	Команди для створення/зміни/ видалення черг повідомлень від сервісів до БД, що зберігає повідомлення (Service Broker поміщає повідомлення у відповідну чергу): {CREATE | ALTER | DROP} QUEUE	CREATE_QUEUE
			ALTER_QUEUE
			DROP_QUEUE
1.5.4	DDL_SERVICE_EVENTS	Команди для створення/зміни/ видалення сервісів (сервіс – ім'я певного завдання або групи завдань, пов'язаний із чергою й управляється Service Broker): {CREATE | ALTER | DROP} SERVICE	CREATE_SERVICE
			ALTER_SERVICE
			DROP_SERVICE
1.5.5	DDL_ROUTE_EVENTS	Команди для створення/зміни/ видалення шляхів (мережна адреса, що визначає Service Broker якогось екземпляра MS SQL Server) у таблиці шляхів: {CREATE | ALTER | DROP} ROUTE	CREATE_ROUTE
			ALTER_ROUTE
			DROP_ROUTE
1.5.6	DDL_REMOTE_SERVICE_BINDING	Команди для створення/зміни/ видалення з'єднання для обміну інформацією з віддаленим сервісом: {CREATE | ALTER | DROP} REMOTE SERVICE BINDING	CREATE_REMOTE_SERVICE_BINDING
			ALTER_REMOTE_SERVICE_BINDING
			DROP_REMOTE_SERVICE_BINDING
1.6	DDL_XML_SCHEMA_COLLECTION_EVENTS	Команди для створення/зміни/ видалення схем XML колекцій: {CREATE | ALTER | DROP} XML SCHEMA COLLECTION	CREATE_XML_SCHEMA_COLLECTION
			ALTER_XML_SCHEMA_COLLECTION
			DROP_XML_SCHEMA_COLLECTION
1.7	DDL_PARTITION_EVENTS	Команди для роботи з розподіленими функціями й схемами даних
1.7.1	DDL_PARTITION_FUNCTION_EVENTS	Команди для створення/зміни/ видалення розподілених функцій (функції, які, відображають набір рядків вихідної таблиці у вигляді декількох наборів рядків, імітуючи розподілену таблицю): {CREATE | ALTER | DROP} PARTITION FUNCTION	CREATE_PARTITION_FUNCTION
			ALTER_PARTITION_FUNCTION
			DROP_PARTITION_FUNCTION
1.7.2	DDL_PARTITION_SCHEME_EVENTS	Команди для створення/зміни/ видалення розподіленого простору імен (схеми), пов'язаної з розподіленою функцією й правила, що описує, відображення даних, що повертаються функцією на файлові групи: {CREATE | ALTER | DROP} PARTITION SCHEME	CREATE_PARTITION_SCHEME
			ALTER_PARTITION_SCHEME
			DROP_PARTITION_SCHEME

Номера груп подій показують підпорядкованість однієї групи іншої (наприклад, група 1.1 підлегла(вкладена) у групу 1 і т.д.). Групи подій з номерами 1 - 1.2.3 описують події для всього сервера, а інші групи подій - подій рівня БД.

Для LOGON тригерів вказується ключове слово LOGON.

6. WITH APPEND. Застосовується тільки для DML тригерів і показує, що можна додати додатковий тригер існуючого типу ( що реагує на певний набір дій з множині INSERT, UPDATE, DELETE). Ця опція необхідна для рівня сумісності 65 і нижче, у випадку ж використання рівня сумісності 70 і вище вона використовується за замовчуванням (Microsoft обіцяє забрати із синтаксису команди цю опцію в нових версіях MS SQL Server).

7. NOT FOR REPLICATION. Ця опція застосовується тільки для DML тригерів і показує, що тригер не буде запускатися під час процесу реплікації (дублювання) даних.

8. AS – ключове слово, за яким ідуть команди, що становлять тіло тригера. Якщо команд більше однієї, то вони повинні бути взяті в операторні дужки BEGIN…END, що позначають, що ці команди є одним блоком (пакетом). У тілі DML тригерів неприпустиме використання наступних команд: ALTER DATABASE, CREATE DATABASE, DROP DATABASE, LOAD DATABASE, RESTORE DATABASE, LOAD LOG, RESTORE LOG, RECONFIGURE. Крім того неприпустимі в тілі DML тригерів команди, що випливають, коли вони відносяться до таблиці або подання, на якій(ому) виконалася (повинна була виконатися) дія, що привела до активації тригера (це обмеження уведене в MS SQL Server 2005, однак воно діє, якщо рівень сумісності встановлений у значення 80): CREATE INDEX, ALTER INDEX, DROP INDEX, DBCC DBREINDEX, ALTER PARTITION FUNCTION, DROP TABLE, ALTER TABLE (Коли ця команда виконує одну з наступних дій: додає, модифікує або видаляє стовпець, перемикає розділи(partition), додає або видаляє обмеження PRIMARY KEY або UNIQUE).

9. EXTERNAL NAME. Після цих ключових слів іде повне ім'я (включаючи ім'я зборки та ім'я класу) методу, що написаний мовою високого рівня, що підтримує CLR, і є тілом тригера.

При написанні тіла DML тригерів можна використовувати спеціальні функції COLUMNS_UPDATED() і UPDATE(ім'я_стовпця), а також дві спеціальні таблиці inserted і deleted. Їхнє застосування дозволяє визначити, яка дія викликала активацію тригера, якщо тригер може бути активований різними командами. У випадку ж використання INSTEAD OF тригера дані в таблиці або поданні не змінюються, тому що тригер викликаний замість дії, що його активувала. Використання ж таблиць inserted і deleted дозволяє визначити, як дані повинні були б змінитися.

Функція COLUMNS_UPDATED() повертає значення типу varbinary, що представляє собою набір байт, кожний з яких представляє інформацію про зміну значення групи з 8-ми стовпців. При цьому 1-ий байт представляє цю інформацію для 1-ой групи з 8-ми стовпців і т.д. У кожному байті молодший біт (нульовий) представляє інформацію про зміну 1-ого стовпця групи, 1-ий біт – 2-ого стовпця і т.д. Якщо який-небудь стовпець змінився, то відповідний йому біт буде дорівнювати 1, інакше 0. Функція COLUMNS_UPDATED() видає ті самі значення незалежно від того, чи змінилося в результаті виконання команди UPDATE хоча б одне значення в обновлюваних стовпцях, чи ні. При активації тригера командою INSERT функція COLUMNS_UPDATED() повертає значення, що відповідає зміні ВСІХ стовпців таблиці або подання.

Функція UPDATE(ім'я_стовпця) поводиться аналогічно функції COLUMNS_UPDATED(), однак має наступні відмінності: застосовна тільки до одного стовпця і повертає значення TRUE, якщо стовпець змінився, і FALSE - у противному випадку. Цю функцію можна послідовно застосовувати в умовному операторі IF для перевірки зміни декількох стовпців.

Таблиці inserted і deleted є тимчасовими таблицями, що зберігаються в пам'яті, створюваними при запуску DML тригера автоматично. Їх структуру і дані в них не можна змінювати, створювати індекси для цих таблиць також неприпустимо, їх використання можливо ТІЛЬКИ в тілі DML тригерів. Таблиця deleted містить рядки, які були вилучені або рядки, які були оновлені командою UPDATE, причому в останньому випадку для обновлюваних стовпців утримуються їхні первісні значення. Таблиця inserted містить рядки, що додаються в таблицю, (команда INSERT) або обновлювані рядки, причому в останньому випадку в обновлюваних стовпцях цієї таблиці містяться нові значення. Слід зазначити, що для INSTEAD OF тригерів одержати змінені/додані значення можна ТІЛЬКИ з таблиці inserted, а набір рядків, що видаляються - ТІЛЬКИ з таблиці deleted. Якщо в результаті виконання якої-небудь із команд, що повинна була привести до спрацьовування тригера, жоден рядок (значення в рядку) у таблиці (поданні) не був змінений, то тригер однаково буде викликаний. При цьому кількість рядків у таблицях inserted і deleted буде дорівнювати 0.

В MS SQL Server 2005 не допускаються посилання на стовпці з типами даних text, ntext і image у таблицях inserted і deleted для AFTER тригерів, у той час як типів даних varchar(max), nvarchar(max), vrabinary(max) це обмеження не стосується.

Таким чином, можна сформулювати наступні правила, по яких можна визначити яка дія активувала тригер, якщо тригер може бути активований декількома командами:

1. Якщо функція COLUMNS_UPDATED() повернула значення 0, то тригер був активований командою видалення(DELETE), відповідно кількість рядків у таблиці deleted буде відповідати кількості рядків, що видаляються.

2. Якщо функція COLUMNS_UPDATED() повернула значення не 0, то тригер був активований або командою INSERT, або командою UPDATE.

   0. Якщо в таблиці inserted  ненульова кількість рядків, а таблиця deleted – не містить рядків, то тригер був активований командою INSERT.

   1. Якщо таблиці inserted і deleted містять однакову ненульову кількість рядків або таблиці inserted і deleted містять нульову кількість рядків і функція COLUMNS_UPDATED() повернула деяке значення , що задовольняє нерівності , де - кількість стовпців у таблиці або в поданні, то тригер був активований командою UPDATE.

   2. Якщо таблиці inserted і deleted містять нульову кількість рядків і функція COLUMNS_UPDATED() повернула деяке значення , таке що , то визначити яка з команд INSERT або UPDATE активувала тригер не представляється можливим, тому що команда UPDATE може змінювати значення у всіх стовпцях, а команда INSERT може не вставити ні одного рядка.

При написанні DDL тригерів, як і у випадку з DML тригерами, виникає необхідність визначення того, яка саме подія активувала тригер. Для цих цілей використовується функція EVENTDATA(). Ця функція може бути використана тільки в тілі DDL або LOGON тригера (у противному випадку вона повертає NULL, навіть якщо використовується в збереженій процедурі, що викликає відповідний тригер). Дані, що повертаються цією функцією, втрачають свою актуальність, якщо відбувся відкат транзакціії, у якій була викликана функція EVENTDATA().

Слід зазначити, що ця функція повертає результат своєї роботи у вигляді xml даних, представлених в юнікоді. При цьому допускається використання тільки наступних кодів символів: 0x0009, 0x000A, 0x000D, 0x0020..0xD7FF, 0xE000..0xFFFD. Всі інші символи вважаються неприпустимими і відображаються за допомогою символу ?.

Функція EVENTDATA() повертає xml дані, що містять інформацію про тип події, що активировали тригер, час його виникнення, SPID (System Process ID) з'єднання, коли тригер був викликаний. Залежно від типу події може повертатися додаткова інформація про нього, наприклад: назва бази даних, у якій ця подія відбулася, назва об'єкта, якого ця подія стосується, команда T-SQL, що привела до виникнення цієї події.

Всі ці дані передаються усередині елемента <EVENT_INSTANCE>...</EVENT_INSTANCE>. Наприклад, для події ALTER_TABLE цей елемент має такий вигляд:

<EVENT_INSTANCE>

    <EventType>type</EventType>

    <PostTime>date-time</PostTime>

    <SPID>spid</SPID>

    <ServerName>name</ServerName>

<LoginName>name</LoginName>

<UserName>name</UserName>

<DatabaseName>name</DatabaseName>

<SchemaName>name</SchemaName>

<ObjectName>name</ObjectName>

<ObjectType>type</ObjectType>

<TSQLCommand>command</TSQLCommand>

</EVENT_INSTANCE>

Для інших подій можуть змінюватися назви елементів і їх кількість, якщо, інформація, що повертається для події, відрізняється від інформації, що повертається для події ALTER_TABLE. У документації для кожної події описаний перелік всіх його елементів і типи даних цих елементів.

При створенні | зміні тригерів потрібно враховувати, що:

1. Команда {CREATE | ALTER} TRIGGER повинна бути 1-ою командою в пакеті команд.

2. Тригер створюється тільки в поточній БД, однак може посилатися на об'єкти з інших БД.

3. Команда SET може бути використана в тілі тригера, але всі установки, зроблені за її допомогою мають силу тільки на час роботи тригера. По його завершенню всі настроювання автоматично вертаються в первісний стан.

4. Рекомендується не використовувати в тригері команд, які приводять до виводу даних (наприклад, SELECT - у випадку, коли вона не є під запитом, і PRINT).

5. Для AFTER тригерів за допомогою процедури sp_settriggerorder можна встановити 1-ий і останній тригер, що буде спрацьовувати як реакція на обрану дію. Виклик цієї процедури має такий вигляд:

sp_settriggerorder [ @triggername = ] '[ простір_імен. ] ім'я_тригера'

       , [ @order = ] 'значення'

         , [ @stmttype = ] 'тип_команди'

         [ , [ @namespace = ] { 'DATABASE' | 'SERVER' | NULL } ]

де @triggername – задає ім'я тригера, причому простір імен може бути зазначено тільки для DML тригерів.

@order – визначає послідовність спрацьовування тригера, має тип даних varchar(10) і може приймати значення: ‘First’ – тригер спрацьовує першим, ‘Last’ – тригер спрацьовує останнім, ‘None’ – порядок спрацьовування тригера не визначений. Перший і останній тригери повинні ОБОВ'ЯЗКОВО відрізнятися і можна описати тільки один перший і один останній тригери для якої-небудь дії.

@stmttype – описує тип дії, для якої встановлює порядок виконання тригерів, має тип даних varchar(50) і може мати наступні значення: ‘INSERT’, ‘UPDATE’, ‘DELETE’, ‘LOGON’ або назва кожного з типів подій, припустимих при створенні DDL тригера.

@namespace – задає рівень DDL тригера: DATABASE або SERVER. Для LOGON тригерів можна вказати тільки SERVER, для DML тригерів - або не вказувати останній параметр, або вказати значення NULL.

При зміні тригера, що має атрибут First або Last командою ALTER TRIGGER, цей атрибут автоматично скидається і вимагає своєї повторної установки за допомогою процедури sp_settriggerorder.

6. При створенні тригерів у їхньому тілі допускається звертатися до таблиць, яких ще немає в момент створення тригера. Однак, у момент спрацьовування тригера такі таблиці повинні бути вже створені, інакше буде отримане повідомлення про помилку.

7. Допускається створення рекурсивних тригерів, якщо опція RECURSIVE_TRIGGERS для БД установлена в значення enabled. Рекурсія буває 2-ух видів - прямою і непрямою. Пряма рекурсія, наприклад, має місце у випадку, коли додаток змінює значення в якомусь стовпці таблиці, що приводить до спрацьовування тригера, що, у свою чергу, також міняє значення в якомусь стовпці таблиці, що знову приводить до спрацьовування цього ж тригера і т.д. Непряма рекурсія, наприклад, має місце у випадку, коли додаток змінює значення в якомусь стовпці таблиці T1, що приводить до спрацьовування тригера TR1, що, у свою чергу змінює значення в якому-небудь стовпці таблиці T2, що приводить до спрацьовування тригера TR2, що змінює значення в якому-небудь стовпці таблиці T1, що знову приводить до спрацьовування тригера TR1 і т.д. Для того, щоб відключити непряму рекурсію, необхідно встановити значення опції сервера nested triggers (відповідає за можливість непрямих рекурсивних викликів, кількість яких не може перевищувати 32) в 0 (що також приведе до відключення прямої рекурсії для тригерів). Ця опція не впливає на поводження INSTEAD OF тригерів. За замовчуванням непряма рекурсія дозволена (значення 1).

При створенні | зміні DML тригерів потрібно також ураховувати, що:

1. Тригер може бути зв'язаний тільки з однією таблицею або поданням.

2. Для подання можна створити ТІЛЬКИ INSTEAD OF тригер.

3. INSTEAD OF тригер не може бути створений для таблиці, що має обмеження FOREIGN KEY з опцією CASCADE для дій DELETE або UPDATE.

4. Якщо при створенні тригера був зазначений простір імен, то в тілі тригера при звертанні до використовуваних об'єктів також необхідно вказувати їхній простір імен.

5. Для таблиці або подання може бути описаний тригер, що реагує відразу на кілька команд.

6. Може бути описано кілька тригерів, що реагують на той самий набір команд, при цьому вони будуть викликані в порядку їхнього створення.

7. SQL Server не підтримує користувальницькі тригери для системних таблиць, тому не рекомендується такі тригери створювати.

8. Команди TRUNCATE TABLE і WRITETEXT не приводять до спрацьовування тригерів.

При створенні | зміні DDL тригерів потрібно також ураховувати, що:

1. DDL тригери не прив'язані до простору імен (schema), отже, для одержання метаданих про ці тригери не можуть бути використані функції OBJECT_ID, OBJECT_NAME, OBJECT_PROPERTY і OBJECT_PROPERTYEX. Замість цього потрібно використовувати подання sys.triggers, sys.trigger_events, sys.sql_modules, sys.assembly_modules для тригерів рівня БД і подання sys.server_triggers, sys.server_trigger_events, sys.server_sql_modules, sys.server_assembly_modules для тригерів рівня сервера.

2. DDL тригери не спрацьовують внаслідок дій, що стосуються локальних і глобальних тимчасових таблиць і збережених процедур.