PROGRAM_NAME() 返回客户端连接时指定的Application Name，不自动记录日志，需显式设置才有效；未设置时返回默认值或NULL，生产中应结合参数传入或HOST_NAME()等辅助字段增强溯源可靠性。
PROGRAM_NAME() 函数本身不能直接记录修改来源
PROGRAM_NAME() 是一个会话级系统函数，返回当前连接的客户端应用程序名称（如 SQL Server Management Studio、Microsoft Access、MyApp.exe），但它**不自动写入任何日志**，也不参与审计或触发器的隐式捕获。你看到的“程序名”其实是客户端在建立连接时通过连接字符串中的 Application Name=xxx 参数传入的——如果没设，SQL Server 默认填 Microsoft SQL Server Management Studio 或空字符串。
常见错误现象包括：
- 在触发器里直接用
SELECT PROGRAM_NAME()，结果全是NULL或统一值，因为很多 ORM（如 Entity Framework）或中间件根本没设置Application Name - 误以为开启默认跟踪或 SQL Server Audit 就能自动带出程序名，其实审计事件里
program_name字段依赖的就是这个会话属性，源头没传，后续就为空
必须由客户端显式设置 Application Name 才有效
只有当连接字符串中明确包含 Application Name=YourApp，PROGRAM_NAME() 才能返回有意义的值。不同场景下的设置方式差异较大：
- SSMS 连接：在“连接到服务器”对话框点“选项 → 额外连接参数”，填入
Application Name=ReportService - .NET SqlConnection：在连接字符串末尾加
;Application Name=InventoryApp - Python pyodbc：连接时传参
appname='OrderProcessor'（注意不是所有驱动都支持同名参数，pyodbc 用application_name关键字） - Java JDBC：使用
applicationName=ShippingModule作为连接属性
没设或设错，PROGRAM_NAME() 返回空或不可区分的默认值，后续所有基于它的判断都会失效。
在触发器或审计中安全使用 PROGRAM_NAME() 的要点
即使客户端设置了 Application Name，在服务端逻辑中调用 PROGRAM_NAME() 仍需注意上下文和权限：
- 它只在当前会话生命周期内有效；跨批处理（如触发器 + 后续 EXEC）可能因会话重用导致值漂移
- 在启用
EXECUTE AS的存储过程或触发器中，PROGRAM_NAME()返回的是**原始调用者**的程序名，不是执行上下文切换后的账户名——这点常被误认为是 bug - 若用在 DML 触发器里记录修改来源，建议搭配
HOST_NAME()和ORIGINAL_LOGIN()一起存，避免单点失效 - SQL Server Audit 的
database_principal_name和client_hostname字段可与program_name联合查询，但审计策略本身不支持过滤program_name，只能事后 WHERE 筛选
替代方案：为什么光靠 PROGRAM_NAME() 不够可靠
真实生产环境里，仅依赖 PROGRAM_NAME() 做溯源存在明显短板：
- Web 应用通常共用连接池，所有请求看起来都是同一个
Application Name（如IIS AppPool） - 代理层（如 API 网关、负载均衡器）会掩盖真实客户端，
PROGRAM_NAME()只反映中间层名称 - 无法区分同一程序内的不同业务模块（比如同一个 ERP 客户端里有采购/销售两个功能入口）
更稳妥的做法是：在业务层 SQL 中显式传入来源标识，例如用参数 @source_module = 'PurchaseOrderEntry'，再由存储过程写入变更日志表。这比依赖会话元数据更可控，也绕过了连接字符串配置的运维耦合问题。
