La relation n'a pas pu être modifiée parce qu'une ou plusieurs des propriétés de la clé étrangère ne sont pas nulles.

la raison pour laquelle vous faites face à cette est due à la différence entre composition et agrégation .

dans sa composition, l'objet enfant est créé lorsque le parent est créé et est détruit lorsque son parent est détruit . Donc sa durée de vie est contrôlée par sa mère. par exemple un billet de blog et ses commentaires. Si un message est supprimé, ses commentaires doivent être supprimés. Il n'est pas logique d'avoir commentaires à un poste qui n'existe pas. Idem pour les commandes et les articles de commande.

l'objet enfant peut exister indépendamment de son parent . Si le parent est détruit, l'objet enfant peut encore exister, comme il peut être ajouté à un autre parent plus tard. par exemple: la relation entre une playlist et les chansons de cette playlist. Si la playlist est supprimée, les chansons ne doivent pas être supprimées. Ils peuvent être ajoutés à une liste de lecture différente.

La façon dont l'Entité Cadre différencie d'agrégation et de composition des relations est comme suit:

• pour la composition: il s'attend à ce que l'objet enfant ait une clé primaire composite (ParentID, ChildID). Il s'agit là d'un choix délibéré, car l'identification des enfants devrait relever de la compétence de leurs parents.

• Pour l'agrégation: il attend la propriété de clé étrangère dans l'objet enfant à accepter les valeurs null.

donc, la raison pour laquelle vous avez ce problème est à cause de la façon dont vous avez placé votre clé primaire dans votre table enfant. Il devrait être composite, mais il ne l'est pas. Ainsi, le cadre D'entité voit cette association comme une agrégation, ce qui signifie que, lorsque vous supprimez ou effacez les objets enfant, il ne va pas supprimer les dossiers enfant. Il va simplement supprimer l'association et définit la colonne de clé étrangère correspondante à NULL (de sorte que ces dossiers d'enfant peuvent plus tard être associés avec un autre parent). Puisque votre colonne n'autorise pas NULL, vous obtenez l'exception que vous avez mentionnée.

Solutions:

1 - Si vous avez une bonne raison de ne pas vouloir utiliser une clé composite, vous devez supprimer les objets enfants explicitement. Et cela peut être fait plus simplement que les solutions suggérées plus haut:

context.Children.RemoveRange(parent.Children);

2-sinon, en plaçant la clé primaire appropriée sur votre table d'enfant, votre le code aura l'air plus significatif:

parent.Children.Clear();

C'est un très gros problème. Ce qui se passe réellement dans votre code est ceci:

• Vous chargez Parent à partir de la base de données et d'obtenir un joint entité
• vous remplacez sa collection d'enfants par une nouvelle collection d'enfants détachés
• vous économisez des modifications mais pendant cette opération tous les enfants sont considérés comme ajouté parce que EF ne savait pas à leur sujet jusqu'à ce moment. L'EF tente donc de définir null à clé étrangère des anciens enfants et insérez tous les nouveaux enfants => doublez les lignes.

Maintenant, la solution dépend vraiment de ce que vous voulez faire et comment voulez-vous faire?

si vous utilisez ASP.NET MVC vous pouvez essayer d'utiliser UpdateModel ou TryUpdateModel .

si vous voulez simplement mettre à jour les enfants existants manuellement, vous pouvez simplement faire quelque chose comme:

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

context.SaveChanges();

la connexion n'est pas réellement nécessaire (réglage de l'état de Modified sera également attacher de l'entité), mais je l'aime parce qu'il rend le processus plus évident.

si vous voulez modifier existant, supprimer existant et insérer de nouveaux enfants, vous devez faire quelque chose comme:

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();

j'ai trouvé cette" réponse 151930920 " beaucoup plus utile pour la même erreur. Il semble que EF n'aime pas quand vous retirez, il préfère Supprimer.

order.OrderDetails.ToList().ForEach(s => db.Entry(s).State = EntityState.Deleted);

Je ne sais pas pourquoi les deux autres réponses sont si populaires!

