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.
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.
sp_configure 'clr enable', 1
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
- 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:
public class BaseFunctionClass
#region "Default Constructor"
#region "Welcome Function"
public static void GetMessage(SqlString strName, out SqlString
strMessge = "Welcome," + strName + ", " + "your code is getting
executed under CLR !";
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
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
Now register ManagedCodeAndSQLServer.dll under that using the following code:
CREATE ASSEMBLY ManagedCodeAndSQLServer
WITH PERMISSION_SET = UNSAFE
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
WITH PERMISSION_SET = UNSAFE
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:
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
AS EXTERNAL NAME ManagedCodeAndSQLServer.[ManagedCodeAndSQLServer.
To execute the procedure:
DECLARE @msg varchar(MAX)
EXEC usp_UseHelloDotNetAssembly 'Kittu And Tannu',@msg output
You will get the following output: Welcome, Kittu And Tannu, your code is getting executed under CLR !
Try it and enjoy!