Linq DataContext SubmitChanges InvalidOperationException of ZombieCheck

Question

I get an InvalidOperationException when I try to add a row using LinqToSql. We cannot duplicate it in the house, and this is approximately 0.06% for one of our customers, always with a relatively simple change to the database. (Insert one row or update one field)

 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) 

Here is a sample code (the database automatically generates a primary key)

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

We are using SQL Server 2008 R2. Insertions and updates are performed on the server. But we still get the exception. There is nothing to prevent these updates and insertions. No dependencies or other things.

How can we stop these exceptions / checks / rollbacks from zombies or that they cause them in the first place?

EDIT:

After additional verification, the database update performed by SubmitChanges () does indeed occur. This exception is thrown after the transaction is completed, and the database row is updated to the new value.

Answer 1

One thing to be aware of is that LinqToSql (and EntityFramework) will default to null to DateTime fields in your data objects, so if your table has a DateTime field, it will throw an exception on insert if the datacontext tries to insert this is a zero value.

You can work around this error either using the datetime2 type in MSSQL (which will allow the DateTime object to be “zero” - 01/01/0001 ), or manually assign a valid date for the DateTime data object before inserting / updating.

Without a more detailed stack trace, this is the only obvious problem that comes to mind. NTN.

EDIT:

It seems like this is not entirely unusual: http://connect.microsoft.com/VisualStudio/feedback/details/588676/system-data-linq-datacontext-submitchanges-causes-invalidoperationexception-during-rollback#details

The root problem is that the internal ADO logic used by LinqToSql is not actually configured properly to handle transaction rollbacks. From what I can tell, the only real solution is to provide the LinqToSql transaction object and manage the rollbacks myself, which doesn’t really seem attractive.