我得到这个错误时，我GetById()在一个实体，然后设置子实体的集合到我的新列表，来自MVC视图。
操作失败 关系是无法改变的 因为一个或多个外键 Properties是非空的。当一个 关系发生了变化 相关外键属性设置为 空值。如果外键是 不支持空值，新建 关系必须被定义 必须分配外键属性 另一个非空值或 必须删除不相关的对象。
我不太理解这句话:
这种关系无法改变 因为一个或多个外键 Properties是非空的。
我为什么要改变两个实体之间的关系?它应该在整个应用程序的生命周期内保持不变。
发生异常的代码只是简单地将集合中修改过的子类分配给现有的父类。这将有望满足取消子类，增加新的和修改。我本以为实体框架处理这个。
代码行可以提炼为:
var thisParent = _repo.GetById(1);
thisParent.ChildItems = modifiedParent.ChildItems();
_repo.Save();
当前回答
我今天遇到了这个问题，想分享我的解决方案。在我的例子中，解决方案是在从数据库中获取Parent之前删除Child项。
以前我是这样做的代码如下。然后我将得到这个问题中列出的相同错误。
var Parent = GetParent(parentId);
var children = Parent.Children;
foreach (var c in children )
{
Context.Children.Remove(c);
}
Context.SaveChanges();
对我来说，有效的方法是先获取子项，使用parentId(外键)，然后删除这些项。然后我可以从数据库中获取父元素，在这一点上，它应该不再有任何子元素，我可以添加新的子元素。
var children = GetChildren(parentId);
foreach (var c in children )
{
Context.Children.Remove(c);
}
Context.SaveChanges();
var Parent = GetParent(parentId);
Parent.Children = //assign new entities/items here
其他回答
我也遇到了同样的问题，但我知道它在其他情况下也能正常工作，所以我把问题简化为:
parent.OtherRelatedItems.Clear(); //this worked OK on SaveChanges() - items were being deleted from DB
parent.ProblematicItems.Clear(); // this was causing the mentioned exception on SaveChanges()
OtherRelatedItems有一个复合主键(parentId +一些本地列)，工作正常 probleaticitems有自己的单列主键，而parentId只是一个FK。这导致了Clear()之后的异常。
我所要做的就是使ParentId成为复合PK的一部分，以表明没有父元素就不能存在子元素。我使用DB-first模型，添加PK并将parentId列标记为EntityKey(因此，我必须在DB和EF中更新它-不确定EF单独是否足够)。
仔细想想，这是一个非常优雅的区别，EF使用它来决定没有父对象的子对象是否“有意义”(在这种情况下，Clear()不会删除它们并抛出异常，除非你将ParentId设置为其他/特殊的对象)，或者-就像最初的问题一样-我们期望项一旦从父对象中删除就会删除。
我今天遇到了这个问题，想分享我的解决方案。在我的例子中，解决方案是在从数据库中获取Parent之前删除Child项。
以前我是这样做的代码如下。然后我将得到这个问题中列出的相同错误。
var Parent = GetParent(parentId);
var children = Parent.Children;
foreach (var c in children )
{
Context.Children.Remove(c);
}
Context.SaveChanges();
对我来说，有效的方法是先获取子项，使用parentId(外键)，然后删除这些项。然后我可以从数据库中获取父元素，在这一点上，它应该不再有任何子元素，我可以添加新的子元素。
var children = GetChildren(parentId);
foreach (var c in children )
{
Context.Children.Remove(c);
}
Context.SaveChanges();
var Parent = GetParent(parentId);
Parent.Children = //assign new entities/items here
我只是犯了同样的错误。 我有两个具有父子关系的表，但是我在子表的表定义中的外键列上配置了“on delete cascade”。 因此，当我手动删除父行(通过SQL)在数据库中，它将自动删除子行。
然而，这在EF中不起作用，出现了这个线程中描述的错误。 原因是，在我的实体数据模型(edmx文件)中，父表和子表之间的关联属性不正确。 End1的OnDelete选项被配置为none(“End1”在我的模型中是具有1的多重性的结束)。
我手动将End1 OnDelete选项改为Cascade，然后它就工作了。 我不知道为什么EF不能拾取这个，当我从数据库更新模型(我有一个数据库第一模型)。
为了完整起见，这是我删除代码的样子:
public void Delete(int id)
{
MyType myObject = _context.MyTypes.Find(id);
_context.MyTypes.Remove(myObject);
_context.SaveChanges();
}
如果我没有定义级联删除，我将不得不在删除父行之前手动删除子行。
我尝试过这些方法和其他方法，但没有一个很有效。由于这是谷歌上的第一个答案，我将在这里添加我的解。
对我来说很有效的方法是在提交期间将关系排除在外，这样EF就不会搞砸了。我通过在DBContext中重新找到父对象并删除它来做到这一点。因为重新找到的对象的导航属性都是空的，所以在提交过程中会忽略子对象的关系。
var toDelete = db.Parents.Find(parentObject.ID);
db.Parents.Remove(toDelete);
db.SaveChanges();
注意，这里假设外键设置为ON DELETE CASCADE，所以当父行被删除时，子行将被数据库清除。
我不知道为什么其他两个答案这么受欢迎!
我相信您认为ORM框架应该处理它是正确的——毕竟，这是它承诺交付的。否则，您的域模型就会被持久性问题所破坏。如果你正确地设置了级联设置，NHibernate就能很好地管理它。在实体框架中也有可能，他们只是希望你在建立数据库模型时遵循更好的标准，特别是当他们不得不推断应该做什么级联时:
您必须使用“识别关系”来正确地定义父-子关系。
如果你这样做，实体框架知道子对象是由父对象标识的，因此它必须是一个“级联删除孤儿”的情况。
除了上面的，你可能需要(从NHibernate的经验)
thisParent.ChildItems.Clear();
thisParent.ChildItems.AddRange(modifiedParent.ChildItems);
而不是完全替换列表。
更新
@Slauma的评论提醒我，分离实体是整体问题的另一部分。为了解决这个问题，您可以采用使用自定义模型绑定器的方法，通过尝试从上下文加载模型来构造模型。这篇博客文章展示了我的意思。
