ほぼ同一のパッケージがいくつかあります。異なるデータベース バージョンで追加/削除された列のみが異なります。パッケージをコピーしてコピーのデータ フローを変更するとき、OLE DB データ ソースを削除して新しいものを追加します。新しいものが定義されると、そのプレビューはまさに私が期待するものを示します。ただし、列は削除された OLE DB ソースからのものです。どこかにキャッシュされているようなものです。
データ ソースを削除した後、パッケージを閉じて再度開く必要があるようです。このキャッシュされた状態をクリアする他の方法はありますか? これを引き起こす内部で何が起こっているのですか？
詳細...パッケージが閉じられて再度開かれるまで、以前のパラメーターを保持しているのは、パラメーター化された接続マネージャーのようです。
あなたのワークフローを理解していれば、パッケージをコピーして貼り付け、データ フローでソース定義を微調整していることになります。問題は、あるシステムの CustomerID が varchar(7) であり、別のシステムでは varchar(12) として定義されていることです。「トリック」は、設計エンジンにメタデータの変更を認識させ、それに応じて動作させることになります。
私の通常のハックは、ソースを根本的に変更することです。クエリを使用するとうまくいくことがわかりSELECT 1 as fooました。その後、OLE DB ソース コンポーネントのメタデータは既存の列へのすべての参照を削除し、ダウンストリーム コンポーネントに浸透します。次に、適切なソースに戻り、最初の赤い X をダブルクリックして、古い ID から新しい ID にマップします。
内戦手術よりも脳外科手術が必要な場合は、メタデータの変更を登録する必要があるものについて、ソースの列名を変更してください。したがって、データフロー全体で最初の列のみがキボッシュされるようにSELECT T.MyColumn, T.IsFine FROM dbo.MyTable AS Tなりました。SELECT T.MyColumnX, T.IsFine FROM dbo.MyTable AS T「正しい」列名に戻すと、すべて問題ありません。
内部的にはわかりませんが、推測を止めることはありません。検証が開始され、SSIS エンジンはデータ型がまだ互換性があることを認識し、既存のメタデータを変更しません。存在しなくなった列は、立ち上がって注意を引くのに十分であるため、キャッシュされたサイズはなくなります。
詳細プロパティを使用してサイズを変更することを好む人もいますが、サイズを変更するだけでデザイナーに手を叩いて提案された変更を拒否させるよりも、上記のアプローチを使用する方がうまくいくことがわかりました。