列を自動的にマッピングしないデータフロー変換
50のテーブルからデータをインポートする一連のSSIS 2014パッケージ（Visual Studio 2013を使用）を作成している最中です。ほとんどのテーブルが同じ列でフィルター処理されており、すべての列をステージング領域にインポートしているので、パッケージ名がテーブル名と一致する再利用可能なデザインを選択しましたOLE DBソースクエリは式ベースの変数（SELECT * FROM <tablename>...で始まる）で定義され、my OLE DB宛先テーブルも式ベースの変数で定義されます（この場合- schema.tablename）。
ソースクエリとターゲットテーブルの両方に一致する列名があり、ほとんどの場合、データ型とサイズが一致します。
各テーブルのパッケージを複製しているので、以前に作成したパッケージをコピーして貼り付け、マッピングを視覚的に検査して、式とデータフローマッピングが新しいパッケージ名に対して有効であることを確認します。式は予定どおりに機能しているようですが、宛先エディターでほとんどの列のドラッグ/ドロップマッピングを手動で行う必要があります。
元のパッケージのデザインメタデータは新しいパッケージ名では無効であり、Visual Studioで列名に基づいてデータフロー内のすべての列を削除して再マップする方法があるので、エディターの予想される動作はありますか？
SSISパッケージをコピーして貼り付けると、いくつかの問題が発生する可能性があります。ソースから宛先へのデータフローという単純なパッケージがあるようです。一般的に、私が遭遇したハングアップはありませんが、データ型の定義に一貫性がないという状況を見てきました。メール-varchar（40）、varchar（80）、varchar（120）、nvarchar（256）はすべて、同じデータベース内の異なるテーブルにあります。起こり得ることは、最初に80サイズを使用してパッケージをビルドすることです。ソーステーブルをコピーして貼り付けて修正すると、古いサイズに収まるため、40テーブルに移動したときに、データサイズの変更がエディターで認識されない場合があります。しかし、私は逆も見ました-それは増加したサイズを拾わないかもしれません。解決策はひどいものではありません。クエリをselect 1 AS xに変更し、メタデータを設定してから、クエリを修正して適切な選択に戻します。
Daveが示唆したように、このタスクはエントリーレベルのBimlタスクに最適です。実際、明示的なソースクエリがなくても構わないのと同様に、私の Biml replicate-o-matic は、まさにあなたが説明しているものです。以前の化身は [〜＃〜] so [〜＃〜] にあり、リンクの腐敗を防ぐためにそれにリンクしています。
あなたのアプローチが好きなら、あなたはあなたのアプローチを続けることができます。ただし、目的地でのクリックとドラッグを省いて、右クリック3回、左3回の6回のクリックに置き換えてください。マッピングタブで右クリックして、この状況依存メニューを表示します
「すべてのマッピングを選択」を左クリックします
右クリックして左クリックし、「選択したマッピングを削除」
右クリックしてから左クリックして、「名前の一致によるアイテムのマップ」
はい、参照を解決した後でも、宛先は適切に自動マッピングされません。新しい宛先を作成するか、宛先用に別のテーブルを選択し、受け入れ/クローズしてから、目的のターゲットを開いて選択する必要があります。これで、列の関連付けが自動解決されるはずです。私も以前にその問題に遭遇しました。
今後50個のテーブルがわかる50個のテーブルがあるので、 [〜＃〜] biml [〜＃〜] をチェックしてください 各パッケージのXMLを生成 およびしたがって（すべてを正しく設定したと仮定して）、作成されたパッケージを検査する必要さえありません。