SQL Server触发器无法直接获知调用它的存储过程名，因其属事件响应机制而非函数调用；可通过SESSION_CONTEXT透传标识或Extended Events外部跟踪定位。
SQL Server 的触发器本身无法直接获知“是哪个存储过程调用的”，因为 DML 触发器（如 AFTER INSERT）响应的是语句级事件，不是调用栈意义上的函数调用；而 DDL 触发器和登录触发器更不涉及“调用者存储过程”的概念。真正能查到上下文的，只有当前会话的执行链路，且需主动捕获。
触发器里拿不到 CALLER_PROC 的原因
SQL Server 触发器不是被“调用”的，而是被“激发”（fired）的——它属于事件响应机制，与存储过程的嵌套调用模型完全不同。即使 INSERT 语句写在某个存储过程中，触发器内部也看不到该存储过程名，@@PROCID 返回的是触发器自身的 ID，OBJECT_NAME(@@PROCID) 得到的是触发器名，不是上层过程名。
- DML 触发器没有
inserted/deleted以外的上下文视图可读取调用堆栈 - DDL 触发器依赖
EVENTDATA()，但只返回事件类型、T-SQL 命令文本、数据库名等，不包含调用它的存储过程信息 - SQL Server 不提供类似
sys.dm_exec_input_buffer在触发器内实时获取当前会话原始批处理的能力（该 DMV 需要独立会话权限且不能在触发器中安全调用）
替代方案：用 SESSION_CONTEXT 或 CONTEXT_INFO 透传调用者标识
如果业务逻辑可控，最可靠的方式是在调用方显式传递上下文。比如在存储过程中执行 DML 前，先设置会话级标记：
EXEC sys.sp_set_session_context @key = N'caller_proc', @value = N'sp_update_customer'; INSERT INTO Orders (...) VALUES (...);
然后在触发器里读取：
DECLARE @caller SYSNAME = CAST(SESSION_CONTEXT(N'caller_proc') AS SYSNAME);
IF @caller IS NOT NULL
INSERT INTO AuditLog (event, caller, table_name)
VALUES ('INSERT on Orders', @caller, 'Orders');
-
SESSION_CONTEXT是线程安全、会话隔离的，比老式的CONTEXT_INFO更推荐（后者需CONVERT处理二进制） - 必须确保调用方（存储过程）和触发器在同一个会话中执行，跨连接或异步作业不适用
- 若使用
CONTEXT_INFO，注意长度限制（128 字节）和类型转换开销
排查时临时抓原始批处理：用 SQL Server Profiler 或 Extended Events
当无法修改代码，又需要定位某次触发是由哪个过程引发的，应放弃在触发器内“自省”，改用外部跟踪：
- 启用
rpc_completed和sql_batch_completed事件，筛选database_id和目标表名 - 在 Extended Events 中捕获
query_post_execution_showplan（慎用，性能开销大）或更轻量的sp_statement_completed - 关键字段看
client_app_name、session_id、sql_text，再结合时间戳关联触发器日志 - Profiler 已弃用，但对临时诊断仍有效；生产环境优先用 XE Session +
ring_buffer目标
为什么 EVENTDATA() 和 ERROR_PROCEDURE() 都不适用
EVENTDATA() 只在 DDL/登录触发器中可用，返回 XML 包含 <EventType>、<TSQLCommand> 等，但命令文本是原始 DDL（如 CREATE TABLE），不会显示外层存储过程名；ERROR_PROCEDURE() 是错误上下文函数，仅在 CATCH 块中有效，且返回的是发生错误的最内层过程名——而触发器执行出错时，它返回的是触发器自身名，不是调用者。
真正容易被忽略的点是：很多人试图在触发器里查 sys.dm_exec_requests 或 sys.dm_exec_sessions 获取 program_name，但这只能反映客户端应用名（如 “Microsoft SQL Server Management Studio”），对区分同个应用下的不同存储过程毫无帮助。
