EF6中通过实体引用更新数据为何抛出异常？

我来帮你梳理下这段代码可能出问题的地方，毕竟用EF和DevExpress GridControl结合时，这类编辑异常挺常见的：

• SelectedItem未被EF上下文跟踪
  如果你给GridControl绑定的数据源是通过AsNoTracking()查询出来的（比如context.Instruments.AsNoTracking().ToList()），那选中的SelectedItem其实不在当前上下文的跟踪列表里。这时候context.Entry(SelectedItem)可能返回的实体状态是Detached，你强行设置State = EntityState.Modified的话，EF可能找不到对应的数据库记录，或者因为实体未被跟踪而抛出异常。
  解决办法：要么去掉AsNoTracking()让EF跟踪实体；如果必须用无跟踪查询，那你需要先把实体附加到上下文：

  var entry = context.Entry(SelectedItem);
  if (entry == null || entry.State == EntityState.Detached)
  {
      context.Instruments.Attach(SelectedItem);
      entry = context.Entry(SelectedItem);
  }
  // 然后再修改属性和设置状态
  

• 上下文实例不匹配
  假设GridControl的数据是从ContextA加载的，但你编辑时用的是一个新的ContextB实例。这时候SelectedItem属于ContextA，ContextB无法识别它，调用context.Entry(SelectedItem)会出现问题，SaveChanges时EF会因为实体不属于当前上下文而报错。
  解决办法：确保加载数据和编辑数据用的是同一个上下文实例，或者在新上下文里先附加实体再修改。

• 实体主键无效
  如果SelectedItem的主键字段（比如Id）是默认值（比如int类型的0，或者Guid的空值），EF无法确定要修改数据库中的哪条记录，设置State = Modified后执行SaveChanges()就会抛出异常。这种情况通常是因为选中的不是有效的数据库行，或者绑定的时候主键没有正确赋值。
  解决办法：检查SelectedItem的主键值是否正确，确保它和数据库中存在的记录主键一致。

• 并发冲突
  在你编辑这条记录的过程中，可能有其他用户或者后台进程修改了数据库里的这条数据。EF的乐观并发机制会检测到这种情况，抛出DbUpdateConcurrencyException。
  解决办法：可以捕获这个异常，然后处理冲突（比如提示用户刷新数据重新编辑，或者合并修改）。

• 数据验证失败
  你从addForm获取的字段值可能不符合数据库的约束（比如Name是必填项但为空，或者Units的长度超过数据库字段的限制），这时候SaveChanges()会抛出DbEntityValidationException或者SQL层面的异常。
  解决办法：在修改前先验证addForm的输入值，或者捕获验证异常查看具体的错误信息。

• 不必要的状态设置
  如果SelectedItem本来就在上下文的跟踪中（状态是Unchanged），其实你修改实体的属性后，EF会自动把实体标记为Modified，不需要手动设置entry.State = EntityState.Modified。手动设置可能不会直接报错，但有时候会和EF的自动跟踪逻辑冲突，尤其是当实体有导航属性的时候。
  解决办法：可以尝试去掉手动设置状态的代码，看看是否能正常保存。

内容的提问来源于stack exchange，提问作者DonBoitnott