Creating Triggers in SQL Server 2005

One of the excellent features provided by SQL Server 2005 (code named Yukon) is its integration
with the .NET CLR which makes it possible for us to author triggers, stored procedures, user
defined functions, and create other database objects using a managed language such as
VB.NET, C#, and so on. This approach provides a number of benefits such as increased
productivity, significant performance gains and the ability to leverage the features of .NET Code
Access Security to prevent assemblies from performing certain operations and so on. In this
article, we will take a look at this new CLR integration feature and learn how to create triggers in
SQL Server using a managed language. Along the way, we will also learn how the features of
.NET code access security can be leveraged to better control the assembly execution
environment. Finally, we will discuss when to use T-SQL and when to use a .NET language when
creating SQL Server triggers.

.NET CLR and SQL Server Integration

In previous versions of SQL Server, database programmers were limited to using Transact-SQL
when creating server side objects such as triggers, stored procedures, and user defined functions
and so on. But now with the integration of SQL Server with .NET CLR, it opens up a whole
avenue of opportunities. Before we talk about the features of .NET CLR integration with SQL
Server, let us understand the limitations of T-SQL when it comes to creating server side objects.

Transact-SQL (T-SQL) is an extension of the Structured Query Language as defined by the

International Standards Organization (ISO) and the American National Standards Institute (ANSI).
Using T-SQL, database developers can create, modify and delete databases and tables, as well
as insert, retrieve, modify and delete data stored in a database. T-SQL is specifically designed for
direct data access and manipulation. While T-SQL can be very useful for data access and
management, it is not a full-fledged programming language in the way that Visual Basic .NET and
C# are. For example, T-SQL does not support arrays, strongly typed objects, collections, for each
loops, bit shifting or classes and so on. While some of these constructs can be simulated in T-
SQL, managed code based languages such as VB.NET or C# have first-class support for these
constructs. Now that we have understood the limitations of T-SQL, let us talk about the
advantages of .NET CLR integration with SQL Server.

With CLR integration, things have changed dramatically. The CLR provides the execution
environment for all the server side objects that are created using a .NET language. This means
the database developers can now perform tasks that were impossible or difficult to achieve with
T-SQL alone. Especially when working with large amounts of server code, developers can easily
organize and maintain your code investments. By allowing the code to run under the control of
.NET CLR, you can also leverage the code access security features of .NET. For example, before
executing code, the CLR can check to see if the code is safe. This process is known as
"verification." During verification, the CLR performs several checks to ensure that the code is safe
to run. For example, the code is checked to ensure that no memory is read that has not be been
written to. The CLR will also prevent buffer overflows. Now that we have had a complete overview
of the .NET CLR integration, let us understand the steps to be followed for creating a trigger in
VB.NET.

Creating a Trigger using Managed Code in SQL Server

As you may know, triggers are executed as the result of a user action against a table, such as an
INSERT, UPDATE or DELETE statement. To create a trigger using a managed language such as
C# or VB.NET, you need to go through the following steps.

• Create a .NET class and implement the functionality of the extended trigger within that
class.
• Compile that class to produce a .NET assembly.
 • Register that assembly in SQL Server using the Create Assembly statement.
• Create trigger definitions. As part of this, you also associate the trigger with the actual
methods in the assembly. Once this is done, the triggers are configured and can be
invoked automatically like any other triggers.

In the next section, we will take an in-depth look at the above steps and understand what it takes
to create a trigger using C#.

Implementation of .NET class that will act as an extended Trigger

Before we go onto creating the .NET class that will implement the functionalities of the trigger, let
us create a simple table named Users using the following DDL statement.

CREATE TABLE Users

(UserName Varchar (100) )

Now that we have created the table, let us create the C# class that implements the functionalities
required of the trigger. Towards this end, we will create a C# class named Users and modify its
code to look like the following code.

