sql-server - 为什么在调试模式下运行父包时，子 SSIS 包的 .dtsx 文件会在 BIDS 中打开？

Question

SSIS 2008 R2 + 投标

我正在重写 ETL 作业。该作业由大约 50 个步骤组成，其中一些是 SSIS 包，其中一些只是存储的 proc 调用。我正在编写一个包装程序（Gatekeeper），它检查这些“步骤”中的哪些已准备好执行，然后执行适当的 .dtsx 包或存储的过程。

当 Gatekeeper 启动时，调用存储过程来获取当前运行的“步骤”列表。然后它通过 a Foreach Loop，根据标志列检查“步骤”是包还是 proc，然后为该步骤动态运行适当的任务类型。步骤完成后，我记录成功或失败，并迭代 Foreach 循环。

到目前为止，我已经了解了包的业务逻辑和动态执行以及存储过程的正常工作。对于存储的 proc 调用，我在字符串变量中构建查询，并使用Execute SQL Taskwith SqlStatementSourceTypeset to Variable。对于包，我使用一个Execute Package Task使用File Connection Manager一个表达式来将 ConnectionString 设置为文件系统上 .dtsx 文件的路径的一个。

这一切都按照我的意愿工作，并且在适当的时间执行适当的存储过程和包。

所以有什么问题？我注意到，当 Gatekeeper 必须连续执行 2 个或更多包时，当它Execute Package Task连续命中每一次时，BIDS 会尝试打开先前完成的子包。我们使用的所有包都使用密码加密（所有文件都相同），当 BIDS 尝试打开文件时，我会收到“包密码”提示。

奇怪的是，如果 order 是Package -> proc -> package，则不会发生奇怪的文件打开行为。我已经尝试更改DelayValidation子包和 Gatekeeper 中的各种值，我尝试在父进程内部和外部运行，但这些似乎与问题没有任何关系。

这是Gatekeeper的截图Control Flow：

这是 的配置File Connection Manager：

这是 的配置Execute Package Task：

编辑：

凭直觉，我尝试先在 BIDS 中打开两个子包，然后再运行 Gatekeeper 的测试执行。我看着 BIDS 连接到第一个子包并在调试模式下完成它的任务。“很酷，也许它只是试图打开文件以在调试模式下运行它”我想。没有。一旦它碰到第二个子包，BIDS 就会尝试打开第一个子包的另一个副本。

编辑2：

在我发布之前的编辑后，我意识到我可能没有打开 Gatekeeper 试图运行的完全相同的文件。我打开了 TFS 本地文件夹中的源文件，而不是实际部署到文件系统的包。所以我关闭了子文件的源文件，并让第一个部署的子文件保持打开状态并重新运行 Gatekeeper。它在第一次迭代时仍然挂在打开的子文件中，令我惊讶的是，它在第​​二次迭代时并没有尝试打开子 #1 的另一个副本。

所以我现在的想法是，这是 BIDS 的某种奇怪的调试问题。我的下一个测试是将 Gatekeeper 部署到测试服务器，看看我在通过 SQL 代理作业执行它时是否遇到任何问题。

标签： sql-serverssisbidsssis-2008

Answer 1

我从来没有弄清楚 BIDS 的问题，但我找到了解决方法。我没有尝试直接从 Gatekeeper 执行子程序包，而是有一个 SQL 代理作业，它将所有子程序作为单独的步骤。每个步骤都配置为成功或失败时退出。

Gatekeeper 调用一个存储过程，该过程提供准备执行的子步骤的job_id 和step_id。然后它使用这些值msdb.dbo.sp_start_job在Execute SQL Task. 我使用的代码是：

DECLARE @step VARCHAR(100)
,@Job VARCHAR(100)

SET @step = ?
SET @Job = ?

EXEC msdb.dbo.sp_start_job @job_id = @job, @step_name = @step

我不得不改变Control Flow一点。我不再关心孩子是 proc 还是 SSIS 包，但我需要在开始子作业步骤之前检查“子步骤”作业是否没有运行，但我必须添加一些等待，所以 SSIS 没有不要尝试sp_start_job过早执行。