je crois que vous aviez raison de supposer que le cadre de L'ORM devrait s'en charger - après tout, c'est ce qu'il promet de fournir. Sinon, votre modèle de domaine est corrompu par la persistance. NHibernate gère cela avec plaisir si vous configurez correctement les paramètres de cascade. Dans le cadre D'Entity il est également possible, ils s'attendent juste à ce que vous suivez de meilleures normes lors de la mise en place de votre modèle de base de données, surtout quand ils doivent inférer ce que Cascade devrait être fait:

vous devez définir correctement la relation parent - enfant en utilisant relation d'identification ".

si vous faites cela, Entity Framework sait que l'objet enfant est identifié par le parent, et donc il doit s'agir d'une situation" cascade-delete-orphans".

à l'exclusion de ce qui précède, vous pourrait besoin d' (à partir de NHibernate expérience)

thisParent.ChildItems.Clear();
thisParent.ChildItems.AddRange(modifiedParent.ChildItems);

au lieu de remplacer entièrement la liste.

mise à JOUR

le commentaire de @Slauma m'a rappelé que les entités détachées sont une autre partie du problème global. Pour résoudre ce problème, vous pouvez utiliser un classeur de modèle personnalisé qui construit vos modèles en essayant de le charger à partir du contexte. Ce billet de blog montre un exemple de ce que je veux dire.

si vous utilisez AutoMapper avec Entity Framework sur la même classe, vous pourriez avoir ce problème. Par exemple, si votre classe est

class A
{
    public ClassB ClassB { get; set; }
    public int ClassBId { get; set; }
}

AutoMapper.Map<A, A>(input, destination);

cela va essayer de copier les deux propriétés. Dans ce cas, ClassBId est non nul. Puisque AutoMapper copiera destination.ClassB = input.ClassB; cela causera un problème.

définit votre AutoMapper pour ignorer la propriété ClassB .

 cfg.CreateMap<A, A>()
     .ForMember(m => m.ClassB, opt => opt.Ignore()); // We use the ClassBId

cela se produit parce que l'entité enfant est marquée comme modifiée au lieu d'être supprimée.

et la modification que EF fait à L'entité enfant lorsque parent.Remove(child) est exécuté, est simplement de mettre la référence à son parent à null .

vous pouvez vérifier L'EntityState de L'enfant en tapant le code suivant dans la fenêtre immédiate de Visual Studio lorsque l'exception se produit, après avoir exécuté SaveChanges() :

_context.ObjectStateManager.GetObjectStateEntries(System.Data.EntityState.Modified).ElementAt(X).Entity

où X doit être remplacé par L'entité supprimée.

si vous n'avez pas accès au ObjectContext pour exécuter _context.ChildEntity.Remove(child) , vous pouvez résoudre ce problème en faisant de la clé étrangère une partie de la clé primaire sur la table enfant.

Parent
 ________________
| PK    IdParent |
|       Name     |
|________________|

Child
 ________________
| PK    IdChild  |
| PK,FK IdParent |
|       Name     |
|________________|

de cette façon, si vous exécutez parent.Remove(child) , EF marquera correctement l'entité comme supprimée.

j'ai eu la même erreur. J'ai deux tables avec une relation parent-enfant, mais j'ai configuré un "ON delete cascade" sur la colonne clé étrangère dans la définition de la table enfant. Ainsi, lorsque je supprime manuellement la ligne parent (via SQL) dans la base de données, elle supprime automatiquement les lignes enfant.

cependant cela n'a pas fonctionné dans EF, l'erreur décrite dans ce thread s'est manifestée. La raison pour cela était, que dans mon modèle de données d'entité (fichier edmx) le les propriétés de l'association entre la table parent et l'enfant n'étaient pas correctes. L'option End1 OnDelete a été configurée pour être none ("End1" dans mon modèle est la fin qui a une multiplicité de 1).