using System.Data;
using System.Data.Sql;
using System.Data.SqlServer;
public class Users
{
public static void InsertTrigger()
{
SqlTriggerContext triggerContext = SqlContext.GetTriggerContext();
SqlPipe sqlPipe = SqlContext.GetPipe();
SqlCommand command = SqlContext.GetCommand();
if (triggerContext.TriggerAction ==
System.Data.Sql.TriggerAction.Insert)
{
command.CommandText = "SELECT * FROM INSERTED";
sqlPipe.Execute(command);
}
}
}

Let us walk through the above code. To execute .NET code in SQL server, you need to reference
the System.Data.Sql and System.Data.SqlServer namespaces. Then we declare a class named
Users that is mainly used to implement the trigger functionalities for the Users table. Then we get
reference to the current trigger context by invoking the GetTriggerContext method of the
SqlContext class. The SqlTriggerContext object enables the code to access the virtual table that's
created during the execution of the trigger. This virtual table stores the data that caused the
trigger to fire. The SqlPipe object enables the extended trigger to communicate with the external
caller. To get reference to the SqlPipe object, we invoke the GetPipe method of the SqlContext
class. Once we have reference to the SqlPipe object, we can then return tabular results and
messages to the client. In this example, the SqlTriggerContext object is used to first determine if
the trigger action was an insert operation. If so, then the contents of the virtual trigger table are
retrieved and sent to the caller.

Compilation of .NET class to create a .NET Assembly

Now that we have created the C# class, let us compile that class to produce a .NET assembly,
which can then be registered with SQL Server. The following screenshot shows how to compile
the C# class to produce the .NET assembly.

As shown in above screenshot, we need to reference the sqlaccess.dll since our code uses the
classes contained in the System.Data.SqlServer namespaces.

Registering the assembly in SQL Server

When writing managed code, the deployment unit is called an assembly. An assembly is
packaged as a DLL or executable (EXE) file. While an executable can run on its own, a DLL must
be hosted in an existing application. Managed DLL assemblies can be loaded into and hosted by
Microsoft SQL Server. To load an assembly into SQL Server, you need to use the Create
Assembly statement.

CREATE ASSEMBLY Users

FROM 'C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\Binn\Test\CLRProcedures\CS\Users.dll'

The FROM clause specifies the pathname of the assembly to load. This path can either be a
UNC path or a physical file path that is local to the machine. The above statement will register the
assembly with the SQL Server. Note that the assembly name should be unique within a database.
Once you load the assembly, a copy of the assembly is loaded into SQL Server. After that, if you
want to make changes to the assembly, you need to drop the assembly first and then reregister
that with SQL Server again. To drop an assembly from SQL Server, you need to use the Drop
Assembly statement. For example, to drop the assembly that we created earlier, we need to use
the following command.

DROP ASSEMBLY Users

Loading an assembly into Microsoft SQL Server is the first step in exposing the functionality that
the assembly provides. Now that we have loaded the assembly, the next step is to associate an
extended trigger to a specific method of the class that is contained in the assembly.

Creating Trigger Definitions

In this step, we will create an extended trigger using the Create Trigger statement. SQL Server
2005 supports a new clause named External Name that allows you to reference a method in the
registered assembly. By referencing this method, we hook the trigger to that method in the
assembly.
CREATE TRIGGER InsertTrigger
ON Users
FOR INSERT
AS
EXTERNAL NAME
Users:[Users]::InsertTrigger

For the purposes of this example, we will use the InsertTrigger method in the Users class. In the
above code, External Name clause uses the following syntax.

[Name of the Assembly]:[Name of the Class]::[Name of the Method]

Now that the trigger is created, let us test the trigger by using the following Insert statement that
inserts a row into the Users table.

Insert Users Values('TestUser')

You will see the output as shown in the following screenshot.

So far, we have seen the steps involved in creating the trigger and executing that trigger from
SQL Server Workbench. Now let us demonstrate how to execute the same Insert statement from
a C# Windows forms application and get the resultset returned by the trigger and then display it in
the screen.

