SQL Server触发器中ERROR_*()值易丢失，因其仅在CATCH块内首次调用有效；必须在CATCH开头立即用DECLARE存入变量，否则后续调用返回NULL或0。

SQL Server触发器里ERROR_*()值为什么一不留神就丢了

ERROR_NUMBER()、ERROR_MESSAGE()、ERROR_LINE() 这几个函数有个很容易踩坑的特点：它们只在 CATCH 块里才生效。

只有第一次调用时，拿到的才是当前这次错误的原始上下文。 只要你在 CATCH 中先执行了别的语句，哪怕只是一个 SELECT 1，后面再去调用这些函数，返回的往往就是 NULL 或 0。

问题不在于错误没发生，而是上下文已经被后续操作冲掉了。

• 必须在 CATCH 开头第一行就用 DECLARE 把它们存进变量：DECLARE @err_msg NVARCHAR(4000) = ERROR_MESSAGE();
• 别在 CATCH 里写日志前先查表、调函数或做 IF 判断，这些都可能触发新错误或干扰上下文
• 如果触发器里嵌套了存储过程调用，ERROR_PROCEDURE() 返回的是触发器名，不是内部 SP 名——想定位深层问题得靠 ERROR_LINE() 和日志打点

日志表插入失败会导致整个事务回滚？怎么防

是的。触发器和主 DML 共享同一事务。

INSERT INTO ErrorLog 如果因约束冲突、字段超长或锁超时失败，会连带让原始 INSERT/UPDATE/DELETE 一起回滚。

用户看到的是“操作失败”，但根本不知道触发器才是元凶。

• 日志表结构要极简：最少字段（时间、错误号、消息）、无外键、无触发器、主键用 IDENTITY 而非 GUID
• 插入时加 WITH (TABLOCK) 避免页锁争用，但高并发场景慎用；更稳妥的是用 INSERT ... SELECT + WHERE NOT EXISTS 防重复
• 关键防御：插入前加 IF @err_msg IS NOT NULL 判断，避免空值插入触发 NOT NULL 约束失败
• 不要在 CATCH 里调用另一个可能出错的存储过程记录日志——那等于把单点故障变成双点故障

为什么RAISERROR不如THROW可靠

RAISERROR 会重置错误号、丢失原始 ERROR_LINE()。

而且默认严重级为 10，低于事务中断阈值，导致上层业务代码捕获不到。你以为吞掉了错误，其实它还在那儿静默破坏数据一致性。

• 用无参 THROW：它原样重抛原始错误，保留全部上下文（包括行号、过程名、嵌套深度）
• 别写 RAISERROR(@err_msg, 16, 1)——这会把 ERROR_NUMBER() 变成 50000，掩盖真实问题
• 如果必须自定义消息（比如加 trace_id），用 THROW 50000, 'msg', 1，但注意：自定义错误号无法携带原始 ERROR_LINE()
• THROW 后不能跟任何语句（包括 RETURN），否则报语法错

调试时PRINT不显示？怎么让错误透出来

SSMS 默认不显示触发器里的 PRINT，尤其当触发器被事务包裹时，输出会被缓冲甚至丢弃。

更糟的是，如果触发器里用了 SET NOCOUNT ON（常见于模板），PRINT 直接失效。

• 临时调试可在触发器开头加 SET NOCOUNT OFF;，但上线前必须删掉
• 用 RAISERROR('debug: %d rows', 0, 1, @@ROWCOUNT) WITH NOWAIT; 强制刷出消息——级别 0 不中断执行，WITH NOWAIT 绕过缓冲
• 真正可靠的调试方式是往日志表写中间状态：比如在 TRY 块开头插一条 'start' 记录，在关键分支后插 'after validation'，这样即使最终失败也能看到走到哪一步
• 别依赖 SSMS 的“消息”窗口——用 sys.dm_exec_trigger_stats 查 execution_count 和 failed_execution_count，比肉眼盯输出靠谱得多

核心结论

触发器诊断信息能否保留，不取决于你写了多少 PRINT，也不取决于日志表建得多漂亮。

真正的关键是：有没有在 CATCH 第一行就把那几个 ERROR_* 函数的值“抓牢”。

稍一松手，线索就断了。

《夸克》非常好用的免费AI浏览器

下载APP查看