The common language runtime (CLR) allows you to write
stored procedures, triggers, userdefined functions, user-defined types,
and user-defined aggregates using a .NET programming language that can
be managed and executed from SQL Server. The purpose of this section is
not to teach you how to write CLR code, but to discuss the management
implications of using CLR in your environment.
Before you can implement CLR, you need to enable CLR integration by using the sp_configure system procedure, as shown in Listing 1. To disable CLR, change the value following the 'clr enabled' parameter from 1 to 0.
Example 1. Syntax to Enable CLR Integration Functionality
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO
|
CLR is not supported
with lightweight pooling enabled because certain features will not work
while running in fiber mode. To disable lightweight pooling, run the
script shown in Listing 2.
Example 2. Syntax to Disable Lightweight Pooling
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'lightweight pooling', 0;
GO
RECONFIGURE;
GO
|
CLR is implemented in SQL Server in the form of assemblies. An assembly
is a compiled DLL file that is hosted within SQL Server. In order to
use an assembly, you must first register it in SQL Server using the CREATE ASSEMBLY statement, as shown in Listing 3. To load a new version of an assembly, just change the CREATE keyword to ALTER.
Example 3. Syntax Used to Register an Assembly in SQL Server
CREATE ASSEMBLY CLRProcDemo
FROM 'C:\ CLRProcDemo.dll'
WITH PERMISSION_SET = EXTERNAL_ACCESS
|
You can specify three different security levels when registering an assembly: SAFE, EXTERNAL_ACCESS, and UNSAFE. SAFE is the default setting that will be applied to an assembly if the permission set is not explicitly specified. The SAFE permission set is the most restrictive, allowing only internal computations and local data access. The EXTERNAL_ACCESS permission set has the same local data access as the SAFE permission set, but the EXTERNAL_ACCESS permission set can also access external resources, such as registry keys and files. The UNSAFE permission set gives an assembly unrestricted access to internal and external resources.
If you create an assembly with a permission set other than SAFE, you have to perform one of two actions in order to run the assembly. You can either set the TRUSTWORTHY database property to ON by running the statement ALTER DATABASE DatabaseName SET TRUSTWORTY ON,
or sign the assembly with a strong key. Microsoft recommends that you
sign the assembly with a strong key instead of setting the TRUSTWORTHY property to ON.
To sign the assembly with a strong key, you need to create an
asymmetric key from the assembly, create a login from the asymmetric
key, and then grant UNSAFE or EXTERNAL_ACCESS to the login, as shown in Listing 4.
Example 4. Syntax Used to Sign an Assembly with a Strong Key
USE master
GO
CREATE ASYMMETRIC KEY CLRProcDemoKey FROM EXECUTABLE FILE = 'C:\ CLRProcDemo.dll'
CREATE LOGIN CLRDemoLogin FROM ASYMMETRIC KEY CLRProcDemoKey
GRANT EXTERNAL ACCESS ASSEMBLY TO CLRDemoLogin
GO
|
Once you have registered the assembly, you can now create an object in SQL Server that references the assembly (see Listing 5). The AssemblyName is the name that was used to register the assembly in SQL Server. In this case, the AssemblyName is CLRProcDemo that was created in Listing 3. The ClassName and MethodName
actually come from the DLL internally and are dependent on the names
that were used within the DLL. Once you have created the procedure, you
can execute it just as if it were any other stored procedure in SQL
Server.
Example 5. Syntax to Create a Stored Procedure That References an Assembly
CREATE PROCEDURE TestCLRStoredProc
AS
EXTERNAL NAME AssemblyName.ClassName.MethodName
|
To remove an assembly from the database, you can issue the DROP ASSEMBLY statement followed by the assembly name, as shown in Listing 6.
Example 6. Syntax to Remove an Assembly from a Database
DROP ASSEMBLY CLRProcDemo
