TSQL ADO.NET不正確的行數返回

樣品BC_AddTakeCompleteAdding

我的問題是，在.NET中SQLCommand.ExecuteNonQuery是採取了BlockingCollection返回錯誤的行數。
更新在主鍵上，所以應該得到一行。
有時會得到正確的數字。
通常在.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值，只有一個行被更新。
它似乎執行正確的更新，但報告錯誤的計數。
鑑於計數錯誤不願意在生產數據上使用它。

該命令位於客戶端的末尾。
在此更新之上有兩個.BeginExecuteNonQuery。
這些更新是針對不同的表格，並且不引用docSVsys。
這些表確實有FK參考docSVsys。
在調試中，如果我停在回調（慢下來），那麼我不會得到這個錯誤。
我想知道如果BeginExecuteNonQuery任務不是問題。
這個錯誤的rowCount與任何異步rowCounts不匹配，但在相同的範圍內。

此基本代碼已處理了數百萬行。
未更改任何TSQL。
轉換爲生產者消費者時，它變得很糟糕。

要將文檔標記爲正在處理中，請在生產者端使用非常類似的TSQL，並且不存在任何問題。該循環也有一個BeginExecuteNonQuery。

來源

2012-10-23 Paparazzi

問題似乎是在生產者和消費者方面共享連接和命令。

是的我意識到這顯然是一件壞事。
當它是一個單一的循環（沒有生產者消費者雙方）時，可以共享該命令。
當我轉換爲消費者生產者時，我並不認爲要拆分命令。

來源

2012-10-23 17:25:26 Paparazzi

TSQL ADO.NET不正確的行數返回

回答

相關問題