SQL Server触发器无法捕获导致更新失败的原始SQL语句，EVENTDATA()在DML触发器中返回NULL，sys.dm_exec_sql_text也不可靠；应改用SQL Server Audit、Extended Events等原生审计机制。
做不到。SQL Server 触发器无法捕获导致更新失败的原始 SQL 语句。
EVENTDATA() 在 DML 触发器里返回 NULL
很多人误以为在 AFTER UPDATE 触发器里调用 EVENTDATA() 能拿到执行语句，实际结果是 NULL。这个函数只在 DDL（如 CREATE TABLE）或 LOGON 触发器中有效，在 INSERT/UPDATE/DELETE 触发器中调用它，返回值就是空，不是空字符串，是真正的 NULL。
- 哪怕你写
SELECT EVENTDATA()放在trg_AfterUpdate ON Orders里，结果也为空 - 它设计目标是响应结构变更或登录事件，不是 SQL 审计工具
- XML 中最多有
<objectname>Orders</objectname>这类元信息，没有<sqltext>节点
sys.dm_exec_sql_text(@sql_handle) 只能拿到当前会话最后执行的批处理
有人尝试用 sys.dm_exec_requests + sys.dm_exec_sql_text 获取 SQL 文本，但这条路在触发器里极不可靠：
-
@sql_handle取的是当前@@SPID最近一次执行的句柄，而触发器本身是嵌套执行，常拿到的是触发器内部语句（如INSERT INTO AuditLog），不是用户发起的那条UPDATE - 并行 DML 场景下，
sys.dm_exec_requests可能返回多行，TOP 1不保证命中原始语句 - 需要
VIEW SERVER STATE权限，生产环境通常不开放 - 返回的是整个批处理文本，如果应用用
sp_executesql拼接，你会看到一堆参数赋值，而不是干净的UPDATE Users SET name = @p0 WHERE id = @p1
真正能记录原始 SQL 的替代方案
如果你的目标是“知道谁、什么时候、执行了哪条 SQL 导致更新失败”，必须放弃触发器，改用原生审计机制：
-
SQL Server Audit：启用STATEMENT级别审计，可捕获UPDATE语句文本、执行者、时间戳，写入文件或安全日志，开销低且稳定 -
Extended Events：监听sql_batch_completed或rpc_completed事件，开启collect_statement选项，能提取sql_text字段；比 Profiler 轻量，适合长期运行 -
Server Audit + Database Audit Specification组合：可精确限定到具体数据库、用户、操作类型（包括SELECT和UPDATE），且支持失败事件过滤（WHERE result = 'FAIL'）
触发器唯一能确认的，只是“某人在某张表上做了 DML”，至于那条 SQL 是从 SSMS 手敲的、还是 ORM 自动生成的、带什么参数、是否含子查询——全都不可能得知。想靠它做 SQL 级故障归因，方向就错了。
