我可以告诉 MS SQL Server 忽略 Msg 8144（指定的参数太多）吗？答案

【问题标题】：Can I tell MS SQL Server to ignore Msg 8144 (too many arguments specified)?我可以告诉 MS SQL Server 忽略 Msg 8144（指定的参数太多）吗？
【发布时间】：2014-12-12 13:58:10
【问题描述】：

以下 SQL 在 Sybase ASE 和 MS SQL Server 中编译没有问题：

go
create proc foo
  @foo1 int
as
  select @foo1
go
create proc bar
  @bar1 int
as
  exec foo @foo1=@bar1, @foo2=@bar1
go

它在 Sybase ASE 中运行没有问题，但在 MS SQL Server 中抱怨：

Msg 8144, Level 16, State 2, Procedure foo, Line 11
Procedure or function foo has too many arguments specified.

是否可以告诉 MS SQL Server 忽略此警告？如果没有，是否可以在编译调用具有太多参数的其他过程的存储过程时告诉 MS SQL Server 中断？当我们只在实际调用过程时才知道这些问题时，这是有潜在危险的。

这段代码应该在 Sybase ASE 和 MS SQL Server 中都可以工作，到目前为止，我们一直在使用 Sybase 的宽松规则，因为我们现在正在添加对 MS SQL Server 的支持。

正如我在下面提到的，问题不在于可选参数。它是关于存储过程的预测。我不介意仅通过使用正确数量的参数调用存储过程或向存储过程添加虚拟参数来解决问题，我只希望 MS SQL Server 在编译时告诉我，而不是在运行时告诉我。既然 MS SQL Server 实际上会验证一个过程是否存在（如果不存在它会发出警告，尽管我更喜欢它像 Sybase ASE 那样失败），为什么它不能同时检查它的参数呢？

【问题讨论】：

您只需要指定例如两个参数，其中一个是可选的。 stackoverflow.com/questions/1810638/…
"为什么不能检查..." 可以，但不能。不幸的是deferred name resolution 被认为是一个特性而不是一个错误。只有在执行时 SQL Server 才会尝试生成查询计划，然后才会看到调用无效。收到警告是一种礼貌。
嗯，那么这个转换会很有趣。

标签： sql sql-server sap-ase

【解决方案1】：

不，这是不可能的。

我建议您开始使用 SSDT - SQL Server Data Tools - 对您的代码运行 SQL 编译检查。它是 Visual Studio 的一部分。

【讨论】：

【解决方案2】：

不，你不能那样做。如果它可以有一个或两个参数，则使用带有默认值的可选参数：

create proc foobar
  @foo1 int = null,
  @bar1 int = null

您必须根据提供的参数处理代码执行路径。然后你可以这样做：

exec foobar -- with no params, both default to null

或者：

exec foobar 1 -- just a foo param, bar defaults to null

或者：

exec foobar 1,2 -- with both params

或者：

exec foobar @bar1 = 2 -- with a specified param, other param defaults to null

【讨论】：

举个反例：我们有很多报表存储过程。我们的报表服务器使用一组参数（包括一个公共参数）调用 SQL 数据库，该参数是大多数的报表存储过程，但不是全部，因为不是所有的都需要。因此，要么我必须为许多存储过程创建虚拟参数，要么让我的报表服务器检查存储过程是否实际采用这些参数。但这只是我们存储过程的一小部分，我们有超过 2000 个存储过程。
@Svip：这与其说是一个反例，不如说它是你有很多工作要做的原因。 SQL Server 根本不允许您使用它们不接受的参数调用过程。更糟糕的是，没有简单的方法可以确定存储过程将接受哪些参数——不过，您可以从sys.sql_modules 获取定义并对其进行搜索。另一种选择是统一所有参数集，然后使用完全相同的参数列表创建所有存储过程——这应该是可自动化的。