ソースLOB列を処理するときの「行ごとの」フェッチメソッドの回避

SSISを使用して新しいSQL Serverスキーマに移行しようとしているレガシーPostgreSQLデータベースソース（ODBC）があります。次のような警告が表示されます。

テーブルにLOB列があるため、「Row by Row」フェッチメソッドが適用されます。列の内容はLOBです

実は、どの列も実際にLOBである必要はありません。TEXT型はいくつかありますが、varchar（max）内に簡単に収まります。でも見知らぬ人は、しかし、最もすでにある VARCHARが、それはLOBであるかのように扱われているvarchar型以上のもの（128）らしい（事前のプロパティでは、データ型はDT_NTEXTです）。

selectステートメントですべての文字列型を適切な長さのvarcharに明示的にキャストし、ODBCソースでDT_NTEXTとして設定されているSQLコマンドを手動で実行しようとしました。

私はDBAではないので、本当に愚かなことをしている可能性は十分にあります。バッチフェッチできるように、型が最終的にvarcharになるようにするための最良の方法を知りたいのですが。何か案は？

必要に応じて、Visual Studio 2013内でSSIS-BI 2014を使用しています。

どうやらこれは、128より大きいvarcharをNTEXTとして扱うSSISに要約されます。なぜだかわかりません。ただし、ODBCソースの詳細プロパティに移動して、タイプをDT​​_WSTRのようなものに戻すことができます。ほとんどの部分でうまくいくようです。

ただし、私が処理しているいくつかのテーブルが実際にそれらのTEXT列の一部で4000バイト以上を運んでいると判断したため、残念ながら、これらの列をDT_NTEXTのままにして、切り捨てを防止する必要があります（SSISでは許可されません） 4000バイトを超えるDT_WSTRタイプを設定した場合）。これらのインスタンスでは、行ごとのフェッチに行き詰まっていると思いますが、少なくともいくつかのテーブルを修正することができました。

NTEXTとして128より大きいvarcharのデータ変換を使用しましたが、最終的にエラーを削除したのは、Validate External DataをFalseに設定したことです。

この解決策は私にとってうまくいきました：

datasourceプロパティのMax Varcharパラメータを変更して、エラーを取り除きました。接続マネージャーに移動します。接続文字列の横にあるビルドオプションを選択します。接続ボタンをクリックして、その他のオプションにアクセスします。Max Varcharの値を変更します。

私の場合、ソースはFilemaker ODBCで、長いテキストもLOBデータ型として扱われます。テーブルごとにLOB列があるため、Row by Rowフェッチメソッドのパフォーマンスが極端に低下するために長い間ハングしていたパッケージが強制されます。したがって、デプロイされている間、長い時間をかけてタイムアウトになり、最終的に失敗していました。

私にとって魅力のように機能した実際のソリューションを共有しています。30kを超えるLOBタイプのデータのプルに1日かかるのに約10分かかりました。

DefaultBufferMaxRowsを1に下げ、DefaultBufferSizeを最大、つまり100 MBに増やします。次に、オプション「テキストを長いvarcharとして扱う」をチェックして、ソースODBC DSNを変更します。そして、ソースからターゲットにデータ型をそのままマップします（ソースの高度なエディターを変更せずに）。