我来帮你梳理下这个问题的几个排查方向，毕竟SSIS在Visual Studio和SQL Server Agent环境下的运行上下文差异，经常是这类连接问题的根源：

1. SQL Server Agent服务账户的权限与环境问题 #

VS里运行包时用的是你的本地登录账户，但SQL Server Agent是用它自身的服务账户（比如Local System、Network Service或域账户）来执行作业的，这两个账户的环境权限差异很大：

• 确认Agent服务账户在AS/400系统中拥有读写目标表的权限，包括库（Library）的访问权限和表的操作权限；
• 检查Agent账户是否能访问IBMDA400驱动的安装路径，甚至可以尝试用Agent服务账户登录到SQL Server所在服务器，重新安装一遍IBMDA400驱动——因为有些驱动只会在当前登录用户的环境中注册；
• 如果Agent用的是域账户，要确保这个账户能通过网络正常访问AS/400服务器，没有防火墙、路由或AD组策略的限制。

2. 连接字符串的显式配置 #

有时候VS图形界面配置的连接会依赖默认值，嵌套执行时这些默认值可能在Agent环境下不生效：

• 把连接字符串改成完全显式的格式，比如：

  Provider=IBMDA400;Data Source=你的AS400服务器名;User ID=AS400账户;Password=AS400密码;Default Collection=目标库名;
  

  不要依赖任何默认参数，确保所有必要信息都写全；
• 尽量避免使用Windows身份验证连接AS/400，改用AS/400本地账户——因为Agent的服务账户可能无法直接映射到AS/400的身份体系。

3. 嵌套包的连接传递问题 #

当用Execute Package Task调用子包时，连接可能没有正确继承或加载：

• 把父包和子包的连接都配置为包级连接（而非项目级连接，如果是项目部署模式），确保子包能独立获取连接配置；
• 不要让子包依赖父包的变量来配置连接，直接在子包里写死正确的连接字符串，或者使用Agent账户能访问的配置文件来存储连接信息；
• 检查Execute Package Task的“连接”选项，确认子包的存储位置（文件系统或SSISDB）对Agent账户是可读取的。

4. 32/64位驱动的兼容性验证 #

虽然你试过以32位模式运行作业，但要确保Agent的32位环境真的加载了正确的驱动：

• 打开C:\Windows\SysWOW64\odbcad32.exe（32位ODBC管理器），检查是否存在IBMDA400驱动，并且配置了正确的DSN（如果使用DSN连接的话）；
• 如果是64位SQL Server，Agent的32位作业步骤必须对应32位版本的IBMDA400驱动，且驱动要安装在SysWOW64对应的路径下。

5. 进阶日志与调试 #

如果错误信息不够详细，可以通过更细的日志定位问题：

• 给子包开启详细日志记录，勾选“OnError”、“OnInformation”等事件，运行Agent作业后查看日志，获取更具体的错误提示（比如驱动找不到、身份验证失败等）；
• 用Agent的服务账户登录到SQL Server所在服务器，手动执行子包（用dtexec命令：dtexec /f "子包文件路径.dtsx"），看是否能重现错误——这样可以直接在Agent账户的环境下排查问题，更容易定位根源。

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