Microsoft SQL Server 2005 Developer’s Guide- P5 docx

To enable SQL Server’s CLR support, you need to use the advanced options of SQL Server’s sp_configure system stored procedure, as shown in the following listing: sp_configure 'show advan

CLR Architecture

The NET Framework CLR is very tightly integrated with the SQL Server 2005

database engine In fact, the SQL Server database engine hosts the CLR This tight

level of integration gives SQL Server 2005 several distinct advantages over the NET integration that’s provided by DB2 and Oracle You can see an overview of the SQL Server 2005 database engine and CLR integration in Figure 3-1

As you can see in Figure 3-1, the CLR is hosted within the SQL Server database

engine A SQL Server database uses a special API or hosting layer to communicate

with the CLR and interface the CLR with the Windows operating system

Hosting the CLR within the SQL Server database gives the SQL Server database

engine the ability to control several important aspects of the CLR, including

䉴 Threading

䉴 Garbage collection

The DB2 and Oracle implementation both use the CLR as an external process,

which means that the CLR and the database engine both compete for system

resources SQL Server 2005’s in-process hosting of the CLR provides several

important advantages over the external implementation used by Oracle or DB2 First, in-process hosting enables SQL Server to control the execution of the CLR, putting

SQL Server Engine

SQL Server OS

Windows

CLR

Hosting Layer

Figure 3-1 The SQL Server CLR database architecture

essential functions such as memory management, garbage collection, and threading under the control of the SQL Server database engine In an external implementation the CLR will manage these things independently The database engine has a better view of the system requirements as a whole and can manage memory and threads better than the CLR can do on its own In the end, hosting the CLR in-process will provide better performance and scalability

Enabling CLR Support

By default, the CLR support in the SQL Server database engine is turned off This ensures that update installations of SQL Server do not unintentionally introduce new functionality without the explicit involvement of the administrator To enable SQL Server’s CLR support, you need to use the advanced options of SQL Server’s sp_configure system stored procedure, as shown in the following listing:

sp_configure 'show advanced options', 1

GO

RECONFIGURE

GO

sp_configure 'clr enabled', 1

GO

RECONFIGURE

GO

CLR Database Object Components

To create NET database objects, you start by writing managed code in any one of the NET languages, such as VB, C#, or Managed C++, and compile it into a NET DLL (dynamic link library) The most common way to do this would be to use Visual Studio 2005 to create a new SQL Server project and then build that project, which creates the DLL Alternatively, you create the NET code using your editor of choice and then compiling the code into a NET DLL using the NET Framework SDK ADO.NET is the middleware that connects the CLR DLL to the SQL Server database Once the NET DLL has been created, you need to register that DLL with SQL

Server, creating a new SQL Server database object called an assembly The assembly

essentially encapsulates the NET DLL You then create a new database object such as

a stored procedure or a trigger that points to the SQL Server assembly You can see an overview of the process to create a CLR database object in Figure 3-2

SQL Server NET Data Provider

If you’re familiar with ADO.NET, you may wonder exactly how CLR database

objects connect to the database After all, ADO.NET makes its database connection

using client-based NET data providers such as the NET Framework Data Provider

for SQL Server, which connects using networked libraries While that’s great for

a client application, going through the system’s networking support for a database

call isn’t the most efficient mode for code that’s running directly on the server To

address this issue, Microsoft created the new SQL Server NET Data Provider The

SQL Server NET Data Provider establishes an in-memory connection to the SQL

Server database

Assemblies

After the coding for the CLR object has been completed, you can use that code to

create a SQL Server assembly If you’re using Visual Studio 2005, then you can

simply select the Deploy option, which will take care of both creating the SQL

Server assembly as well as creating the target database object

If you’re not using Visual Studio 2005 or you want to perform the deployment

process manually, then you need to copy the NET DLL to a common storage

location of your choice Then, using SQL Server Management Studio, you can

execute a T-SQL CREATE ASSEMBLY statement that references the location of the .NET DLL, as you can see in the following listing:

CREATE ASSEMBLY MyCLRDLL

FROM '\\SERVERNAME\CodeLibrary\MyCLRDLL.dll'

Code database object using managed code and complie to DLL

Register DLL with SOL Server using T-SQL create assembly

Create database object using T-SQL Create

Figure 3-2 Creating CLR database objects

