Linq DataContext SubmitChanges從ZombieCheck發出InvalidOperationException

嘗試使用LinqToSql添加行時，我得到一個InvalidOperationException。我們不能在內部複製它，只有我們的一個客戶發生約0.06％的情況，總是對數據庫進行相對簡單的更改。（單列插入或單個字段更新）Linq DataContext SubmitChanges從ZombieCheck發出InvalidOperationException

Message: 
    This SqlTransaction has completed; it is no longer usable. 
Stack Trace: 
    at System.Data.SqlClient.SqlTransaction.ZombieCheck() 
    at System.Data.SqlClient.SqlTransaction.Rollback() 
    at System.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode)

下面是代碼的樣品片（數據庫自動生成的主鍵）

TableName row = new TableName(); 
row.Description = "something"; 
row.Action = "action"; 
Context.TableName.InsertOnSubmit(row); 
Context.SubmitChanges();

我們使用SQL Server 2008 R2。插入和更新確實通過服務器。但我們仍然得到例外。沒有什麼應該阻止這些更新和插入的發生。沒有依賴或其他東西。

我們如何阻止這些異常/殭屍檢查/回滾事件的發生，或者是什麼導致他們擺在首位？

編輯：

經過進一步檢驗，即正由的SubmitChanges完成的數據庫更新（）實際發生。事務成功完成後，將調用此異常，並將數據庫行更新爲新值。

來源

2013-03-11 David

這是否只發生在特定的代碼塊中？如果是這樣的話，它是否在任何一點的「使用」塊內？ – 2013-03-12 02:23:23

我們所有的數據庫更新函數都調用一個通用函數來執行DataContext SubmitChanges（）。所以它始終是失敗的同一行代碼。 – David 2013-03-12 15:01:05

有一點要注意的是，LinqToSql（和的EntityFramework）將默認分配在數據對象null到DateTime領域，所以如果你的表中有一個datetime場將扔在插入一個異常，如果DataContext的嘗試插入該空值。

您可以通過使用在MSSQL中datetime2類型（這將允許DateTime對象的「空」值 - 01/01/0001）解決這個錯誤，或者手動分配的有效日期數據對象的DateTime場（S）之前插入/更新。

沒有更詳細的堆棧跟蹤，這是想到的唯一明顯的問題。 HTH。

編輯：

看起來這是不完全少見：http://connect.microsoft.com/VisualStudio/feedback/details/588676/system-data-linq-datacontext-submitchanges-causes-invalidoperationexception-during-rollback#details

問題的根源似乎是，該LinqToSql使用內部ADO邏輯是不是真的正確配置來處理事務回滾。據我所知，唯一真正的解決方案是爲LinqToSql提供一個事務對象並管理自己的回滾，這看起來並沒有那麼吸引人。

來源

2013-03-11 19:12:54

不，所有字段都已填寫。發生這種情況的時間爲0.06％。簡單更新等同於更新表集field1 ='text'，其中primaryKey = 123。堆棧跟蹤的唯一其他部分是我的用戶函數，它調用DataContext的SubmitChanges（）函數。 – David 2013-03-11 20:02:09

Linq DataContext SubmitChanges從ZombieCheck發出InvalidOperationException

回答

相關問題