ソースLOB列を処理するときの「行ごとの」フェッチメソッドの回避
SSISを使用して新しいSQL Serverスキーマに移行しようとしているレガシーPostgreSQLデータベースソース（ODBC）があります。次のような警告が表示されます。
テーブルにLOB列があるため、「Row by Row」フェッチメソッドが適用されます。列の内容はLOBです
実は、どの列も実際にはLOBである必要はありません。 TEXT型はいくつかありますが、varchar（max）内に簡単に収まります。さらに奇妙なことに、ほとんどの場合はvarcharsですが、varchar（128）を超えるものはLOBであるかのように扱われているようです（事前のプロパティ、データ型は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列があるためです。したがって、展開されている間、長い時間をかけてタイムアウトし、最終的に失敗していました。
私にとって魅力のように機能した実際のソリューションを共有しています。 30kを超えるLOBタイプのデータをプルする1日は、約10分かかりました。
DefaultBufferMaxRowsを1に下げ、DefaultBufferSizeを最大（つまり100 MB）に増やします。次に、オプションをチェックしてソースを変更しますODBC DSNオプション 'long text as long varchar'をチェックします。ソースからターゲットにデータ型をそのままマッピングします（ソースの高度なエディターを変更せずに）。