Creating a Windows Forms Client Application that executes the SQL Statement
Now we will create a simple Windows Forms to execute the insert SQL statement that we used in
the previous step. To this end, let us create a new Visual C# Windows Forms application. After
the project is created, open up the design view of the Form1. To the form, add a command button
and name it as btnInsertUser. Then modify the Click event of the command button to look like the
code shown below.

private void btnInsertUser_Click(object sender, System.EventArgs e)

{
string connString =
"server=localhost;uid=sa;pwd=thiru;database=Test;";
using (SqlConnection conn = new SqlConnection(connString))
{
string sql = "Insert into Users Values ('TestUser')";
SqlDataAdapter adapter = new SqlDataAdapter(sql,conn);
adapter.SelectCommand.CommandType = CommandType.Text;
DataSet insertTriggerDataSet = new DataSet();
adapter.Fill(insertTriggerDataSet);
grdUsers.DataSource = insertTriggerDataSet.Tables[0].DefaultView;
}
}

The above code is very simple and straightforward. We simply execute the Insert statement and
that will invoke automatically invoke the trigger. To start with, we declare a variable named
connString and assign the connection string to the database to that variable. Then we create a
new SqlConnection object passing in the connection string as an argument to its constructor.
Then we create a SqlDataAdapter object and supply the sql statement and the previously created
SqlConnection object as its arguments. Finally, we execute the sql statement by invoking the Fill
method of the SqlDataAdapter object. Once we get the results in the form of a DataSet object, we
then bind the results of the DataSet to a DataGrid control. If you run the application and click on
the command button, you will get an output as similar to the following.
In the above screen, when you click on the Insert Users hyperlink, it will not only execute the sql
statement, but will also invoke the trigger and the results of the trigger execution are sent to the
client application, which are then displayed in the data grid control.

Advanced Operations in an Extended Trigger

So far, we have seen the steps involved in creating an extended trigger and indirectly invoking
that from a client application. In this section, we will enhance our previous example by adding the
following two capabilities.

• Validate the email address specified by the users.

• If the email address is invalid, we will then send out confirmation email to those users.

For this example, let us create a new class named UsersValidation and add the following lines of
code to it.

using System.Data;
using System.Data.Sql;
using System.Data.SqlServer;
using System.Web.Mail;
using System.Text.RegularExpressions;

public class UsersValidation

{
public static void InsertTrigger()
{
SqlTriggerContext triggerContext = SqlContext.GetTriggerContext();
SqlPipe sqlPipe = SqlContext.GetPipe();
SqlCommand command = SqlContext.GetCommand();
if (triggerContext.TriggerAction ==
System.Data.Sql.TriggerAction.Insert)
{
command.CommandText = "SELECT * FROM INSERTED";
SqlDataRecord record = command.ExecuteRow();
string userName = (string)record[0];
sqlPipe.Execute(command);
if (CheckEMailAddress(userName))
{
MailMessage mail = new MailMessage();
mail.From = "[email protected]";
mail.To = userName;
mail.Body = "Your Registration has been successfully
recieved";
mail.BodyFormat = MailFormat.Html;
//Send the mail
SmtpMail.Send(mail);
}
else
throw new System.Exception ("Invalid user name");
}
}

public static bool CheckEMailAddress(string email)

{
return Regex.IsMatch(email,
@"([\w-]+\.)*?[\w-]+@[\w-]+\.([\w-]+\.)*?[\w]+$");
}
}

As you can see from the above code, it is very similar to our previous example. It simply get the
supplied user name from the Inserted table by executing the ExecuteRow method of the
SqlCommand object. It first stores the results of the statement execution in an SqlDataRecord
object and then moves the results into a local variable named username. After that, the variable is
supplied to a static function named CheckEMailAddress, which validates the supplied user name.
If the user name is a valid email address, the code then sends an email to that user providing a
confirmation of the registration. Otherwise it simply throws an exception to the caller by creating
an exception object and throwing it back.

Now that we have created the class, let us compile it as shown in the following screenshot.

