C# .NET 4.0 には、次から取得した BlockingCollection があります。
サンプル BC_AddTakeCompleteAdding
私の問題は、.NET の SQLCommand.ExecuteNonQuery が間違った行数を返すことです。
更新は主キーにあるため、1 行を取得する必要があります。
正しい番号を取得する場合もあります。
.NET で 1 より大きい数値 (100 ～ 10000) を取得することがよくあります。
また、同じ PK に対してまったく同じ TSQL を実行した場合でも、常に同じ間違った番号になるとは限りません。
TSQL を SSMS にコピー ペーストして、毎回正しい答え (1) を得ることができます。
update [docSVsys] set [FTSstatus] = '1', [FTSdate] = '10/23/2012 8:51:32 AM' ,
textHash = '5b4d553360fbe733a66eebf36fa666f7', [textSize] = '39504'
where [sID] = '1525850'
使用中の変数を宣言し、rowsRet5 という名前の他の変数がない
int rowsRet5 = sqlCmdUpate.ExecuteNonQuery();
その textHash 値を確認したところ、1 行だけが更新されました。
適切な更新を実行しているように見えますが、間違ったカウントを報告します。
カウントが間違っているとすれば、これを本番データで使用するつもりはありません。
このコマンドは、コンシューマー側の最後にあります。
この更新の上に 2 つの .BeginExecuteNonQuery があります。
これらの更新は別のテーブルに対するものであり、docSVsys を参照していません。
これらのテーブルには、docSVsys への FK 参照があります。
デバッグでコールバックで停止した場合 (速度を落とした場合)、このエラーは発生しません。
タスクの BeginExecuteNonQuery が問題ではないかどうか疑問に思っています。
この間違った rowCount は、非同期の rowCounts のいずれにも一致しませんが、同じ範囲にあります。
この基本コードは、数百万行を処理しました。
TSQL は一切変更していません。
プロデューサー・コンシューマーに変換したらダメだった。
ドキュメントを進行中としてマークするには、プロデューサー側で非常によく似た TSQL を使用しますが、問題はありません。そのループには、BeginExecuteNonQuery もあります。