EVENTDATA()在DML触发器中始终返回NULL，因其仅支持DDL和LOGON触发器；sys.dm_exec_sql_text等方法在触发器内不可靠，应改用SQL Server Audit或Extended Events进行SQL审计。
EVENTDATA() 在 DML 触发器中始终返回 NULL
很多人在 AFTER UPDATE 或 INSTEAD OF INSERT 里调用 EVENTDATA()，期待拿到原始 SQL 文本，结果查出来是真正的 NULL（不是空字符串）。这不是权限或配置问题，而是设计限制：EVENTDATA() 只对 DDL（如 CREATE TABLE）和 LOGON 触发器有效，在所有 DML 触发器中它都返回 NULL。XML 结果里最多有 <objectname>Orders</objectname> 这类元信息，根本没有 <sqltext> 节点。
sys.dm_exec_sql_text + @@SPID 在触发器里不可靠
试图用 sys.dm_exec_requests 查当前会话的 sql_handle，再喂给 sys.dm_exec_sql_text()，这条路在触发器中几乎必败：
-
@@SPID拿到的是触发器执行时的会话 ID，但sys.dm_exec_requests返回的是该会话“最近一次执行”的语句句柄——大概率是触发器自己内部的INSERT INTO AuditLog，不是用户那条UPDATE Users SET name = @p0 - 并行 DML 场景下，
sys.dm_exec_requests可能返回多行，TOP 1不保证命中原始语句 - 需要
VIEW SERVER STATE权限，生产库通常不开放 - 即使拿到句柄，返回的也是整个批处理文本；如果应用用
sp_executesql发送，你会看到一堆@p0 = N'xxx'参数赋值，而非干净的原始 SQL
dbcc INPUTBUFFER(@@SPID) 有严重局限性
有人用 DBCC INPUTBUFFER(@@SPID) 试图抓源头，它确实能返回发起请求的最外层语句（比如 SSMS 里敲的 UPDATE），但它有硬伤：
- 只返回前 4000 字符，长 SQL 直接被截断
- 如果变更来自存储过程，它只返回
EXEC proc_name，看不到过程体内的实际语句 - 在连接池复用场景下，
@@SPID可能对应上一个已结束的请求，缓冲区内容早已被覆盖 - 无法区分失败语句——它不管执行成功与否，只管“最后发了什么”
真正可用的替代路径只有 Audit 或 XEvent
想审计“谁、什么时候、执行了哪条 SQL 导致更新失败”，必须放弃触发器：
-
SQL Server Audit：启用STATEMENT级别审计，可精确捕获 SQL 文本、登录名、时间戳、结果（含FAIL），写入文件或 Windows 安全日志，开销低且稳定 -
Extended Events：监听sql_batch_completed或rpc_completed，开启collect_statement选项，直接提取sql_text字段；比 Profiler 轻量，适合长期运行 - 组合使用
Server Audit+Database Audit Specification，可限定到具体数据库、用户、操作类型，并支持WHERE result = 'FAIL'过滤失败事件
触发器唯一能确认的，只是“某人在某张表上做了 DML”。至于那条 SQL 是 ORM 自动生成的、带什么参数、是否含子查询、甚至是不是失败了——全都不可能得知。把触发器当 SQL 审计工具，从起点就错了。
