C# 具有可选参数/默认值的SQLCLR存储过程

既然C#支持可选参数，那么有没有一种方法可以编写SQL CLR存储过程，以便从Visual Studio发布将使用C#中定义的可选参数在SQL server中创建存储过程

过去唯一的方法是手动编写包装函数：

我宁愿避免这种情况，因为它需要编写两次接口，并在情况发生变化时维护两个接口

例如：

[Microsoft.SqlServer.Server.SqlProcedure]
public static void help(string FunctionName = "")
{
    SqlPipe pipe = SqlContext.Pipe;
    pipe.Send("help> " + FunctionName + "<");
}

运行它：

exec help
Procedure or function 'help' expects parameter '@FunctionName', which was not supplied.

但是，如果手动编写过程创建，则如下所示：

drop procedure [help]
CREATE PROCEDURE [dbo].[help] 
( @FunctionName nvarchar(100) = null)
AS EXTERNAL NAME [YOURDB].[StoredProcedures].[help];

exec help 
help> <

drop过程[帮助]
创建过程[dbo]。[帮助]
（@FunctionName nvarchar（100）=null）
作为外部名称[YOURDB].[StoredProcess].[help]；
执行帮助
帮助><

…它现在按预期运行

---

由于C#支持，Visual Studio拥有将参数发布为可选参数所需的所有信息，因此要么我做错了什么，要么他们根本没有更新发布实现以识别可选参数。

目前无法向SSDT（SQL Server数据工具）指示发布过程参数的默认值。是的，这是令人沮丧的，因为它需要额外的步骤来解析和“修复”生成的.sql脚本，或者添加执行

ALTER{object}

语句的部署后脚本来添加缺少的细节（其中包括其他功能，例如用于标量函数的

在NULL输入时返回NULL

选项，非常方便）

我创建了一个Connect建议来解决此缺陷：

与指定参数默认值的可能性相关的两个注释：

• 它们不适用于LOB类型的t-SQL参数--

  NVARCHAR（MAX）

  、

  VARBINARY（MAX）

  、和

  XML

  --因为这些数据类型不支持SQLCLR对象中的默认值。这是另一个挫折，我记录了以下连接建议以解决此缺陷：
• 他们会（也应该）作为属性的附加属性处理。它们不应从C#方法参数默认值派生的原因是，参数默认值在C#和T-SQL之间的工作方式不同。不仅存在上述LOB类型限制，而且在T-SQL中，具有默认值的任何参数的位置都不相关，第具有默认值的仪表后面可以跟有所需参数（即未指定默认值）。相反，在C#中，可选参数必须位于参数列表的末尾，并且不能跟有所需参数。如MSDN页面中所述： 可选参数定义在参数列表的末尾，在任何必需参数之后。如果调用方为一系列可选参数中的任何一个提供参数，则它必须为所有前面的可选参数提供参数

• 我目前正在研究一种方法来记录这些默认值，希望还有

  创建过程

  和

  创建函数

  的其他缺失属性（即

  执行为

  ，

  在空输入时返回空值

  ，等等），但要使其在SSDT发布过程中尽可能无缝地工作有点棘手，因此没有关于何时完成的ETA。完成后，我将使用下载链接更新此答案

更新：
最后，手动处理T-SQL包装器对象创建可能是最容易的。您可以让Visual Studio生成程序集和任何必要的DB设置语句，然后自己执行

创建过程

，

创建函数

，等等，方法是：

在项目属性->项目设置中选中创建脚本（.sql文件）复选框

在项目属性->SQLCLR中，取消选中生成DDL复选框

添加新项目->SQL Server->用户脚本->部署后脚本，并在此脚本中添加您的

CREATE

语句

---

像往常一样回答得很透彻，谢谢。由于这一点和其他各种疯狂，我不想费心去弄清楚，我已经求助于将我的SQLCLR代码放在一个完全独立的VS项目中，并完全手动部署它（手工编码的函数定义）-这是一种痛苦，但你能做些什么。如果在官方文件中说明这些缺点，这样一个人从一开始就知道它不符合预期（并且不可能解决），那将是一件好事@tbone是的，这实际上是我对生产级内容所做的。我只依赖Visual Studio deploy进行测试。我在答案中添加了一个更新。我自己写有点恼人，但签名很少更改，所以它并没有那么糟糕。

drop procedure [help]
CREATE PROCEDURE [dbo].[help] 
( @FunctionName nvarchar(100) = null)
AS EXTERNAL NAME [YOURDB].[StoredProcedures].[help];

exec help 
help> <