Triggers en SQL PDF
Triggers en SQL PDF
Triggers en SQL PDF
Triggers are special types of Stored Procedures that are defined to execute automatically in
place of or after data modifications. They can be executed automatically on the INSERT,
There are two different types of triggers in Microsoft SQL Server 2000. They are INSTEAD OF
triggers and AFTER triggers. These triggers differ from each other in terms of their purpose
and when they are fired. In this article we shall discuss each type of trigger.
First of all, let's create a sample database with some tables and insert some sample data in
GO
USE KDMNN
GO
GO
) ON [PRIMARY]
GO
[UserID]
) ON [PRIMARY]
GO
[UserID]
) REFERENCES [dbo].[User_Master] (
[UserID]
GO
SELECT 'Murthy','Murthy'
SELECT 4,'Murthy','Belluri','[email protected]'
AFTER Triggers
The type of trigger that gets executed automatically after the statement that triggered it
completes is called an AFTER trigger. An AFTER trigger is a trigger that gets executed
Using the below script, first we shall create a trigger on the table USER_MASTER for the
Go
ON User_Master
FOR INSERT
AS
GO
BEGIN TRANSACTION
VALUES('Damerla','Damerla')
IF @ERR = 0
BEGIN
ROLLBACK TRANSACTION
END
ELSE
BEGIN
COMMIT TRANSACTION
END
Output
(1 row(s) affected)
ROLLBACK TRANSACTION
By looking at the output, we can conclude that before the transaction is rolled back or
committed, the AFTER trigger gets executed automatically. A table can have several AFTER
triggers for each of the three triggering actions i.e., INSERT, DELETE and UPDATE. Using the
below script, we shall create two triggers on the table User_Master for the INSERT triggering
action.
ON User_Master
FOR INSERT
AS
BEGIN
Print ('AFTER Trigger [trgInsert2] – Trigger executed
!!')
END
GO
ON User_Master
FOR INSERT
AS
BEGIN
END
GO
BEGIN TRANSACTION
VALUES('Damerla','Damerla')
BEGIN
ROLLBACK TRANSACTION
END
ELSE
BEGIN
COMMIT TRANSACTION
END
Output
(1 row(s) affected)
ROLLBACK TRANSACTION
From the output we can conclude that when the user tries to insert data in the table
USER_MASTER, three triggers are executed automatically. That is, you can write several
AFTER triggers on one table for each of the three triggering actions.
Similarly, we can write several AFTER triggers on DELETE and UPDATE triggering actions.
Note: If a table has multiple AFTER triggers, then you can specify which trigger should be
executed first and which trigger should be executed last using the stored procedure
sp_settriggerorder. All the other triggers are in an undefined order which you cannot control.
An AFTER trigger can be created only on tables, not on views.
Using the script below, first we shall create a simple view [vwUserMaster] which will fetch
as
GO
ON vwUserMaster
FOR INSERT
AS
BEGIN
END
GO
Output
From the Output we can conclude that we cannot create an AFTER trigger on views.
Like stored procedures and views, triggers can also be encrypted. The trigger definition is
then stored in an unreadable form. Once encrypted, the definition of the trigger cannot be
decrypted and cannot be viewed by anyone, including the owner of the trigger or the system
administrator.
FOR INSERT
AS
BEGIN
END
GO
SELECT
OBJECT_NAME(sysobjects.parent_obj) AS [Table
Name],
syscomments.encrypted AS [IsEncrpted]
FROM
WHERE
(sysobjects.xtype = 'TR')
Output
-----------------------------------------------------------
------
Since the trigger trgEncrypted is created with the option WITH ENCRYPTION, the trigger
definition is hidden and there is no way that one can easily decrypt the trigger code.
We all know that the DML statements change or modify data. Sometimes it becomes
necessary for the triggers to have the access to the changes being caused by the DML
statements. SQL Server 2000 provides four different ways to determine the affects of the
DML statements. The INSERTED and DELETED tables, popularly known as MAGIC TABLES,
and update () and columns_updated() functions can be used to determine the changes being
The below table depicts the contents of the INSERTED and DELETED tables for three different
table Events
deleted
Update Contains the rows after update Contains the rows before
update
Note that the Magic Table does not contain the information about the columns of the data-
type text, ntext, or image. Attempting to access these columns will cause an error.
The update() function is used to find whether a particular column has been updated or not.
ON User_Details
FOR UPDATE
AS
If UPDATE(FName)
BEGIN
ROLLBACK TRANSACTION
END
else If UPDATE(LName)
BEGIN
ROLLBACK TRANSACTION
END
else If UPDATE(MName)
BEGIN
ROLLBACK TRANSACTION
END
else If UPDATE(Email)
BEGIN
ROLLBACK TRANSACTION
END
GO
UPDATE User_Details
WHERE UserID = 1
Output
Depending upon the column updated, a message will be displayed. With this feature we can
determine which column in the table has been updated, and then proceed with the business
updated. This function return a hexadecimal values from which we can determine which
INSTEAD OF Triggers
A trigger which gets executed automatically in place of triggering actions i.e., INSERT,
INSTEAD OF triggers gets executed automatically before the Primary Key and the Foreign
Key constraints are checked, whereas the traditional AFTER triggers gets executed
On User_Details
FOR INSERT
AS
BEGIN
VALUES(100, 'FName','LName','MName','[email protected]')
Output
UserID 100 does not exist in the User_Master table, so the Foreign Key constraint has been
checked and an error message is displayed. What we can conclude is: AFTER triggers gets
On User_Details
INSTEAD OF INSERT
AS
BEGIN
END
Output
(1 row(s) affected)
Even if the UserID 100 does not exists in the User_Master table, the trigger gets gets
executed automatically.
on vwUserMaster
INSTEAD OF INSERT
AS
begin
End
VALUES('Damerla','Venkat')
Output
(1 row(s) affected)
So whenever a user tries to insert data into the view vwUserMaster, the INSTEAD OF trigger
In SQL SERVER 2000, views can be used to INSERT/DELETE and UPDATE the data in the
AS
SELECT
[User_Master].[Username],
[User_Master].[Password],
[User_Details].[FName],
[User_Details].[MName],
[User_Details].[LName],
[User_Details].[Email]
FROM
[User_Master], [User_Details]
WHERE
[User_Master].[UserID]=[User_Details].[UserID]
INSTEAD OF INSERT
AS
BEGIN
SELECT
@UserName = UserName,
@Password = Password,
@FName = FName,
@MName = MName,
@LName = LName,
@Email = Email
FROM INSERTED
INSERT INTO
User_Details(UserID,FName,LName,MName,Email)
VALUES(@@Identity, @FName, @LName, @MName, @Email)
END
INSERT INTO
vwUser(UserName,Password,FName,LName,MName,Email)
VALUES ('Dhananjay','Dhananjay','Dhananjay','Nagesh',NULL,
Output
(1 row(s) affected)
(1 row(s) affected)
Then check the data in the following tables User_Master and User_Details. The new row gets
A view or table can have only one INSTEAD OF trigger for each INSERT, UPDATE and DELETE
events.
We have seen that you can create any number of AFTER triggers on the table for the same
ON vwUserMaster
INSTEAD OF UPDATE
AS
BEGIN
END
ON vwUserMaster
INSTEAD OF UPDATE
AS
BEGIN
END
Output
From the output, it is clear that you cannot create two INSTEAD OF triggers on the view/
Note: An important point to be noted is that INSTEAD OF DELETE and INSTEAD OF UPDATE
At last, how would you know what are the triggers associated with the table and what type of
The solution for this question is sp_helptrigger. This stored procedure gives all the
information about the triggers such as Event on which the trigger gets executed, the type of
Sp_helptrigger User_Master
Output
trgInsert dbo 0
0 1 1 0
trgInsert2 dbo 0 0
1 1 0
trgInsert3 dbo 0 0
1 1 0
trgEncrypted dbo 0 0
1 1 0
Triggers can be used in the following scenarios, such as if the database is de-normalized and
customized messages and complex error handling are required, or if a value in one table
Triggers are a powerful tool that can be used to enforce the business rules automatically
when the data is modified. Triggers can also be used to maintain the data integrity. But they
are not to maintain data integrity. Triggers should be used to maintain the data integrity only
if you are unable to enforce the data integrity using CONSTRAINTS, RULES and DEFAULTS.