j'ai changé manuellement l'option End1 OnDelete en Cascade et que cela a fonctionné. Je ne sais pas pourquoi EF n'est pas capable de le récupérer, quand je mets à jour le modèle à partir de la base de données (j'ai un premier modèle de base de données).

Pour être complet, c'est Comment mon code à supprimer ressemble à:

   public void Delete(int id)
    {
        MyType myObject = _context.MyTypes.Find(id);

        _context.MyTypes.Remove(myObject);
        _context.SaveChanges(); 
   }    

si je n'avais pas de suppression en cascade définie, je devrais supprimer les lignes enfant manuellement avant de supprimer la ligne parent.

j'ai rencontré ce problème aujourd'hui et je voulais partager ma solution. Dans mon cas, la solution était de supprimer les éléments enfant avant d'obtenir le Parent de la base de données.

Auparavant, je le faisais comme dans le code ci-dessous. Je vais alors obtenir la même erreur énumérée dans cette question.

var Parent = GetParent(parentId);
var children = Parent.Children;
foreach (var c in children )
{
     Context.Children.Remove(c);
}
Context.SaveChanges();

ce qui a fonctionné pour moi, c'est d'obtenir les articles pour enfants d'abord, en utilisant le parentId (clé étrangère) et puis supprimer ces articles. Alors je peux avoir le Parent à partir de la base de données et, à ce stade, il ne devrait pas avoir d'enfants, et je peux ajouter de nouveaux enfants.

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

vous devez vider manuellement la collection de ChildItems et y ajouter de nouveaux articles:

thisParent.ChildItems.Clear();
thisParent.ChildItems.AddRange(modifiedParent.ChildItems);

après cela, vous pouvez appeler la méthode D'extension DeleteOrphans qui traitera avec les entités orphelines (elle doit être appelée entre les méthodes DetectChanges et SaveChanges).

public static class DbContextExtensions
{
    private static readonly ConcurrentDictionary< EntityType, ReadOnlyDictionary< string, NavigationProperty>> s_navPropMappings = new ConcurrentDictionary< EntityType, ReadOnlyDictionary< string, NavigationProperty>>();

    public static void DeleteOrphans( this DbContext source )
    {
        var context = ((IObjectContextAdapter)source).ObjectContext;
        foreach (var entry in context.ObjectStateManager.GetObjectStateEntries(EntityState.Modified))
        {
            var entityType = entry.EntitySet.ElementType as EntityType;
            if (entityType == null)
                continue;

            var navPropMap = s_navPropMappings.GetOrAdd(entityType, CreateNavigationPropertyMap);
            var props = entry.GetModifiedProperties().ToArray();
            foreach (var prop in props)
            {
                NavigationProperty navProp;
                if (!navPropMap.TryGetValue(prop, out navProp))
                    continue;

                var related = entry.RelationshipManager.GetRelatedEnd(navProp.RelationshipType.FullName, navProp.ToEndMember.Name);
                var enumerator = related.GetEnumerator();
                if (enumerator.MoveNext() && enumerator.Current != null)
                    continue;

                entry.Delete();
                break;
            }
        }
    }

    private static ReadOnlyDictionary<string, NavigationProperty> CreateNavigationPropertyMap( EntityType type )
    {
        var result = type.NavigationProperties
            .Where(v => v.FromEndMember.RelationshipMultiplicity == RelationshipMultiplicity.Many)
            .Where(v => v.ToEndMember.RelationshipMultiplicity == RelationshipMultiplicity.One || (v.ToEndMember.RelationshipMultiplicity == RelationshipMultiplicity.ZeroOrOne && v.FromEndMember.GetEntityType() == v.ToEndMember.GetEntityType()))
            .Select(v => new { NavigationProperty = v, DependentProperties = v.GetDependentProperties().Take(2).ToArray() })
            .Where(v => v.DependentProperties.Length == 1)
            .ToDictionary(v => v.DependentProperties[0].Name, v => v.NavigationProperty);

        return new ReadOnlyDictionary<string, NavigationProperty>(result);
    }
}

