You are currently offline, waiting for your internet to reconnect

Using extended stored procedures or SP_OA stored procedures to load CLR in SQL Server is not supported

Extended support for SQL Server 2005 ends on April 12, 2016

If you are still running SQL Server 2005 after April 12, 2016, you will no longer receive security updates and technical support. We recommend upgrading to SQL Server 2014 and Azure SQL Database to achieve breakthrough performance, maintain security and compliance, and optimize your data platform infrastructure. Learn more about the options for upgrading from SQL Server 2005 to a supported version here.

This article was previously published under Q322884
SUMMARY
Microsoft does not support the use of Microsoft Common Language Runtime (included with the .NET Framework) for any COM Callable Wrapper or Managed Extensions for C++ in Microsoft SQL Server 2005, in Microsoft SQL Server 2000, or in Microsoft SQL Server 7.0. This limitation for support pertains directly to the use of extended stored procedures and to the use of OLE Automation for any loading of the libraries that you must load to run in the SQL Server memory space.

SQL Server 2005 and later versions host Common Language Runtime (CLR) and support procedures, functions, triggers, types, and aggregates that are written in CLR langauges. In these versions, you cannot load CLR by using extended stored proceduress or sp_OA stored procedures.
MORE INFORMATION
The .NET Framework assembly System.Runtime.InteropServices provides a robust environment for invoking assemblies from unmanaged code. However, there are several technical discordances between the internal implementations of CLR and SQL Server:

Threading

To increase performance, the CLR implements Thread Local Storage. For more information about issues that are related to the use of Thread Local Storage in extended stored procedures, click the following article numbers to view the articles in the Microsoft Knowledge Base:
163449 Use of Thread Local Storage in an extended stored procedure
190987 How to use extended stored procedures
Additionally, CLR uses only thread-based scheduling and does not support Fiber-mode scheduling. However, SQL Server can use Fiber-mode scheduling. To configure this property, use one of the following methods:
  • Run the sp_configure stored procedure by using the lightweight pooling option.
  • In SQL Server 2000 or in SQL Server 7.0, you can configure this property in SQL Server Enterprise Manager. To do this, follow these steps:
    1. In Enterprise Manager, expand Microsoft SQL Servers, expand SQL Server Group, and then right-click the instance of SQL Server 2000 or of SQL Server 7.0.
    2. In the SQL Server Properties (Configure) dialog box, click the Processor tab.
    3. Click to select the Use Windows NT fibers check box.
  • In SQL Server 2005, you can configure this property in SQL Server Management Studio. To do this, follow these steps:
    1. In Management Studio, connect to the instance of SQL Server 2005.
    2. In Object Explorer, right-click the SQL Server instance, and then click Properties.
    3. In the Server Properties dialog box, click Processors.
    4. Click to select the Use Windows fibers (lightweight pooling) check box.

Memory

The use of extended stored procedures and OLE Automation both run in the virtual memory address space of the memory of SQL Server. The default SQL Server memory is only a fraction of the memory that SQL Server can potentially use and CLR competes with any existing implementations for these memory resources. For more information about SQL Server memory management, click the following article number to view the article in the Microsoft Knowledge Base:
316749 There may not be enough virtual memory when you have a large number of databases in SQL Server

COM interoperability

This section specifically addresses the use of OLE Automation in SQL Server and it applies to both in-process and out-of-process COM objects. Assembly meta data for function interfaces implements a strongly-typed mechanism for any invocations.

As part of this design, the COM Callable wrapper for an assembly must use an external mechanism of mapping a ClassID to a member of a managed class. Because of this explicit mapping, there is no ability from an unmanaged perspective to establish a root list of available interfaces.

The extended stored procedure sp_oaCreate uses the IUnknown::QueryInterface interface to determine the object's support for a particular interface. The interoperability between CLR and unmanaged code relies on the IDispatch interface for implementing interfaces. Because there is no equivalent to a QueryInterface method to a CLR-based assembly, you cannot create an instance of the object.
Properties

Article ID: 322884 - Last Review: 07/30/2007 16:20:52 - Revision: 8.2

Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition, Microsoft Common Language Runtime (included with the .NET Framework 1.1)

  • kbinfo KB322884
Feedback