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

以下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一样失败），为什么它不能同时检查其参数？

不，这是不可能的

---

我建议您开始使用SSDT—SQLServer数据工具—对代码运行SQL编译检查。它是Visual Studio的一部分。

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

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

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

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

或：

或：

或：

---

您只需指定两个参数，使其中一个成为可选参数。“为什么它不能检查…”它可以，但它不能。不幸的是，它被认为是一个特性，而不是一个bug。只有在执行时，SQL Server才会尝试生成查询计划，然后才发现调用无效。得到警告是一种礼貌。那么，这种转换将非常有趣。让我给你一个反例：我们有许多报表存储过程。我们的报表服务器使用一组参数（包括一个公共参数）调用SQL数据库，这些参数是大多数报表存储过程调用的，但不是所有存储过程调用的，因为并非所有存储过程都需要。因此，要么我必须为许多存储过程创建虚拟参数，要么让我的报表服务器检查存储过程是否实际使用了这些参数。但这只是我们存储过程的一小部分，我们有2000多个存储过程。@Svip：这与其说是一个反例，倒不如说是一个原因，让你有很多工作要做。SQL Server不允许您使用过程不接受的参数调用过程。更糟糕的是，没有简单的方法来确定存储过程将接受哪些参数——不过，您可以从

sys.sql\u modules

中获取定义并搜索它。另一种选择是统一所有参数的集合，然后使用完全相同的参数列表创建所有存储过程——这应该是自动化的。

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