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'，再由存储过程写入变更日志表。这比依赖会话元数据更可控，也绕过了连接字符串配置的运维耦合问题。