Advertisment

Using DDL triggers in SQL server

author-image
CIOL Bureau
Updated On
New Update

BANGALORE, INDIA: It has been more than two decades since Relational Database Management Systems (RDBMS) have made transition from the laboratory to becoming the data store of choice for all large and small businesses.

Advertisment

And with time, database servers are increasingly becoming sophisticated and are providing more functionalities and features to the developers, administrators and architects. It would benefit us a lot if we learn what new is coming new with each version.

In Microsoft SQL Server , the versions in use across development houses in India are primarily 2000 and 2005, and in a few cases, 2008. The move from Microsoft SQL Server 2000 to 2005 was a big leap with many new functionalities and features introduced. The concept of DDL Triggers was one such new feature.

We know about triggers as they exist in SQL Server 2000 and its previous versions ? triggers that fire in response to INSERT, UPDATE and DELETE events. They are now called as DML triggers, as they fire in response to DML events. The new triggers that we are discussing now fire in response to DDL events, for example CREATE TABLE. Hence they are called DDL triggers. The code samples presented here run on an instance of SQL Server 2008, but they would also run on SQL Server 2005 also.

Advertisment

Before we get into serious business usage, I would demonstrate a simple DDL trigger that displays a message in response to the CREATE TABLE event.

CREATE TRIGGER DDLDemo

ON DATABASE

FOR CREATE_TABLE

AS

PRINT 'Table Created!'

After the trigger has been created at the database level, let us now create a table and see if the trigger is getting executed.

Advertisment

CREATE TABLE employee

(

EmployeeID int primary key,

EmployeeName nvarchar(30)

)

As you can see, the trigger gets fired in response to any create table statement.

Advertisment

EVENTDATA

If you have used DML triggers extensively you would know there would be times when you need to know which rows are being inserted, updated or deleted; what are the old values and what are the new values. In DML triggers, we use the magic tables inserted and deleted to answer these queries.

In DDL triggers you would need to know what is the activity that is being carried out, who is carrying it out the activity, when is the activity being carried out, what is the query that is being executed, and so on.

The EVENTDATA() function answers these questions when fired from within a trigger.

Advertisment

 

Let us try it out.

ALTER TRIGGER DDLDemo

ON DATABASE

FOR CREATE_TABLE

AS

SELECT EVENTDATA()

GO

Advertisment

DROP TABLE employee

GO

CREATE TABLE employee

(

EmployeeID int primary

key,

EmployeeName nvarchar(30)

)

Advertisment

GO

When you create the table now, the trigger executes the EVENTDATA() function and displays some details:

Click on the XML link in the result. SQL Server Management Studio will open a new window with the XML results.



CREATE_TABLE

2009-05-

14T07:23:08.340

53

AMARESH\SQL2008

AMARESH\Administrator

dbo

Name>payroll

dbo

Name>employee

TABLE





CREATE TABLE employee

(

EmployeeID int primary key,

EmployeeName nvarchar(30)

)





You would see this has all the data you would need about the event that fired the trigger.

SQL Server 2005 and 2008 have a set of extensive functions that let you manipulate the results of EVENTDATA() and extract the info you are interested in. Refer to books online for details on the XML data type and the associated methods.

Applications

So where do you use DDL triggers? You can use them whenever and wherever you want to take custom actions against execution of DDL events. The following two are classic examples.

1. You want to audit various DDL events and maintain a track of who is creating, altering and dropping various database objects and when. Create a table for maintaining your audit records and insert into this table from within DDL triggers.

2. You want to enforce certain rules on various database objects.

Like, you want to enforce thatevery table being created has a primary key. In the CREATE TABLE trigger, you would then check if the table has a primary key. You will rollback the transaction if your rule is violated.

Amresh Patnaik

tech-news