SQLCLR存储过程数据类型

Question

I decided to create a SQLCLR stored procedure to replace a SQL Server stored procedure due to it's complexity.

Question: is there any data type or API restrictions when we write CLR stored procedures? If so, can someone give me any heads up on this.

I am planning to use var, List<T>, DataTable, DataRow[] and a Queue along with few LINQ extension methods.

Answer 1

This is actually a fairly open-ended question as there are nuances in both what can be done in the .NET / CLR code itself and what datatypes can/should be used as input/output parameters.

Starting with the basics, the nuances depend on what version of SQL Server you are using, and which particular question is being asked.

.NET Framework Versions

• Mixed-mode is not allowed: only a single CLR version can be used within the SQL Server CLR Host, and the CLR version depends on the version of SQL Server and cannot be changed
• SQL Server 2005, 2008, and 2008 R2: Statically bound to CLR 2.0
• SQL Server 2012, 2014, and 2016: Statically bound to CLR 4.0

.NET Framework Libraries and Data Type Mappings

SQL Server 2005

Supported .NET Framework Libraries :

• CustomMarshalers
• Microsoft.VisualBasic
• Microsoft.VisualC
• mscorlib
• System
• System.Configuration
• System.Data
• System.Data.OracleClient
• System.Data.SqlXml
• System.Deployment
• System.Security
• System.Transactions
• System.Web.Services
• System.Xml

Data Types:

• Specifics: SQL Server Data Types and Their .NET Framework Equivalents
• Main page with more info (ie handling NULLs, etc): SQL Server Data Types in the .NET Framework

SQL Server 2008, 2008 R2, 2012, 2014, and 2016:

Supported .NET Framework Libraries : ( 2 libraries added as noted below )

• CustomMarshalers
• Microsoft.VisualBasic
• Microsoft.VisualC
• mscorlib
• System
• System.Configuration
• System.Data
• System.Data.OracleClient
• System.Data.SqlXml
• System.Deployment
• System.Security
• System.Transactions
• System.Web.Services
• System.Xml
• System.Core.dll ( added in SQL Server 2008 )
• System.Xml.Linq.dll ( added in SQL Server 2008 )

Data Types:

• Specifics: SQL Server Data Types and Their .NET Framework Equivalents
• Main page with more info (ie handling NULLs, etc): SQL Server Data Types in the .NET Framework

Misc.

• Regarding Data Types: if there is a Sql* type available (eg SqlInt32 ) then use it; don't use the .NET type in the C# method for input parameters (eg int or Int32 ). Only use the native .NET type if there is no Sql* type for the SQL Server Data Type to map to. The two common instances of this exception are using object (which can be DbNull.Value ) to map to SQL_VARIANT , and DateTime / DateTime? which map to DATETIME2 .
• You can reference / use 3rd party assemblies as well as Framework Libraries outside of those listed above, but you then need to import them with a PERMISSION_SET of UNSAFE into the database in which your code also resides. You will also probably need to set the database to TRUSTWORTHY ON in order to set them to UNSAFE because it does not seem possible (not that I can find, anyway) to create the Asymmetric Key from Microsoft provided DLLs.
• Generally speaking, anything written against .NET 2.0 such that it works in SQL Server 2005 should work in any of the later versions of SQL Server. I have yet to come across something that works in .NET 2.0 on 2005 that doesn't work in any of the version to come after 2005.
• You cannot pass Table-Valued Parameters (TVPs) into a SQLCLR-based object (Stored Procedure, Function, etc.). That point, as well as some other helpful info, is noted in the MSDN documentation for CLR Stored Procedures
• I have not seen any issues when using List<T> , DataTable , and DataRow[] .
• I have not used Queue or var but would not expect any issues when using them.
• It has been years since I tried LINQ but seem to recall the only issue being that it was not included in the SQL Server 2005 set of supported Framework Libraries so that didn't work for me as I need to support 2005 - 2014, but for anyone who doesn't need to worry about SQL Server 2005 it should be ok.
• For more details on the topic of SQLCLR, I have a series of articles on SQL Server Central (free registration required): Stairway to SQLCLR