我知道“已經有一個與此連接相關聯的打開的 DataReader”（編輯：最初編寫的“命令”）存在類似的問題 - 但在所有情況下都涉及一些 SELECT 命令。我的情況不同：在這臺機器上，沒有執行 SELECT 命令（它們在不同的物理計算機上），只有 INSERT 和 UPDATE 命令。怎么會這樣？acommand.ExecuteNonQuery()或 a是否command.Prepare()仍然打開 DataReader？那將是一個WTF，但至少是一個解釋。
2 回答
蠱毒傳說
TA貢獻1895條經驗 獲得超3個贊
查看了SqlCommand和的參考源后OleDbCommand，它們的ExecuteNonQuery方法實現中都有一些快速路徑，這些路徑將嘗試避免打開數據讀取器，但都有一條慢速路徑，將回退到使用數據讀取器（顯然，數據讀取器路徑必須應對所有可能的選擇，并且他們不想重復所有這些代碼，并非不合理）。
我懷疑您用來連接的任何選項1mysql將有類似的實現。所以，首先也是最重要的，它不一定是SELECT引起沖突的。
不過，修復應該很簡單，并且是很好的一般建議。不要共享任何數據庫對象。當然，您的連接字符串只有一個來源，但一般來說，如果您需要一個連接對象，new則將其放在那里，然后在using語句中使用它。命令對象也是如此。對于讀者，您不會new自己修改它們，但您仍然需要using.
如果您不重用數據庫對象，則永遠不會出現此錯誤。唯一的例外（在我的書中）是如果您使用客戶端控制的事務（例如TransactionScope或類似的），您確實希望共享連接對象。但是您仍然不需要共享命令對象。如果事務如此廣泛，以至于您無法跟蹤（可能已經）在其上執行的所有命令，我建議它太大了。
1上次我看有幾個競爭者mysql可以使用IDbConnectionet al 層次結構、plusOleDbCommand和 family 的特定實現。
呼如林
TA貢獻1798條經驗 獲得超3個贊
根據 Bradley Grainger 的評論（MySqlConnection 的線程安全問題），我可以通過確保沒有并行運行查詢來解決這個問題。
這意味著原始異常消息可能是錯誤的（不能排除 Damien_The_Unbeliever 的回答中提到的一些奇怪的路徑）。
- 2 回答
- 0 關注
- 337 瀏覽
添加回答
舉報
0/150
提交
取消