Sql server ssis xml配置-配置覆盖包-ssis是否在您不告诉它的情况下更改配置？

昨天我工作了一整天，试图消除XML配置文件中不正确连接字符串的影响。我检查了每个包，删除了有故障的连接管理器，并用正确的服务器名称重新添加了它。每次执行此操作时，我都会通过删除配置来显式更新配置，然后使用覆盖选项重新添加配置。但后来我犯了一个可怕的错误，拉上了父包，它使用了不同的xml配置，再次将连接管理器更新为错误的服务器名称

我从父包中取出配置，并再次开始修复子包。修复了这些子包之后，我从现在无xml配置的父包调用了其中一个。我真的很震惊和失望地看到，它再次在连接错误的服务器

这怎么会发生

我还通过wordpad++注意到配置文件已更新。我的假设是，当父级配置更新连接管理器时，SSIS会自动更新现在已更正的配置文件，并再次将其破坏

---

SSI是否真的在其组件更改时自动更新配置文件？真的是这样吗？如果是这样的话，那就是完全令人困惑的行为——比如乒乓球，或者把手指伸进堤坝。我准备好建议我们永远不要使用XML配置

更新：我错了。见下面我的评论

因此，我认为您对SSI中的配置如何工作有一个（可能有两个）基本误解

使连接管理器可配置的标准过程是：

创建连接管理器，将其指向BIDS中的本地/dev连接

为连接管理器的ConnectionString、ServerName和DatabaseName属性创建一个配置。（如果是文件，请添加文件路径等）

在后续的软件包中，只需创建相同的连接管理器，添加一个配置，将其指向现有的配置文件，然后选择“重用现有…”（而不是“覆盖”，这将抛出您在步骤2中所做的所有工作。）

将包部署到服务器，并将XML文件部署到服务器上的同一本地位置

修改服务器上的XML文件，以指向该服务器的正确数据库连接（开发、登台、生产等）

在该服务器上运行包时，它将在运行时使用该XML文件，并在运行时使用服务器各自的数据库

完全可选：我们实际上每个数据源使用一个XML文件，并显式命名为连接管理器。这意味着我们可以通过连接管理器的命名约定“保证”所有需要使用某个数据库的包都访问完全相同的数据库。我们将这些数据源存储在项目级别，只需从数据源创建新的连接，然后使用匹配的名称“重用现有”添加配置，点击OK，就可以了

因此，您的一个误解是删除了连接管理器。配置文件不会“更新”连接管理器。连接管理器的属性在设计时设置，并且是您在投标中双击它时看到的任何属性。这些是硬编码到包中的（查看代码并亲自查看），只能在连接管理器编辑器中更改。因此，没有“错误”的连接管理器，删除它也没有意义——只要在编辑器中测试连接时获得“成功”，该连接管理器就可以运行

第二个误解是配置文件是如何工作的。配置文件仅在运行时将包执行中的属性替换为自己的值。它根本不会修改包。相反，SSIS包本身永远不会修改配置文件。这只能通过投标流程之外的文本编辑器或通过投标配置编辑器完成，我相信这就是发生的情况

我不能确切地根据您提供的一般时间线来判断，但您使用覆盖选项表明，您基本上允许最后进行的任何配置编辑“赢得”设置所有文件将用于该特定连接的值的特权

---

无论如何，我会（正如您可能猜到的那样）完全推荐使用XML配置，因为它们是（或者我认为是！）非常简单的，而且在我看来，这是多层SSIS环境最简单的部署选项。

需要澄清的是：XML配置不会“更新”包中的连接管理器。曾经在运行时，如果您选择使用配置，它将用自己配置的值替换包中的默认值。您可以做一件事：在XML配置文件本身的顶部有一行，指示哪个包生成了该特定文件以及生成该文件的时间。如果我在Visual Studio中有一个包，如果我在XML配置中修改connectionstring中的servername（将服务器A更改为服务器B），并运行包，那么我期望的行为是正常的，它会将数据写入第二台服务器上的表中。我不期望的行为是这样的。当我在visual studio包中启动连接管理器时，服务器A已更改为服务器B SSIS已修改了我包中的代码。在我看来，它应该只在运行时覆盖值，而不是在设计时覆盖包！！所以如果您使用的是直接连接管理器连接而不是数据源，那么看起来您是对的。当我使用一个数据源并在配置中修改该值时，我会收到一条警告，指出该数据源未同步，然后“重置”该数据源