TLDRバージョン：一括挿入は、影響を受けた行数を示します。影響を与えようとした行数や失敗した行数はわかりません。これに関する問題は直感的に明らかであり、コードをサーバー内に保持して、テキストファイルからアップロードするより信頼性の高い方法があるかどうかを知りたいです。
フルバージョン：テキストデータファイルをSQLServerテーブルに定期的にアップロードする必要があるアプリケーションがあります。いくつかのワイルドでクレイジーな理由で、フロントエンドアプリケーションにテーブルに直接書き込むのではなく、これをストアドプロシージャに入れて、抽象化レイヤーの一部にすることを考えました。
ほとんどのSQLServerスクリプトと同様に、私は通常の時間を費やして、レンガの壁に頭をぶつけて、それを完全に機能させました。（このサイトや他のサイトの過去の投稿を検索することで、少なからず助けが得られます。）
Bulk Insertはヘッダー行を読み取り、書き込むフィールドを決定しますか？いいえ、フォーマットファイルを使用するか（テーブルの構造/順序が変更されないことを願っています）、データファイルの列のみを含むステージングテーブルを使用する必要があります。ステージングテーブルは、データを実際のテーブルにコピーする前にデータを受け取ります。
ターゲットテーブルの1つの列（デフォルトの列も含む）を省略し、フォーマットファイルを使用しない場合はどうなりますか？「リンクサーバー"（null）"のOLEDBプロバイダー"BULK"から行をフェッチできません。」という非常にわかりやすいエラーメッセージが表示されます。前述のステージングテーブルを使用して、データソースにない列を省略して、これを回避します。
それは結構です、私はそれと一緒に暮らすことができます。怖い部分ではありません。これは。
ステージングテーブルにNOTNULLとして定義されているフィールドがまだあるが、その列のデータソース行がnullである場合、エラーは発生しません。私のテストに基づくと、（たとえば）5行のデータがあり、行3のNOT NULLフィールドにデータがない場合、エラーは発生しませんが、「4行が更新されました」というメッセージが表示されます。5行を期待し、影響を受ける行数とクロスチェックして、期待される数が存在することを確認する場合は、これで問題ありませんが、これらのファイルの長さはさまざまであり、一括挿入ではわかりません。実際に読み取った行数。さらに悪いことに、1つの行にフィールドがない場合、次の（有効な）行もアップロードできなくなることがあります。
明らかな解決策は？ステージングテーブルからNOTNULL制約を削除し、ステージングテーブルと実際のテーブルの間のインターフェイスでnull例外を処理します。しかし...私の懸念は、この曲がまだ出会っていない他の状況でも同じことをするかもしれないということです。つまり、行を読み取り、ステージングテーブルへの書き込みに失敗し、例外をスローしないようにして、データを探しに行き、そこにないことがわかるまで、データが欠落していることを誰も知らないようにします。Accessでさえ、これよりも優れたテキストインポートオプションがあります。
それでは、私の質問は...フロントエンドアプリに依存せずにSQL Serverへの可変行長テキストファイルのアップロードを処理するためのより良い（より信頼性の高い）方法はありますか？
アドバイスをよろしくお願いします。