Access转SQL Server：通用SQL登录下获取Windows用户名咨询

我之前处理过好几个Access转SQL Server的迁移场景，你遇到的这个问题其实很典型——当切换到SQL Server身份验证后，数据库连接的身份是通用SQL登录账号，和客户端的Windows身份完全脱节了，所以SYSTEM_USER只能返回SQL登录名，服务器端根本拿不到客户端的Windows用户名。下面给你几个最实用的解决方案：

方案一：在Access前端处理（最推荐，简单可靠） #

既然前端是运行在用户的Windows机器上，直接保留NetworkUsername()的调用就行，别把用户名的获取逻辑放到直通查询里。具体做法：

• 先在Access VBA里拿到当前用户的Windows用户名：

  Dim currentWinUser As String
  currentWinUser = NetworkUsername() ' 也可以用 Environ("USERDOMAIN") & "\" & Environ("USERNAME") 拿到完整的域名\用户名格式
  

• 然后把这个用户名作为参数传给SQL Server的查询或存储过程。比如调用存储过程的示例：

  Dim cmd As New ADODB.Command
  Set cmd.ActiveConnection = YourSQLServerConnection ' 替换为你的SQL连接对象
  cmd.CommandText = "dbo.YourTargetProcedure"
  cmd.CommandType = adCmdStoredProc
  ' 添加参数，将前端拿到的Windows用户名传入
  cmd.Parameters.Append cmd.CreateParameter("@WinUserName", adVarChar, adParamInput, 100, currentWinUser)
  cmd.Execute
  

• 如果是普通查询，也可以在Access里构造带参数的SQL语句，把用户名作为过滤条件或参数传入，避免直接写死在直通查询里。

这个方案逻辑清晰，不需要修改SQL Server的配置，也没有安全风险，完全利用前端能直接获取客户端身份的优势。

方案二：SQL Server端的替代思路（仅特殊场景可用） #

如果你非得在SQL Server端尝试获取，得先明确：SQL Server身份验证模式下，服务器本身无法直接获取客户端的Windows身份——因为这种验证方式不会传递客户端的Windows凭据。不过有两个偏门方法，但都有明显局限性：

• CLR集成函数：可以写一个CLR函数调用Windows API，但这个函数拿到的是SQL Server服务运行账号的用户名，不是客户端的，对你的场景没用，除非你的SQL Server服务是用客户端身份运行，这显然不现实。
• xp_cmdshell：它是在服务器端执行系统命令，拿到的也是服务器本地的用户名，不是客户端的，而且开启xp_cmdshell还有安全风险，不推荐使用。

总结 #

最靠谱的还是方案一，把用户名的获取放在Access前端，再传递给SQL Server。毕竟前端才是和用户直接交互的层，能准确拿到当前用户的Windows身份，而SQL Server在通用登录模式下，确实没有办法直接感知客户端的Windows用户。

内容的提问来源于stack exchange，提问作者dbmitch