通过SQL作业代理执行SSIS包时遇ODBC错误求助

我之前也踩过一模一样的坑——SSIS包在Visual Studio里跑起来顺得不行，一丢去SQL Server代理作业里执行就炸锅，报DTS_E_PRIMEOUTPUTFAILED错误，ODBC源用的也是IBM i Access for Windows驱动。结合你的排查过程和最终解决办法，整理下实用的关键点：

先试常规排查项（你已经做过的可以参考） #

• 强制32位运行：IBM i的ODBC驱动大多是32位的，SQL Server代理默认用64位执行，所以一定要在作业步骤的「执行选项」里勾选「使用32位运行时」，这是很多人忽略的基础操作。
• 核对连接配置：确认代理服务账号有权限访问IBM i数据源，项目里的连接参数、认证信息在部署后有没有被正确覆盖——毕竟VS用的是你本地的上下文，代理用的是服务账号的环境，很容易出现配置不一致的情况。

终极解决：改用OPENQUERY #

当上面的调整都没用时，把ODBC源的直接查询换成OPENQUERY访问IBM i数据，真的能解决很多驱动层面的兼容性问题，尤其是跨平台数据类型映射的坑。

特别注意：数值列的十进制问题 #

这里必须划重点！我之前也栽在十进制/数值类型列上：

• IBM i的DECIMAL类型和SQL Server的数值类型在精度、小数位的映射逻辑不一样，直接查询时驱动的自动转换很容易失败，导致管道中断。
• 用OPENQUERY的时候，一定要在查询里显式转换数值列的类型，比如用CAST或CONVERT把IBM i的数值转成SQL Server兼容的格式，避免隐式转换带来的意外错误。

举个实际的例子：
原来的ODBC直接查询：

SELECT OrderID, TotalAmount FROM IBMILIB.ORDERS

改成OPENQUERY后调整为：

SELECT OrderID, CAST(TotalAmount AS DECIMAL(18,2)) AS TotalAmount
FROM OPENQUERY(IBMIDSN, 'SELECT OrderID, TotalAmount FROM IBMILIB.ORDERS')

这样强制统一数据类型，能大幅减少驱动转换的不确定性。

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