DTS - 手动步骤执行给出的结果与仅点击“运行”的结果不同。
我有一个 DTS（不是 SSIS）包，多年来我一直没有碰过它，我不得不用它来更新查询。当我通过在编辑器中手动执行每个步骤来运行包时，一切正常，并按预期生成一个包含数千条记录的文件。当我点击编辑器顶部的“执行”按钮来运行整个包时，它不会出错，但生成的文件仅包含 1 条记录。
包内的所有任务都是转换步骤或 Sql 任务。没有任何 ActiveX 脚本任务。当我观察进程本身运行步骤时，执行正确地遵循映射。
我对此一无所知。有人以前见过这个问题或者知道从哪里开始吗？
I have a DTS (not SSIS) package that hasn't been touched in years that I had to update a query with. When I run the package by manually executing each step in the editor, everything works out fine and generates a file of a couple thousand records as expected. When I hit the "Execute" button at the top of the editor to run the whole package, it doesn't error but the file is generated with only 1 record.
All tasks inside of the package are either transformation steps or Sql Tasks. There are not any ActiveX script tasks. When I watch the process as it's running the steps by itself, the execution is following the mapping correctly.
I'm at a loss on this one. Has anyone seen this issue before or have any idea where to start?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我最近遇到了类似的问题。在与高级 DBA 合作时，我们发现运行该包的服务器对网络上的目录没有正确的权限。该包在我的盒子中运行良好，但在生产服务器上失败了。我们需要向生产机器上的 sqlservice 帐户授予权限，以写入网络上的目录。
您可能还想检查任何更改数据泵步骤的连接字符串或目标的 ActiveX 脚本步骤。我遇到过 DTS 包运行的目标服务器上的情况不同的情况。
I just ran into a similar issue recently. While working with the senior DBA, we found that the server where the package ran did not have the right permissions to a directory on the network. The package ran fine in my box, but died on the production server. We need to give permissions to the sqlservice account on the production box, to write to the directory on the network.
You might also want to check out any ActiveX Script step that changes the connection string or destination of Data Pump steps. I've had cases where these were different on the destination server that the DTS packages run.
在检查了包中使用的所有存储过程和直接 SQL 任务的所有行之后，我找到了一个从未重置的 SET ROWCOUNT 1。当我分别手动执行每个步骤时，RowCount 会自动重置；但是，当它作为完整的包运行时，RowCount 从未重置。在特定脚本末尾添加 SET ROWCOUNT 0 解决了此问题。
After going through all of the lines of all of the stored procedures and straight sql tasks used in the package, I located a SET ROWCOUNT 1 that was never reset. While I was manually executing each step separately, the RowCount would be automatically reset; however, when it was run as a complete package, the RowCount was never reset. Adding SET ROWCOUNT 0 at the end of the particular script resolved this issue.