SQL批量执行升级脚本与SSMS单语句查询sys.objects结果不一致

已知现象 #

单独执行触发器、存储过程的元数据查询可正常返回结果，运行完整升级脚本时同类查询返回0行，已排除SET会话配置的影响。

高频原因及对应处理 #

• 数据库上下文被中途切走（概率最高）
  sys.objects 是库级系统视图，只返回当前连接所在库的元数据。如果脚本在跑元数据查询前，有未回溯的USE 其他库语句、动态SQL里嵌的USE逻辑、或是SSDT生成脚本自带的上下文切换代码，查询就会跑到别的库上，自然找不到目标对象。
  验证：在触发器/存储过程的INSERT语句前加一行SELECT DB_NAME() AS 当前库;，跑完整脚本看返回的是不是CarrierAPI_seed。
  解决：
  • 所有系统视图查询显式加目标库前缀，比如把FROM sys.objects改成FROM CarrierAPI_seed.sys.objects，完全不受当前上下文影响。
  • 每个元数据查询批次前强制加USE CarrierAPI_seed; GO，不管之前怎么切的，强制切回目标库。
• 安全上下文切换导致元数据不可见
  SQL Server的系统视图只会返回当前账号有权限看的对象。如果脚本里有没切回去的EXECUTE AS语句、或是跑升级的账号对目标触发器/存储过程没查看权限，查询就会把这些对象过滤掉。
  验证：在INSERT查询前加SELECT USER_NAME() AS 当前账号; SELECT HAS_PERMS_BY_NAME('你预期的触发器名', 'TRIGGER', 'VIEW DEFINITION') AS 权限状态;，确认权限正常。
  解决：给升级账号授予目标库的VIEW ANY DEFINITION权限，或是在EXECUTE AS执行完及时跑REVERT切回原账号。
• 目标对象被提前删除
  如果你新增的存在性检查逻辑，在元数据提取的批次之前已经跑了DROP TRIGGER/DROP PROCEDURE，后面的查询自然查不到。
  验证：在INSERT查询前加SELECT * FROM CarrierAPI_seed.sys.objects WHERE type IN ('TR','P') AND name = '预期的对象名';，确认对象是否已经被删。
  解决：调整脚本执行顺序，把所有元数据提取操作放到所有对象删除逻辑之前。
• 临时表检查逻辑有兼容问题（次要）
  原脚本里OBJECT_ID('TempDB..#CAPI_Upgrade_Triggers','U')的写法有问题：本地临时表在tempdb里的实际名字带系统自动加的一串后缀，只有当前会话已经存在这个临时表时才能匹配到，残留的会话临时表可能导致异常DROP。
  解决：把临时表判断逻辑简化成IF OBJECT_ID('tempdb..#CAPI_Upgrade_Triggers') IS NOT NULL DROP TABLE #CAPI_Upgrade_Triggers;，不用额外指定架构。

快速调试命令 #

在脚本的元数据查询批次前加以下代码，运行后看消息输出就能快速定位：

SELECT '当前上下文：' + DB_NAME() + ' | 当前账号：' + USER_NAME();
-- 替换成你预期的触发器全名，比如dbo.Trg_OrderUpdate
SELECT '触发器存在性：' + CAST(OBJECT_ID('CarrierAPI_seed.架构名.你的触发器名', 'TR') AS VARCHAR(20));

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