Once the C# class is compiled into a .NET assembly, let us register it in the SQL Server using the
Create Assembly statement.

CREATE ASSEMBLY UsersValidation

FROM 'C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\Binn\Test\CLRProcedures\CS\UsersValidation.dll'
WITH PERMISSION_SET = UNSAFE

Note that in the above code, we added a new clause named WITH PERMISSION_SET to the
Create Assembly statement. The PERMISSION_SET clause allows you to specify the level of
security in which your code will be executed.

When loading an assembly into SQL Server, you can specify any one of the following 3 values for
PERMISSION_SET:

• SAFE - It is the default permission set and with this mode, the assembly can only do
computation and data access within the server via the in-process managed provider.
• EXTERNAL_ACCESS - This permission set is typically useful in scenarios where the
code needs to access resources outside the server such as files, network, registry and
environment variables. Whenever the server accesses an external resource, it
impersonates the security context of the user calling the managed code.
• UNSAFE - It is used in situations where an assembly is not verifiably safe or requires
additional access to restricted resources, such as the Win32 API.

In our example, since we want to send out email from within the trigger, we set the
PERMISSION_SET to UNSAFE. Now that we have created the assembly, let us create the trigger
definition using the Create Trigger statement.
CREATE TRIGGER InsertTrigger
ON Users
FOR INSERT
AS
EXTERNAL NAME
UsersValidation:[UsersValidation]::InsertTrigger

Now that the trigger is created, let us test the trigger by using the following Insert statement that
inserts a row into the Users table.

Insert Users Values('[email protected]')

The above sql statement will not only insert the data into the Users table, but will also trigger an
email to be sent to [email protected].

Creating DDL Triggers in Managed Code

Another new and excellent feature of SQL Server 2005 is that it allows us to hook triggers on to
DDL constructs as well. This means you can write logic in a trigger that will be executed when
someone performs DDL operations (such as CREATE TABLE, and ALTER TABLE) in your
database. However one issue with this approach is that how do we know what happened when a
DDL trigger fires - after all we won't get any entries in the INSERTED and DELETED tables. So
somehow the database engine needs to deliver the trigger reason (or context) to the trigger. It
does this by making the data accessible in the form of an XML document. Let us create a simple
example trigger to illustrate this. For the purposes of this example, let us create a new C# class
named TableTrigger and modify the class to look like the following.

using System.Data;
using System.Data.Sql;
using System.Data.SqlServer;
using System.Xml;
using System.IO;
using System.Diagnostics;

public class TableTrigger

{
public static void AddTable()
{
SqlTriggerContext ctx = SqlContext.GetTriggerContext();
XmlDocument doc = new XmlDocument();
if (ctx.TriggerAction == TriggerAction.CreateTable)
{
string s = new string(ctx.EventData.Value);
StringReader r = new StringReader(s);
XmlReader reader = new XmlTextReader(r);
doc.Load(reader);
reader.Dispose();
EventLog evt = new EventLog("Application", ".",
"Create Table Audit");
evt.WriteEntry(string.Format("XML {0} created in ",
doc.OuterXml));
}
}
}
In the above code, we utilize the SqlTriggerContext object to find out if the trigger is invoked by
someone executing the CREATE TABLE statement. If that is the case, we then use the
EventData property of the SqlTriggerContext to get reference to the actual XML that was created.
Then we first load that information into a StringReader object and then onto a XmlReader object.
Finally, we extract the content of the XmlDocument object and write that information onto the
Application event log.

Now that the C# class is created, let us compile that class into a .NET assembly. Once the
assembly is created, we can register the assembly into SQL Server using the following statement.

CREATE ASSEMBLY TableTrigger

FROM 'C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\Binn\Test\CLRProcedures\CS\TableTrigger.dll'
WITH PERMISSION_SET =UNSAFE

Now create the trigger definition and associate the trigger with the AddTable method in the
TableTrigger class using the following statement.

CREATE TRIGGER TableTrigger