The CREATE ASSEMBLY command takes a parameter that contains the path

to the DLL that will be loaded into SQL Server This can be a local path, but more often it will be a path to a networked file share When the CREATE ASSEMBLY is executed, the DLL is copied into the master database

If an assembly is updated or becomes deprecated, then you can remove the assembly using the DROP ASSEMBLY command as follows:

DROP ASSEMBLY MyCLRDLL

Because assemblies are stored in the database, when the source code for that assembly is modified and the assembly is recompiled, the assembly must first

be dropped from the database using the DROP ASSEMBLY command and then reloaded using the CREATE ASSEMBLY command before the updates will be reflected in the SQL Server database objects

You can use the sys.assemblies view to view the assemblies that have been added

to SQL Server 2005 as shown here:

SELECT * FROM sys.assemblies

Since assemblies are created using external files, you may also want to view the files that were used to create those assemblies You can do that using the sys assembly_files view as shown here:

SELECT * FROM sys.assembly_files

Creating CLR Database Objects

After the SQL Server assembly is created, you can then use SQL Server

Management Studio to execute a T-SQL CREATE PROCEDURE, CREATE

TRIGGER, CREATE FUNCTION, CREATE TYPE, or CREATE AGGREGATE statement that uses the EXTERNAL NAME clause to point to the assembly that you created earlier

When the assembly is created, the DLL is copied into the target SQL Server database and the assembly is registered The following code illustrates creating the MyCLRProc stored procedure that uses the MyCLRDLL assembly:

CREATE PROCEDURE MyCLRProc

AS EXTERNAL NAME

MyCLRDLL.StoredProcedures.MyCLRProc

The EXTERNAL NAME clause is new to SQL Server 2005 Here the

EXTERNAL NAME clause specifies that the stored procedure MyCLRProc will

be created using a SQL Server assembly The DLL that is encapsulated in the SQL

Server assembly can contain multiple classes and methods; the EXTERNAL NAME statement uses the following syntax to identify the correct class and method to use

from the assembly:

Assembly Name.ClassName.MethodName

In the case of the preceding example, the registered assembly is named

MyCLRDLL The class within the assembly is StoredProcedures, and the method

within that class that will be executed is MyCLRProc

Specific examples showing how you actually go about creating a new managed

code project with Visual Studio 2005 are presented in the next section

Creating CLR Database Objects

The preceding section presented an overview of the process along with some

example manual CLR database object creation steps to help you better understand

the creation and deployment process for CLR database objects However, while

it’s possible to create CLR database objects manually, that’s definitely not the most

productive method The Visual Studio 2005 Professional, Enterprise, and Team

System Editions all have tools that help create CLR database objects as well as

deploy and debug them In the next part of this chapter you’ll see how to create each

of the new CLR database objects using Visual Studio 2005

NOTE

The creation of SQL Server projects is supported in Visual Studio 2005 Professional Edition and

higher It is not present in Visual Studio Standard Edition or the earlier releases of Visual Studio.

CLR Stored Procedures

Stored procedures are one of the most common database objects that you’ll want to

create using one of the managed NET languages One of the best uses for CLR stored procedures is to replace existing extended stored procedures T-SQL is only able to

access database resources In order to access external system resources, Microsoft has

provided support in SQL Server for a feature known as extended stored procedures

Extended stored procedures are unmanaged DLLs that run in the SQL Server process

space and can basically do anything a standard executable program can do, including

accessing system resources that are external to the database, such as reading and writing to the file system, reading and writing to the Registry, and accessing the network However, because extended stored procedures run in the same process space

as the SQL Server database engine, bugs, memory violations, and memory leaks in the extended stored procedure could potentially affect the SQL Server database engine CLR stored procedures solve this problem because they are implemented as managed code and run within the confines of the CLR Another good candidate for CLR stored procedures is to replace existing T-SQL stored procedures that contain complex logic and embody business rules that are difficult to express in T-SQL CLR stored procedures can take advantage of the built-in functionality provided by the classes in the NET Framework, making it relatively easy to add functionality such as complex mathematical expressions or data encryption Plus, since CLR stored procedure are compiled rather than interpreted like T-SQL, they can provide a significant

performance advantage for code that’s executed multiple times However, CLR stored procedures are not intended to be used as a replacement for T-SQL stored procedures T-SQL stored procedures are still best for data-centric procedures

