Execute .NET Code under SQL Server 2005

Introduction

First of all, I would like to congratulate the Microsoft Development Team for their superb and innovative technology using which we can use managed code written in any of the .NET supported languages in Microsoft SQL Server 2005 Stored Procedures. If I make it simple, then "Now you can call any function written in .NET class library in your SQL Server stored procedure". This technology will allow us to use the features of .NET language with the extendibility of SQL Server.

Description

I got an article of using MSMQ from SQL Server in CodeProject written by a gentlemen regarding MSMQ, and Messaging was used from SQL SP. I tried to show the constraints and limitations of using such assemblies and the required configuration in SQL Server 2005, so that the developers can begin. And I am sharing the practical problems which I faced in the actual implementation of this.
Before starting, you have to enable the managed code execution feature of the SQL Server which is disabled by default. To enable it, execute the following code as a query in your SQL Server query editor.

Collapse

sp_configure 'clr enable', 1

GO

RECONFIGURE

GO

Now your server is ready to run managed code under its runtime. But let me tell you it's not magic but it's the same technology being used by the .NET framework. The only important part is that now SQL Server is also able to execute code on CLR. Isn't it great? Before writing this article, I did a lot of research on this. I got several articles explaining the same. But I faced a lot of problems because things were scattered. Now I am trying to simulate the whole procedure in this article. I did this study because of my specific requirements. I was using Message Queuing Service of Microsoft in C# .NET. But after some time, I got a requirement in which I needed to send a message from a Stored Procedure to MSMQ Queue. And till that time for me it was possible by using the System. Messaging namespace of .NET runtime only. I know most of the developers are wondering about MSMQ. Don't worry, I won't go into details of that right now. We will start with a simple application which will use a simple string returning function of C# .NET class library. Let's start with the class library.

• Start .NET 2005 Studio.
• Open a new class library.
• Select C# as the language.
• Name the project as ManagedCodeAndSQLServer.
• By default, you will find a class named Class1.cs created for you.
• Rename it as BaseFunctionClass.cs.

Create a simple function in the class as follows:

using System;

using System.Collections.Generic;

using System.Text;

using System.IO;

using System.Data.SqlTypes;

using System.Data.SqlClient;

using Microsoft.SqlServer.Server;

namespace ManagedCodeAndSQLServer

{

    public class BaseFunctionClass

    {

        #region "Default Constructor"

        public BaseFunctionClass()

        { 

        }

        #endregion

        #region "Welcome Function"

        /// <summary>

        /// This function will be called from the SQL Stored Procedure.

        /// </summary>

        /// <param name=""strName"">Name</param>

        /// <returns>Welcome Message</returns>

        [SqlProcedure]

        public static void GetMessage(SqlString strName, out SqlString  

        strMessge)

        {

          strMessge = "Welcome," + strName + ", " + "your code is getting

          executed under CLR !";

        }

        #endregion

    }

}

Important Points

I hope you are able to notice some new things in the above code. First of all, the [SqlProcedure] attribute on the GetMessage function intimates the CLR that the function is callable from SQL Server Stored procedure. The things that I am telling you are my own experiences; you may not find these things in articles published on the Internet. When using a CLR function, you must remember that the SQL server nvarchar is equivalent to System.String. But the most important part is that "CLR enabled procedure can only return Int32, Int and void data types". That's why I have used output parameter with the GetMessage function. Also I have used SqlString instead of System.String. Please keep all the above things in mind.
Now build the project and leave it because your work from the .NET class library point of view is over. Now come to your SQL Server again. I hope you still remember that we enabled CLR integration in our server at the start of the article. If not, then don't wait for me to come and enable it.
We have to register ManagedCodeAndSQLServer.dll as an assembly in our database. To register the assembly, you should have owner rights in your database or you should be the local system admin or Server Admin. The assemblies that we are going to register should be registered in UnSafe mode. Otherwise they would not be able to access resources external to SQL Server 2005. And to register an unsafe assembly, you should have 'unsafe' rights enabled in your username or role. All the above things are very important so take care of them, otherwise you won't be able to register your assembly. So create a database 'TestingCLR'. Before registering the .NET assembly in the database, you have to set the trustworthy option of the database on using the following code:

ALTER DATABASE TestingCLR SET TRUSTWORTHY ON

GO

Now register ManagedCodeAndSQLServer.dll under that using the following code:
 

CREATE ASSEMBLY ManagedCodeAndSQLServer

AUTHORIZATION dbo

FROM 'E:\Important\SQL\ManagedCodeAndSQLServer\ManagedCodeAndSQLServer\bin\

Debug\ManagedCodeAndSQLServer.dll'

WITH PERMISSION_SET = UNSAFE

GO

I am again saying if the dbo is not having 'unsafe assembly' right, it won't work. Similarly if I am using a specific class of .NET in my DLL, I have to register it prior to DLL registration in the same way. For example, I am using System.Messaging in my assembly, then I have to register it using the following code:

CREATE ASSEMBLY Messaging

AUTHORIZATION dbo

FROM 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Messaging.dll'

WITH PERMISSION_SET = UNSAFE

GO

To use the normal functionality, we need not register the DLL from .NET runtime as in our case. Now in your server explorer, go to your TestingCLR database, select Programmability and in Assemblies, you will find an assembly registered with the name given by you, i.e., "HelloDotNet". Now you are almost done. You should know the full path (namespace convention) of the function that you are going to use from that assembly. In our case, it is: ManagedCodeAndSQLServer.BaseFunctionClass and GetMessage is our function to be used. Now I am creating a simple Stored Procedure to use this assembly as follows:

CREATE PROCEDURE usp_UseHelloDotNetAssembly

@name nvarchar(200),

@msg nvarchar(MAX)OUTPUT

AS EXTERNAL NAME ManagedCodeAndSQLServer.[ManagedCodeAndSQLServer.

BaseFunctionClass].GetMessage

GO

To execute the procedure:

DECLARE @msg varchar(MAX)

EXEC usp_UseHelloDotNetAssembly 'Kittu And Tannu',@msg output

PRINT @msg

You will get the following output: Welcome, Kittu And Tannu, your code is getting executed under CLR !
Try it and enjoy!