Stored Procedure in SQL Server 2005
Stored Procedure in SQL Server 2005
SQL Server 2005's (formerly code named Yukon) integration with the .NET CLR makes it possible
for developers to author stored procedures, triggers, user defined functions, and create other
database objects using a managed language such as VB.NET or C#. This excellent feature
provides a number of benefits, including increased productivity, significant performance gains,
and the ability to leverage the features of .NET Code Access Security to prevent assemblies from
performing certain operations. This article takes a look at this new CLR integration feature so you
can understand how to create stored procedures in SQL Server using a managed language.
You'll also see how to leverage.NET code access security to better control the assembly
execution environment. Despite the benefits, it isn't appropriate to use .NET code for every stored
procedure you write, so you'll see how to decide when to use T-SQL and when to use a .NET
language for creating SQL Server stored procedures.
With CLR integration, things have changed dramatically. The CLR provides the execution
environment for all the server side objects created using a .NET language. This means that
database developers can now perform tasks that were impossible or difficult to achieve with T-
SQL alone. The new integration allows you to more easily organize and maintain your code
investments, especially when working with large amounts of server code. Unlike traditional stored
procedures, this approach lets developers create code utilizing object-oriented concepts such as
encapsulation. By allowing the code to run under the control of .NET CLR, you can also leverage
the code access security features of .NET. 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, it checks the code to ensure
that it doesn't try to read from memory to which it has not written. The CLR will also prevent buffer
overflows.
• Create a .NET class and implement the functionality of the stored procedure within that
class
• Compile that class to produce a .NET assembly
• Register that assembly in SQL Server using the Create Assembly statement
• Create stored procedure definitions. As part of this, you also associate the stored
procedure with the actual methods in the assembly.
After completing these steps, the stored procedures are configured and you can execute them
just like any other stored procedure.
Implementing a .NET Class-Based Stored Procedure
Start by creating the VB.NET class that implements the stored procedure functionality. For this
example, create a VB.NET class named AddressType that contains the following code (the
downloadable code provides both VB.NET and C# examples).
Imports System.Data
Imports System.Data.Sql
Imports System.Data.SqlServer
End Class
To execute .NET code in SQL server, you need to reference the System.Data.Sql and
System.Data.SqlServer namespaces. The AddressType class contains one method,
GetAddressTypeDetails, which uses the ID passed as a parameter to retrieve a row from the
AddressType table in the AdventureWorks database that ships with SQL Server 2005. The code
gets a reference to the SqlPipe object by invoking the GetPipe method of the SqlContext class.
You then use that SqlPipe reference to return tabular results and messages to the client using the
SqlPipe.Send method. By calling the various overloads of the Send method, you can transmit
data through the pipe to the calling application. Some of the overloaded versions of the Send
method are:
To start, create a new class named AddressTypeID and add a method named
GetAddressTypeIDByName as shown in the following code.
Imports System.Data.Sql
Imports System.Data.SqlServer