更新：私は間違っていました。以下の私のコメントを参照してください。
したがって、SSIS の構成がどのように機能するかについて、1 つ (おそらく 2 つ) の根本的な誤解があると思います。
接続マネージャーを構成可能にする標準的なプロセスは次のとおりです。
- 接続マネージャーを作成し、それを BIDS のローカル / dev 接続に向けます。
- 接続マネージャーの ConnectionString、ServerName、および DatabaseName プロパティの構成を 1 つ作成します。(ファイルの場合は、filePath などを追加します)
- 後続のパッケージでは、同じ接続マネージャーを作成し、構成を追加し、それを既存の構成ファイルにポイントし、"Reuse Existing ..." ( "Overwrite"ではなく、手順 2 で行ったすべての作業を破棄します) を選択します。 )
- パッケージをサーバーに展開し、XML ファイルをサーバー上の同じローカルの場所に展開します。
- サーバー上の XML ファイルを変更して、そのサーバー (dev、staging、production など) の適切なデータベース接続を指すようにします。
- そのサーバーでパッケージを実行すると、実行時にその XML ファイルが使用され、実行時にサーバーのそれぞれのデータベースが使用されます。
- 完全にオプション: 実際には、データ ソースごとに 1 つの XML ファイルを使用し、明示的に名前を付けた接続マネージャーを使用します。これは、特定のデータベースを使用する必要があるすべてのパッケージがまったく同じデータベースにアクセスすることを、接続マネージャーの命名規則によって「保証」できることを意味します。これらのデータ ソースをプロジェクト レベルで保存し、データ ソースから新しい接続を作成してから、一致する名前の [既存の再利用] で構成を追加し、[OK] をクリックするだけで準備完了です。
したがって、接続マネージャーを削除するという誤解があります。構成ファイルは、接続マネージャーを「更新」しません。接続マネージャーのプロパティは設計時に設定され、BIDS でダブルクリックしたときに表示されるものです。これらはパッケージにハードコードされており (コードを表示して確認してください)、接続マネージャー エディター自体でのみ変更できます。したがって、「障害のある」接続マネージャーのようなものはなく、それを削除しても意味がありません。エディターで接続をテストして「成功」した場合、その接続マネージャーは問題ありません。
2 番目の誤解は、構成ファイルがどのように機能するかです。構成ファイルは、実行時にパッケージ実行のプロパティを独自の値に置き換えるだけです。パッケージはまったく変更されません。逆に、SSIS パッケージ自体が構成ファイルを変更することはありません。これは、BIDS プロセスの外でテキスト エディターを使用するか、BIDS 構成エディターを介してのみ行うことができます。
あなたが提供した一般的なタイムラインの種類では正確にわかりませんが、上書きオプションを使用することは、基本的に、最後に行われた構成編集を許可して、すべてのファイルが使用する値を設定する特権を「獲得」したことを示唆していますその特定の接続のために。
とにかく、私は (おそらくご想像のとおり) XML 構成を使用することを完全にお勧めします (または、私は思っていました!) 非常に簡単で、私の意見では、多層 SSIS 環境の最も簡単な展開オプションです。