从Access连接远程服务器SQL Server实例仅部分用户可用问题排查

你遇到的是典型的客户端环境一致性差异问题，和服务器端配置、Access侧VBA逻辑、连接字符串内容无关——服务器端配置如果有问题，所有用户都会连不上，且局域网SQL实例所有用户可访问，也能排除VBA代码和连接字符串的逻辑错误。
你之前尝试的修复方案没有生效，核心是没命中两个最容易被忽略的客户端差异点：一是连接时的端口解析依赖本地缓存，二是驱动位数和Access位数不匹配。

• 首先修改连接字符串的服务器地址配置，彻底绕开实例名、SQL Browser的解析逻辑：直接把地址写为[服务器B的远程IP],[SQL实例实际监听端口]的格式，比如实例固定监听1433端口就写1.2.3.4,1433，如果是命名实例自定义了1435端口就写1.2.3.4,1435。
  你和另外1名用户能正常连通，本质是你们的机器上留存了之前连接时缓存的实例-端口映射关系，其他用户没有这个本地缓存，又因为远程场景下UDP 1434端口（SQL Browser用来返回端口信息的端口）往往被路由/防火墙拦截，所以既用实例名连不上，不带端口的IP直连也会失败。写死固定端口后完全不依赖SQL Browser服务，不需要再调整该服务的启动状态。
• 统一匹配客户端驱动位数：先确认所有终端上安装的Access是32位还是64位（打开Access后在「文件-账户-关于Access」里可以看到明确位数），必须安装和Access位数完全一致的SQL Server驱动，优先装新版的Microsoft OLE DB Driver for SQL Server，不要用已经停止维护的SQL Native Client 11.0。
  你之前装完整版SQL Server Express只修复了1个用户的问题，就是因为那个用户的Access位数刚好和他装的Express自带驱动位数一致，其余用户要么装错了驱动位数，要么驱动版本过旧，加载失败导致连不通。
• 清理客户端异常凭据与网络拦截：在所有无法连接的终端上打开「控制面板-用户账户-凭据管理器-Windows凭据」，删除所有和服务器B的IP、主机名相关的已保存凭据，避免之前保存的错误Windows凭据优先被用于SQL认证导致连接被拒。临时关闭终端本地的第三方安全软件、系统防火墙做连通测试，如果能连通，就给安全软件加Access程序、SQL对应端口的出向白名单即可。
• 做基础链路校验：在无法连接的终端上打开命令提示符，执行telnet 服务器B的IP SQL实例监听端口，如果执行后窗口黑屏无报错，说明网络端口通，问题出在驱动/凭据层；如果提示连接失败，说明终端到服务器的网络链路存在策略拦截（比如终端网络的出口防火墙限制了非授信地址的数据库端口访问、路由丢包），这部分和应用配置无关，需要调整网络访问策略。

补充验证：所有操作完成后，先在ODBC数据源管理器（32位Access对应打开C:\Windows\SysWOW64\odbcad32.exe，64位Access对应打开系统自带的64位ODBC管理工具）里手动建一个指向服务器B的系统DSN，测试连通成功后再启动ERP系统即可。

内容的提问来源于stack exchange，提问作者Maiol Salse Escudero