To create a CLR stored procedure in Visual Studio 2005, first select the New | Project option and then select the SQL Server Project template as is shown in Figure 3-3 Give your project a name and click OK to create the project In this example you can see that I’ve used the name usp_ImportFile for my stored procedure This stored

Figure 3-3 Creating a new SQL Server stored procedure project

procedure shows how you can replace an extended stored procedure with a CLR

stored procedure In this case the CLR stored procedure will read the contents of a

file and store it in a SQL Server column After naming the project, click OK Before Visual Studio generates the project code, it displays the New Database Reference

dialog that you can see in Figure 3-4

Visual Studio 2005 uses the New Database Reference dialog to create a connection

to your SQL Server 2005 system That connection will be used to both debug and

deploy the finished project Drop down the Server Name box and select the name

of the SQL Server that you want to use with this project Then select the type of

Figure 3-4 The New Database Reference dialog

authentication that you want to use and the database where the CLR stored procedure will be deployed In Figure 3-4 you can see that I’ve selected the SQL Server system named SQL2005 The project will connect using Windows authentication, and the stored procedure will be deployed to the AdventureWorks database You can verify the connection properties by clicking the Test Connection button Once the connection properties are set up the way you want, click OK All of the required references will automatically be added to your SQL Server project, and Visual Studio 2005 will generate a SQL Server starter project

NOTE

While Visual Studio 2005 lets you group multiple stored procedures, triggers, and other CLR database objects in a single DLL, it’s really better to create each CLR database object as a separate DLL This gives you more granular control in managing and later updating the individual database objects.

Next, to create the CLR stored procedure, you can select the Project | Add Stored Procedure option to display the Visual Studio installed templates dialog that’s shown

in Figure 3-5

Figure 3-5 Adding a CLR stored procedure

From the Add New Item dialog, select the Stored Procedure option from the list

of templates displayed in the Templates list and then provide the name of the stored

procedure in the Name field that you can see at the bottom of the screen Here you can see that the stored procedure will be created using the source file usp_ImportFile.vb

Visual Studio 2005 will add a new class to your project for the stored procedure The

generated class file is named after your stored procedure name and will include all of

the required import directives as well as the starter code for the stored procedure You

can see the SQL Server CLR stored procedure template in Figure 3-6

By default the SQL Server NET Data Provider is added as a reference, along with

an include statement for its System.Data.SqlServer namespace Plus, you can see the System.Data reference, which provides support for ADO.NET and its data-oriented

objects such as the DataSet and the System.Data.SqlTypes namespace that provides

support for the SQL Server data types

Figure 3-6 The CLR stored procedure template

It’s up to you to fill in the rest of the code that makes the stored procedure work The following example illustrates the source code required to create a simple CLR stored procedure that imports the contents of a file into a varchar or text column:

Imports System

Imports System.Data

Imports System.Data.Sql

Imports System.Data.SqlTypes

Imports Microsoft.SqlServer.Server

Imports System.IO

Partial Public Class StoredProcedures

<Microsoft.SqlServer.Server.SqlProcedure()> _

Public Shared Sub usp_ImportFile _

(ByVal sInputFile As String, ByRef sColumn As String)

Dim sContents As String

Try

Dim stmReader As New StreamReader(sInputFile)

sContents = stmReader.ReadToEnd()

stmReader.Close()

sColumn = sContents

Catch ex As Exception

Dim sp As SqlPipe = SqlContext.Pipe()

sp.Send(ex.Message)

End Try

End Sub

End Class

The first important point to note in this code is the directive that imports the Microsoft.SqlServer.Server namespace This enables the usp_ImportFile project to use the SQL Server NET Data Provider without always needing to reference the fully qualified name The second thing to notice is the <Microsoft.SqlServer.Server SqlProcedure()> attribute that precedes the method name; it tells the compiler this method will be exposed as a SQL Server stored procedure Next, you can see that the default class name for this stored procedure is set to StoredProcedures This class contains a shared method named usp_ImportFile that accepts two parameters:

a string that specifies the name of the file that will be imported and a second input parameter that specifies the name of a column that will contain the contents of the file For C#, the method must be defined as static For VB.NET code, the method would need to be defined as Shared

Inside the usp_ImportFile method, a new string object named sContents is declared that will contain the contents of the file Next, a Try-Catch loop is used to