Data Modification Language (DML) Triggers in SQL

November 19, 2014 0 Comments

A DML trigger is fired when data in the underlying table is affected by DML statements, such as INSERT, UPDATE, or DELETE. These triggers help in maintaining consistent, reliable, and correct data in tables. They enable the performance of complex action and cascade these actions to other dependent tables. Cascading is the process of reflecting the changes made in a table in the other related tables.
The DML triggers have the following characteristics:
Fired automatically by the SQL Server whenever any data modification statement is issued.
Cannot be explicitly invoked or executed, as in the case of the stored procedures.
Prevents incorrect, unauthorized, and inconsistent changes in data.
Cannot return data to the user.
Can be nested up to 32 levels. The nesting of triggers occurs when a trigger performs an action that initiates another trigger.

Whenever a trigger is fired in response to the INSERT, DELETE, or UPDATE statement, the SQL Server creates two temporary tables, called magic tables. The magic tables are called inserted and deleted. The magic tables are conceptual tables and are similar in structure to the table on which the trigger is defined.
The inserted tale contains a copy of all records that are inserted in the trigger table. The Deleted table contains all records that have been deleted from the trigger table. Whenever you update data in a table, the trigger uses both the inserted and the deleted tables.
Depending on the operation that is performed, the DML trigger can be further categorized as:
Insert trigger: is fired whenever and attempt is made to insert a row in the trigger table. When an INSERT statement is executed, a new row is added to both the trigger and the inserted tables.
Delete trigger: is fired whenever an attempt is made to delete a row from the trigger table. When a DELETE statement is executed, the specified rows from the trigger table are deleted and are added to the deleted table. The deleted and trigger tables do not have any rows in common, as in the case of the inserted and trigger tables.
There are three ways of implementing referential integrity by using a DELETE trigger. These are:
The cascade method: Deletes records from the dependent tables whenever a record is deleted from the master table.
The restrict method: Restricts the deletion of records from the master table if the related records are present in the dependent tables.
The nullify method: Nullifies the values in the specified columns of the dependent tables whenever a record is deleted form the master table.
Update trigger: Is fired when a UPDATE statement is executed in the trigger table. It uses two logical tables for its operations, the deleted table that contains the original rows (the rows with the values before updating) and the inserted table that stores the new tows (the modified rows). After all the rows are updated, the deleted and inserted tables are populated and the trigger is fired.
For example, you have a table with three columns. The table stores the details of hardware devices. You updated a value in column 2 from ‘Printer’ to ‘Lex New Printer’. During the update process, the deleted table holds the original row (the row with the values before updating), and inserted table stores the new row (the modified row) with the value ‘Lex New Printer’ in Column2.

Rhett Butler

Some say he’s half man half fish, others say he’s more of a seventy/thirty split. Either way he’s a fishy bastard. Google