SSIS は、特に苛立たしいフラット ファイルの処理に関して 2 つのことを行います。それらを回避する方法があるはずですが、私にはわかりません。10 列のフラット ファイルを定義し、CRLF で区切られたタブを行の終わりマーカーとして定義する場合、これは、各行に正確に 10 列があるファイルに対して完全に機能します。2 つの困難なシナリオは次のとおりです。
誰かが 11 列目のファイルをどこかに提供した場合、SSIS がそれを定義していないので、単純に無視してくれるとよいでしょう。定義した 10 列を読み取り、行マーカーの最後までスキップするだけですが、代わりに追加データを 10 列目のデータと連結し、そのすべてを 10 列目にぶつけます。なんか本当に駄目。これは、10 番目の列の区切り文字が他のすべてのようなタブではなく CRLF であるため、CRLF までのすべてを取得し、余分なタブを何も置き換えないために発生することに気付きました。私の意見では、これは賢明ではありません。
誰かが 9 列しかないファイルを提供すると、さらに悪いことが起こります。予期せず見つかった CRLF を一時的に無視し、欠落している列を次の行の先頭から列で埋めます! ここでは、賢くないというのは控えめな表現です。誰がそれを望んでいますか？その時点で、ファイルの残りの部分はガベージです。
なんらかの理由でファイル幅にバリエーションを持たせることは不合理ではないようです (もちろん、行末のバリエーションのみを合理的に処理できます (x 少ない列または余分な列))。何かが足りない。
これまでのところ、これに対する唯一の解決策は、行を 1 つの巨大な列 (column0) としてロードし、スクリプト タスクを使用して、見つかった区切り文字を使用して動的に分割することです。行幅を 4000 文字 (1 つの Unicode 列の最大幅) に制限することを除いて、これはうまく機能します。幅の広い行をインポートする必要がある場合 (たとえば、テキスト インポート用に複数の 4000 幅の列がある場合)、上記のように複数の列を定義する必要がありますが、行ごとに厳密な数の列を要求することになります。
これらの制限を回避する方法はありますか?