SSMA 18.8迁移System i DB2表至SQL Server 2019无列返回报错解决

报错核心原因：
对应SQLCODE -206、SQLSTATE 42703的报错，以及提示的“未找到列或全局变量N”，本质是SSMA向IBM i DB2请求源表元数据时，查询链路在某环节失效，DB2返回了空值占位符N——这是IBM i系统在元数据解析失败时的通用缺省标记，并非真实存在的业务列，最终导致SSMA拿不到源表的列结构，无法完成后续迁移。

修正步骤按排查优先级排序：

• 校验连接账号的系统目录访问权限
  • 用于SSMA连接DB2的账号，必须对QSYS2库下的SYSTABLES、SYSCOLUMNS核心系统元数据视图保有读权限。权限不足时DB2不会直接抛出权限类报错，反而会在内部元数据解析时触发占位符*N的引用，完全匹配本次的报错特征。
  • 修正操作：在IBM i命令行执行授权操作，给SSMA的连接账号授予QSYS2库的执行权限，对应命令：GRANT EXECUTE ON SCHEMA QSYS2 TO <你的SSMA连接账号>，授权完成后重启SSMA的数据库连接，重新拉取元数据。
• 检查SSMA连接器的版本适配性
  • IBM i平台的DB2和通用分布式版本的DB2 LUW是两套独立体系，如果错用面向DB2 LUW的SSMA连接器拉取IBM i的表，连接器内置的元数据查询SQL和IBM i的系统表结构不匹配，就会触发对不存在的*N占位列的引用，最终返回空列集。
  • 修正操作：卸载当前SSMA中加载的DB2 LUW连接器，安装适配IBM i平台的专用SSMA扩展组件，确保元数据查询逻辑和IBM i的系统目录结构匹配。
• 定位异常源表的自身状态
  • 如果报错仅针对部分特定表触发，而非所有迁移表加载时都失败，需要排查这些表的运行状态：当表处于损坏、恢复未完成、被排他锁锁定的状态时，DB2的系统目录会把表对应的列集标记为*N空占位，导致SSMA拉取失败。
  • 修正操作：在IBM i端执行DSPFD <问题表名>命令检查表状态，将异常表恢复为可正常读取的状态后，在SSMA中刷新对应表的元数据。
• 清理本地SSMA的损坏缓存
  • 之前中断的迁移操作可能会残留损坏的本地元数据缓存，SSMA读取到损坏缓存时，会尝试引用虚拟的*N列完成结构加载，触发报错。
  • 修正操作：关闭SSMA客户端，删除本地缓存路径下的残留文件：%USERPROFILE%\AppData\Local\Microsoft\SSMA for DB2，重启SSMA后重新建立数据库连接，即可正常加载源表结构。

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