Creating Triggers in SQL Server 2005
One of the excellent features provided by SQL Server 2005 (code named Yukon) is its integrationwith 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 asVB.NET, C#, and so on. This approach provides a number of benefits such as increasedproductivity, significant performance gains and the ability to leverage the features of .NET CodeAccess Security to prevent assemblies from performing certain operations and so on. In thisarticle, we will take a look at this new CLR integration feature and learn how to create triggers inSQL 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 executionenvironment. Finally, we will discuss when to use T-SQL and when to use a .NET language whencreating SQL Server triggers.
.NET CLR and SQL Server Integration
In previous versions of SQL Server, database programmers were limited to using Transact-SQLwhen creating server side objects such as triggers, stored procedures, and user defined functionsand so on. But now with the integration of SQL Server with .NET CLR, it opens up a wholeavenue of opportunities. Before we talk about the features of .NET CLR integration with SQLServer, 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 theInternational Standards Organization (ISO) and the American National Standards Institute (ANSI).Using T-SQL, database developers can create, modify and delete databases and tables, as wellas 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 andmanagement, it is not a full-fledged programming language in the way that Visual Basic .NET andC# are. For example, T-SQL does not support arrays, strongly typed objects, collections, for eachloops, 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 theseconstructs. Now that we have understood the limitations of T-SQL, let us talk about theadvantages of .NET CLR integration with SQL Server.With CLR integration, things have changed dramatically. The CLR provides the executionenvironment for all the server side objects that are created using a .NET language. This meansthe database developers can now perform tasks that were impossible or difficult to achieve withT-SQL alone. Especially when working with large amounts of server code, developers can easilyorganize 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, beforeexecuting 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 safeto run. For example, the code is checked to ensure that no memory is read that has not be beenwritten to. The CLR will also prevent buffer overflows. Now that we have had a complete overviewof the .NET CLR integration, let us understand the steps to be followed for creating a trigger inVB.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 anINSERT, UPDATE or DELETE statement. To create a trigger using a managed language such asC# or VB.NET, you need to go through the following steps.
Create a .NET class and implement the functionality of the extended trigger within thatclass.
Compile that class to produce a .NET assembly.