【问题标题】:Linq DataContext SubmitChanges InvalidOperationException from ZombieCheck来自 ZombieCheck 的 Linq DataContext SubmitChanges InvalidOperationException
【发布时间】:2013-02-27 02:10:58
【问题描述】:

我在尝试使用 LinqToSql 添加行时收到InvalidOperationException。我们不能在内部复制它,而且只有我们的一个客户发生了大约 0.06%,总是对数据库进行相对简单的更改。 (单行插入,或单字段更新)

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() 完成的数据库更新实际上正在发生。事务成功完成后将调用此异常,并将数据库行更新为新值。

【问题讨论】:

  • 这是否只发生在特定的代码块上,如果是这样,它是否在任何时候都在 using 块内?
  • 我们所有的数据库更新函数都调用一个通用函数来执行 DataContext SubmitChanges()。所以总是同一行代码失败。

标签: c# linq sql-server-2008 datacontext


【解决方案1】:

需要注意的一点是,LinqToSql(和 EntityFramework)默认将 null 分配给数据对象中的 DateTime 字段,因此如果您的表有 datetime 字段,它将在插入时抛出异常如果数据上下文尝试插入该空值。

您可以通过在 MSSQL 中使用 datetime2 类型(这将允许 DateTime 对象的“null”值 - 01/01/0001)或手动将有效日期分配给数据对象的 @ 987654328@ 插入/更新之前的字段。

如果没有更详细的堆栈跟踪,这是唯一能想到的明显问题。 HTH。

编辑:

看起来这并不少见:http://connect.microsoft.com/VisualStudio/feedback/details/588676/system-data-linq-datacontext-submitchanges-causes-invalidoperationexception-during-rollback#details

根本问题似乎是 LinqToSql 使用的内部 ADO 逻辑没有真正正确配置以处理事务回滚。据我所知,唯一真正的解决方案是向 LinqToSql 提供一个事务对象并自己管理回滚,这似乎并没有那么吸引人。

【讨论】:

  • 不,所有字段都已填写。这种情况发生的概率为 0.06%。简单更新相当于更新表集 field1='text' where primaryKey=123。堆栈跟踪的唯一其他部分是调用 DataContext SubmitChanges() 函数的用户函数。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2012-01-20
  • 1970-01-01
  • 2012-03-07
  • 1970-01-01
  • 2021-09-04
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多