将存储过程调用嵌套包装后为何出现执行异常？

你用到的SQL代码如下：

CREATE PROCEDURE [dbo].[#SP_FOO_UPDATE]
AS
        BEGIN
        SET nocount ON
        EXEC [dbo].[foo_batch_sp] '20241002', 100
        END;
exec [dbo].[#SP_FOO_UPDATE]
;

核心原因 #

这是SQL Server 2016（你的版本13.0对应2016）及更早版本的临时存储过程编译时序问题。当你在同一个批处理里完成临时存储过程的创建和执行时，SQL Server的批处理解析逻辑会先对整个批的对象做预解析：

• 预解析阶段，#SP_FOO_UPDATE还未被创建，解析器会标记它为「延迟解析」对象；
• 当批处理执行到创建临时存储过程的语句后，立即执行它时，临时存储过程的编译会在同一批的上下文内完成，此时内部对foo_batch_sp的调用会出现隐式的解析异常——虽然不会抛出报错，但实际执行时会跳过内部的存储过程调用。

而分两次提交时，第一次批处理创建完临时存储过程后，会话中已经存在这个对象，第二次执行时，临时存储过程的编译是在对象已存在的正常上下文里，能正确绑定并调用foo_batch_sp；直接调用foo_batch_sp则没有中间层，自然不会有问题。

解决办法 #

• 最可靠的方式：把创建临时存储过程和执行的语句分成两个独立批处理（比如在SQL GUI中用GO分隔，JDBC中分开两次执行）；
• 如果包装本身没有必要，直接调用foo_batch_sp即可；
• 若必须在单批中执行，可尝试在创建临时存储过程后添加EXEC sp_refreshsqlmodule '#SP_FOO_UPDATE'（但临时存储过程可能不支持此操作，因此分批仍是优先方案）。

内容的提问来源于stack exchange，提问作者Mikhail T.