我也遇到了同样的问题，但我知道它在其他情况下也能正常工作，所以我把问题简化为:

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并获得附加实体 您用分离的子集合替换它的子集合 您保存更改，但在此操作期间，所有的子元素都被认为是添加的，因为EF直到此时才知道它们。因此EF尝试将null设置为旧子节点的外键，并插入所有新的子节点=>重复行。

解决方法取决于你想做什么以及你想怎么做?

如果您正在使用ASP。NET MVC你可以尝试使用UpdateModel或TryUpdateModel。

如果你只是想手动更新现有的子程序，你可以简单地这样做:

foreach (var child in modifiedParent.ChildItems)
{
    context.Childs.Attach(child); 
    context.Entry(child).State = EntityState.Modified;
}

context.SaveChanges();

附加实际上是不需要的(将状态设置为Modified也将附加实体)，但我喜欢它，因为它使过程更加明显。

如果你想修改现有的，删除现有的和插入新的子元素，你必须这样做:

var parent = context.Parents.GetById(1); // Make sure that childs are loaded as well
foreach(var child in modifiedParent.ChildItems)
{
    var attachedChild = FindChild(parent, child.Id);
    if (attachedChild != null)
    {
        // Existing child - apply new values
        context.Entry(attachedChild).CurrentValues.SetValues(child);
    }
    else
    {
        // New child
        // Don't insert original object. It will attach whole detached graph
        parent.ChildItems.Add(child.Clone());
    }
}

// Now you must delete all entities present in parent.ChildItems but missing
// in modifiedParent.ChildItems
// ToList should make copy of the collection because we can't modify collection
// iterated by foreach
foreach(var child in parent.ChildItems.ToList())
{
    var detachedChild = FindChild(modifiedParent, child.Id);
    if (detachedChild == null)
    {
        parent.ChildItems.Remove(child);
        context.Childs.Remove(child); 
    }
}

context.SaveChanges();

我也遇到了同样的问题，但我知道它在其他情况下也能正常工作，所以我把问题简化为:

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设置为其他/特殊的对象)，或者-就像最初的问题一样-我们期望项一旦从父对象中删除就会删除。

当我要删除我的记录时，我也遇到了同样的问题，因为这个问题的解决方案是，当你要删除你的记录时，你在删除头/主记录之前丢失了一些东西，你必须写代码在头/主记录之前删除它的细节，我希望你的问题会得到解决。

我在几个小时前遇到过这个问题，并尝试了所有方法，但在我的情况下，解决方案与上面列出的不同。

如果你使用已经从数据库检索实体，并试图修改它的孩子的错误将发生，但如果你从数据库获得实体的新副本，不应该有任何问题。 不要用这个:

 public void CheckUsersCount(CompanyProduct companyProduct) 
 {
     companyProduct.Name = "Test";
 }

用这个:

 public void CheckUsersCount(Guid companyProductId)
 {
      CompanyProduct companyProduct = CompanyProductManager.Get(companyProductId);
      companyProduct.Name = "Test";
 }

您之所以会遇到这种情况，是因为组合和聚合之间存在差异。

在复合中，创建父对象时创建子对象，销毁父对象时销毁子对象。所以它的生命周期是由父节点控制的。例:一篇博客文章及其评论。如果一个帖子被删除，它的评论也应该被删除。对一篇不存在的文章发表评论是没有意义的。订单和订单项目也是如此。

在聚合中，子对象可以不考虑父对象而存在。如果父对象被销毁，子对象仍然可以存在，因为以后它可能被添加到不同的父对象。例如:播放列表和该播放列表中的歌曲之间的关系。如果播放列表被删除，歌曲不应该被删除。它们可能被添加到不同的播放列表中。

实体框架区分聚合和组合关系的方式如下:

对于复合:它期望子对象有一个复合主键(ParentID, ChildID)。这是通过设计来实现的，因为孩子的id应该在他们父母的范围内。 对于聚合:它期望子对象中的外键属性为空。

So, the reason you're having this issue is because of how you've set your primary key in your child table. It should be composite, but it's not. So, Entity Framework sees this association as aggregation, which means, when you remove or clear the child objects, it's not going to delete the child records. It'll simply remove the association and sets the corresponding foreign key column to NULL (so those child records can later be associated with a different parent). Since your column does not allow NULL, you get the exception you mentioned.

解决方案:

1-如果你有强烈的理由不想使用复合键，你需要显式地删除子对象。这可以比之前建议的解决方案更简单:

context.Children.RemoveRange(parent.Children);

2-否则，通过在你的子表上设置正确的主键，你的代码看起来会更有意义:

parent.Children.Clear();