SAS使用新DSN连接Azure DB运行PROC SQL报File不存在错误

一、SAS侧配置验证 #

• 首先确认Server Manager中Prod B的库引擎类型是否与其他三个正常DSN完全一致，必须选择对应Azure DB的ODBC引擎，不要选错为SAS本地库或其他数据库引擎
• 导出Prod A和Prod B的库定义代码对比：在SAS Management Console中右键两个库，选择【显示代码】，检查LIBNAME语句的所有参数，重点核对QUALIFIER=、SCHEMA=、DATASRC=参数值，特别是大小写，Azure DB的对象名对大小写敏感的配置会直接导致找不到对象
• 直接在SAS程序编辑器手动写LIBNAME语句测试Prod B：
  示例代码：

  libname prodbdsn odbc datasrc="你的Prod B DSN名称" user="你的账号" password="你的密码" schema="你的表所属 schema 名";
  proc datasets lib=prodbdsn;
  run;
  

  运行后看列出的表中是否存在你要查询的目标表，确认表名拼写、大小写完全匹配

二、Windows系统DSN配置验证 #

• 打开Windows ODBC数据源管理器（注意区分32位和64位：SAS如果是64位就开C:\Windows\System32\odbcad32.exe，32位SAS开C:\Windows\SysWOW64\odbcad32.exe，两者配置完全独立）
• 选中Prod B DSN点击【配置】，逐页对比和Test B/Prod A的配置项：
  • 确认服务器地址、端口、数据库名完全正确
  • 确认认证方式和其他三个正常DSN一致
  • 点击【测试数据源】确认DSN本身可以正常连通Azure DB
• 检查DSN的默认数据库/默认Schema配置，是否和Test B一致，如果你查询时没有指定Schema，会默认找DSN配置的默认Schema下的表，不一致就会报文件不存在

三、权限排查 #

• 确认Prod B DSN使用的数据库账号，对目标表所属的Schema有SELECT权限，Azure DB中账号如果没有权限也会返回表不存在的报错（而非权限不足，部分ODBC驱动会做报错转换）
• 确认SAS运行服务的账号，对ODBC DSN的配置有读取权限，部分服务账号无法读取用户创建的用户DSN，建议把Prod B DSN创建为系统DSN而非用户DSN

四、语句执行验证 #

• 查询时明确指定Schema名，例如SELECT * FROM ProdBDSN.你的Schema名.你的表名;，避免依赖默认Schema配置
• 清空SAS的本地缓存后再执行查询：先运行proc datasets lib=你的Prod B库名 kill; run;清空库的本地缓存，再执行查询语句

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