SQL Server 2017中sa调用第二个ETL存储过程无法访问staging库

• 检查存储过程的执行上下文设置
  查看第二个存储过程是否包含EXECUTE AS子句，比如CREATE PROCEDURE ... WITH EXECUTE AS '某个受限用户'，该设置会覆盖当前sa的操作上下文，导致无法访问staging库。对比第一个正常存储过程的定义，确认是否存在这个差异。

• 验证对象引用的准确性
  核对第二个存储过程中对staging库诊断表的引用格式，确保是staging.dbo.诊断表这类完整的三部分命名（库名、架构名、表名），排查是否存在库名/表名的笔误，比如把staging写成stage之类的错误。

• 刷新存储过程的依赖元数据
  执行sp_refreshsqlmodule '主库.dbo.第二个存储过程名'刷新存储过程的依赖信息，部分情况下存储过程编译时的上下文异常会引发权限问题。也可以通过sys.sql_expression_dependencies查询该存储过程的依赖对象，确认是否正确指向staging库的诊断表。

• 对比两个存储过程的完整定义
  使用SQL Server Management Studio的「比较对象」功能，直接对比两个存储过程的全部定义内容，包括注释、ANSI_NULLS/QUOTED_IDENTIFIER这类会话级设置，有时候这些隐性设置的差异会导致执行时权限上下文异常。

• 直接测试诊断表访问语句
  在当前sa会话中，单独执行第二个存储过程里访问诊断表的语句（比如SELECT * FROM staging.dbo.诊断表），如果能正常执行，说明问题出在存储过程本身的设置而非sa权限；如果也报错，再排查staging库的sa权限是否被意外撤销（但其他存储过程正常的话此概率极低）。

• 检查存储过程的创建上下文
  查看sys.procedures中的execute_as_principal_id字段，对比两个存储过程的差异，确认第二个存储过程创建时是否使用了受限用户身份，或者创建时的数据库上下文异常，导致存储过程的所有者或执行上下文出现问题。

内容的提问来源于stack exchange，提问作者Geepy