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

Question

SSIS 2008 R2 + BIDS

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

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

到目前为止，我已经获得了业务逻辑以及程序包和存储过程的动态执行正确运行。对于存储的proc调用，我将查询构建在字符串变量中，并使用Execute SQL Task设置为SqlStatementSourceType的{​​{1}}。对于软件包，我使用的Variable使用Execute Package Task，后者使用表达式将ConnectionString设置为文件系统上.dtsx文件的路径。

这一切都按我希望的方式工作，并且在适当的时间执行了适当的存储过程和程序包。

那是什么问题？我注意到，当网闸必须连续执行2个或更多程序包时，当它每次连续命中File Connection Manager时，BIDS都会尝试打开先前完成的子程序包。我们使用的所有软件包都使用密码加密（所有文件都相同），当BIDS尝试打开文件时，我收到“ Package Password”提示。

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

这是关守的DelayValidation的屏幕截图：

这是Control Flow的配置：

这是File Connection Manager的配置：

编辑：

一个预感，我尝试在对Gatekeeper进行测试执行之前先抢先在BIDS中打开两个子程序包。我看着BIDS挂在第一个子程序包中，并在调试模式下完成了它的任务。我想：“很酷，也许它只是试图打开文件以使其在调试模式下运行。”不。一旦到达第二个子程序包，BIDS便尝试打开第一个子程序包的另一个副本。

编辑2：

在发布之前的编辑后，我立即意识到我可能尚未打开与Gatekeeper试图运行的文件完全相同的文件。我从TFS本地文件夹中打开了源文件，而不是实际部署到文件系统中的包。因此，我关闭了子级的源文件，并打开了第一个部署的子级文件，然后重新运行Gatekeeper。它仍然在第一次迭代中挂接到打开的子文件中，令我惊讶的是，它在第​​二次迭代中没有尝试打开子＃1的另一个副本。

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

Answer 1

我从没有解决BIDS的问题，但是找到了解决方法。我没有尝试直接从Gatekeeper执行子程序包，而是使用了一个SQL Agent Job，该程序将所有子级作为单独的步骤。每个步骤都配置为在成功或失败时退出。

关守调用存储的proc，该proc提供准备执行的子步骤的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。