j'ai essayé ces solutions et bien d'autres, mais aucune n'a vraiment fonctionné. Puisque c'est la première réponse sur google, je vais ajouter ma solution ici.

la méthode qui a bien fonctionné pour moi était de retirer les relations de l'image pendant les commits, donc il n'y avait pas de raison pour que EF foire. J'ai fait cela en retrouvant l'objet parent dans le DBContext, et en supprimant cela. Comme les propriétés de navigation de l'objet retrouvé sont toutes nulles, les relations sont ignorés lors de la validation.

var toDelete = db.Parents.Find(parentObject.ID);
db.Parents.Remove(toDelete);
db.SaveChanges();

notez que cela suppose que les clés étrangères sont configurées avec ON DELETE CASCADE, donc quand la ligne parent est retirée, les enfants seront nettoyés par la base de données.

ce type de solution a fait l'affaire pour moi:

Parent original = db.Parent.SingleOrDefault<Parent>(t => t.ID == updated.ID);
db.Childs.RemoveRange(original.Childs);
updated.Childs.ToList().ForEach(c => original.Childs.Add(c));
db.Entry<Parent>(original).CurrentValues.SetValues(updated);

il est important de dire que cela supprime tous les enregistrements et les insérer à nouveau. Mais pour mon cas (moins de 10) c'est ok.

j'espère que ça aidera.

j'ai rencontré ce problème avant plusieurs heures et essayer tout, mais dans mon cas la solution était différente de la liste ci-dessus.

si vous utilisez déjà entité récupérée à partir de la base de données et essayer de modifier ses enfants l'erreur se produira, mais si vous obtenez une nouvelle copie de l'entité à partir de la base de données, il ne devrait pas y avoir de problèmes. N'utilisez pas ce:

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

utilisez ceci:

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

cette question se pose parce que nous essayons de supprimer la table parent les données de la table enfant immobile sont présentes. Nous résolvons le problème avec l'aide de cascade supprimer.

dans le modèle Créer la méthode dans la classe dbcontext.

 modelBuilder.Entity<Job>()
                .HasMany<JobSportsMapping>(C => C.JobSportsMappings)
                .WithRequired(C => C.Job)
                .HasForeignKey(C => C.JobId).WillCascadeOnDelete(true);
            modelBuilder.Entity<Sport>()
                .HasMany<JobSportsMapping>(C => C.JobSportsMappings)
                  .WithRequired(C => C.Sport)
                  .HasForeignKey(C => C.SportId).WillCascadeOnDelete(true);

après cela, dans notre appel API

var JobList = Context.Job                       
          .Include(x => x.JobSportsMappings)                                     .ToList();
Context.Job.RemoveRange(JobList);
Context.SaveChanges();

Cascade supprimer option Supprimer la table enfant parent ainsi parent avec ce code simple. Rendre essayez-le dans cette manière simple.

supprimer la plage utilisée pour supprimer la liste des enregistrements dans la base de données Merci

j'ai utilisé Mosh's solution , mais il n'était pas évident pour moi comment mettre en œuvre correctement la clé de composition dans le code d'abord.

voici donc la solution:

public class Holiday
{
    [Key, Column(Order = 0), DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int HolidayId { get; set; }
    [Key, Column(Order = 1), ForeignKey("Location")]
    public LocationEnum LocationId { get; set; }

    public virtual Location Location { get; set; }

    public DateTime Date { get; set; }
    public string Name { get; set; }
}

j'ai également résolu mon problème avec réponse de Mosh et je pensais réponse de PeterB était un peu de car il a utilisé un enum comme clé étrangère. Rappelez-vous que vous devrez ajouter une nouvelle migration après avoir ajouté ce code.

je peux également recommander cet article de blog pour d'autres solutions:

http://www.kianryan.co.uk/2013/03/orphaned-child /

Code:

public class Child
{
    [Key, Column(Order = 0), DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int Id { get; set; }

    public string Heading { get; set; }
    //Add other properties here.

    [Key, Column(Order = 1)]
    public int ParentId { get; set; }

    public virtual Parent Parent { get; set; }
}