ON DATABASE FOR CREATE_TABLE
AS EXTERNAL NAME TableTrigger:TableTrigger::AddTable

Now that we have completed all the steps, let us test the trigger by executing the following
CREATE TABLE statement.

CREATE TABLE Test

(TestColumn Varchar(100) )

When you execute the above statement, you will find that the trigger caused an entry to be
recorded in the application event log.
If you take a closer look at the above entry, you will find that the create table statement has
resulted in the following the XML document.

<EVENT_INSTANCE>
<PostTime>2004-07-14T23:11:18.517</PostTime>
<SPID>55</SPID>
<EventType>CREATE_TABLE</EventType>
<ServerName>THIRU-SERVER1</ServerName>
<LoginName>sa</LoginName>
<UserName>sa</UserName>
<DatabaseName>Test</DatabaseName>
<SchemaName>dbo</SchemaName>
<ObjectName>XmlLog</ObjectName>
<ObjectType>TABLE</ObjectType>
<TSQLCommand>
<SetOptions ANSI_NULLS="ON" ANSI_NULL_DEFAULT="ON"
ANSI_PADDING="ON" QUOTED_IDENTIFIER="ON" ENCRYPTED="FALSE" />
<CommandText>create table XmlLog (TestColumn
nvarchar)</CommandText>
</TSQLCommand>
</EVENT_INSTANCE>

Once you have the information in the form of an XmlDocument, you can then parse that
information and execute code based on that information.

Transact-SQL versus Managed Code

With the introduction of the ability to write server side objects using a .NET compliant language,
developers are presented with one more way to write triggers. This flexibility also poses some
important challenges in deciding when to use T-SQL and when to use the managed language.
This is an important decision that the developers need to make while defining their application
architectures. There is no straight answer to this question but it depends on the particular
situation. In some situations, you'll want to use T-SQL; in other situations, you will want to use
managed code. T-SQL is best used in situations where the code will mostly perform data access
with little or no procedural logic. Managed code is best suited for CPU intensive computations
and server side objects where complex logic needs to be created. Another reason you might want
to consider using managed code is the ability to leverage the rich features and object model
supported by the .NET Framework's Base Class Library. The location in which the code gets
executed is also an important factor to consider. By writing server side objects such as triggers
using a .NET language you can move some of your middle tier code to the server side objects.
This will also allow you to take full advantage of the processing power of the database server. On
the other hand, you may wish to avoid placing processor intensive tasks on your database server.
Most client machines today are very powerful, and you may wish to take advantage of this
processing power by placing as much code as possible on the client. To summarize,

• Choose T-SQL for data-access tasks that contain little or no procedural code.
• Choose managed code when the task is computationally expensive and will be
performed often; as such, it will benefit from compiled code.
• Locate the managed code on the server side if the data returned to the client can be
substantially reduced by pre-processing it on the server.
• Locate the managed code on the client when the data returned is small or the client can
perform processing in an asynchronous manner without compromising the performance
of the application.
• Always conduct performance testing and compare the various options available.
• Use performance-monitoring tools to avoid overloading the server CPU; upgrade where
possible to higher-end processors.

Conclusion

The closer integration of the .NET CLR and the SQL Server database engine provide developers
with a whole new range of choices when writing data-access code and manipulating data. Proper
use of managed code and choosing the best-performing physical location allows database
developers to write applications that perform and scale better. Access to the BCL and
enhancements to the IDE will make developers more productive, allowing them to concentrate on
implementing business-specific solutions. With all of these enhancements, writing database
objects will become easier, allowing more developers to become familiar with database
interaction.
DDL Trigger:

CREATE TRIGGER ddl_trig_loginAW

ON ALL SERVER
FOR DDL_LOGIN_EVENTS
AS
PRINT 'Added trigger event to DDLServerTriggerData'
INSERT INTO [AdventureWorks].[dbo].[dbo.DDLServerTriggerData]
(DDLServerEvent) VALUES ( EVENTDATA())