Une erreur s’est produite lors de l’enregistrement des entités qui n’exposent pas les propriétés de clé étrangère pour leurs relations.

Pour ceux d’entre vous qui auraient encore cette erreur avec toutes les clés correctement définies, jetez un oeil sur vos entités et assurez-vous de ne pas laisser de champ datetime avec une valeur nulle.

Ce message d’erreur peut être lancé pour n’importe quelle raison. La propriété ‘InnerException’ (ou son InnerException ou son InnerException, etc.) contient la cause principale du problème.

Il serait bien sûr utile de savoir où le problème est survenu – quel (s) object (s) de l’unité de travail pose le problème? Le message d’exception devrait normalement vous indiquer la propriété ‘EntityEnsortinges’, mais dans ce cas, pour une raison quelconque, cela est impossible. Cette complication diagnostique – de la propriété ‘EntityEnsortinges’ étant vide – est apparemment due au fait que certaines entités n’exposent pas de propriétés de clé étrangère pour leurs relations. ‘

Même si l’OP obtient l’erreur parce qu’il n’a pas DateTime initialiser DateTime s pour la deuxième instance de l’ User , il obtient la complication de diagnostic – ‘EntityEnsortinges’ étant vide et un message de premier niveau déroutant … t ‘exposer les propriétés de la clé étrangère’. Pour résoudre ce problème, Avatar devrait avoir un public virtual ICollection Users { get; set; } public virtual ICollection Users { get; set; } public virtual ICollection Users { get; set; } propriété définie.

Le problème a été résolu en ajoutant une propriété FK.

Dans mon cas, la situation suivante me donnait la même exception:

Imaginez un code premier modèle EF où vous avez une entité Garage qui possède une collection d’entités Car . J’avais besoin de retirer une voiture du garage alors j’ai fini avec le code qui ressemblait à ceci:

 garageEntity.Cars.Remove(carEntity); 

Au lieu de cela, il aurait dû ressembler à ceci:

 context.Cars.Remove(carEntity); 

Juste pour ceux qui pourraient avoir des problèmes similaires. J’ai eu la même erreur, mais pour une raison différente. Dans l’un des objects enfants, j’ai défini la [clé] comme étant une valeur identique pour différentes sauvegardes. Une erreur stupide de ma part, mais le message d’erreur ne vous conduit pas instantanément au problème.

Dans mon cas, l’exception a été lancée car EF avait créé une migration incorrecte. Il a manqué de définir l’ identité: true sur la deuxième table. Allez donc dans les migrations qui ont créé les tables pertinentes et vérifiez si elles ont manqué d’append une identité.

 CreateTable( "dbo.LogEmailAddressStats", c => new { Id = c.Int(nullable: false, identity: true), EmailAddress = c.Ssortingng(), }) .PrimaryKey(t => t.Id); CreateTable( "dbo.LogEmailAddressStatsFails", c => new { Id = c.Int(nullable: false), // EF missed to set identity: true!! Timestamp = c.DateTime(nullable: false), }) .PrimaryKey(t => t.Id) .ForeignKey("dbo.LogEmailAddressStats", t => t.Id) .Index(t => t.Id); 

Une colonne Id doit avoir une identité (c’est-à-dire une auto-incrémentation!). Il doit donc s’agir d’un bug EF.

Vous pouvez append une identité manuellement avec SQL directement dans la firebase database, mais je préfère utiliser Entity Framework.

Si vous rencontrez le même problème, je vois deux solutions simples :

Alt 1

inverser la migration créée de manière incorrecte avec

 update-database -target:{insert the name of the previous migration} 

Ajoutez ensuite l’ identité: true manuellement au code de migration, puis mettez à jour la firebase database à nouveau.

Alt 2

vous créez une nouvelle migration qui ajoute une identité. Si vous n’avez aucun changement dans les modèles et que vous courez

 add-migration identity_fix 

cela créera une migration vide. Ajoutez simplement ceci

  public partial class identity_fix : DbMigration { public override void Up() { AlterColumn("dbo.LogEmailAddressStatsFails", "Id", c => c.Int(nullable: false, identity: true)); } public override void Down() { AlterColumn("dbo.LogEmailAddressStatsFails", "Id", c => c.Int(nullable: false)); } } 

Ce problème peut également provenir de déclarations de clé inversées. Si vous utilisez couramment pour configurer la relation, assurez-vous que les touches gauche et droite sont associées à l’entité correcte.

Une autre réponse:

J’ai utilisé ceci:

 public List EdiSegments { get; set; } 

au lieu de cela:

 public virtual ICollection EdiSegments { get; set; } 

et obtenu le message d’erreur noté ci-dessus.

J’ai eu la même erreur et dans mon cas, le problème était que j’ai ajouté un object relationnel qui avait déjà été chargé “AsNoTracking”. J’ai dû recharger la propriété de relation.

BTW, certains suggèrent d’utiliser “Attach” pour les relations qui existent déjà dans db, je n’ai pas essayé cette option cependant.

J’ai le même problème. dans mon cas, cela était dû au champ datetime avec une valeur nulle. Je devais passer une valeur à datetime et tout s’est bien passé

Dans mon cas, le problème était que je ne renommais pas correctement une colonne, de sorte que la migration faisait deux colonnes, l’une appelée “TeamId” et l’autre appelée “TeamID”. C # cares, SQL pas.

Encore un autre cas différent ici. Une requête a été lancée dans une liste et, ce faisant, elle a créé des entités par leur constructeur à des fins de comparaison dans l’expression linq juste après la liste de contrôle (). Cela a créé des entités qui ont atteint l’état supprimé après que l’expression linq ait été terminée.
Toutefois! Un petit ajustement a créé une autre entité dans le constructeur, afin que cette nouvelle entité soit liée à une entité marquée comme Supprimée.

Quelques codes pour illustrer:

 query.Except(_context.MyEntitySetSet() .Include(b => b.SomeEntity) .Where(p => Condition) .ToList() // This right here calls the constructor for the remaining entities after the where .Where(p => p.Collection.First(b => Condition).Value == 0) .ToList(); 

Le constructeur de MyEntity:

 public partial class MyEntity { protected MyEntity() { // This makes the entities connected though, this instance of MyEntity will be deleted afterwards, the instance of MyEntityResult will not. MyEntityResult = new MyEntityResult(this); } } 

Ma solution était de m’assurer que toute l’expression était faite à l’intérieur de l’IQueryable afin qu’aucun object ne soit créé.

Je ne suis pas tout à fait sûr que cela aide dans votre cas, car je configure mes tables à l’aide de l’API Fluent, mais pour autant que je sache, le problème se pose que le schéma soit configuré à l’aide d’annotations de données (atsortingbuts) ou API Fluent (configuration).

Il semble y avoir un bogue dans EF (v. 6.1.3) car il omet certaines modifications du schéma lors de la mise à jour de la firebase database vers la prochaine migration. Le moyen le plus rapide pour le contourner (lors de la phase de développement) consiste à supprimer à nouveau toutes les tables des migrations DB et runt de l’étape init.

Si vous êtes déjà en production, la solution la plus rapide que j’ai trouvée consistait à modifier manuellement le schéma dans la firebase database ou, si vous souhaitez contrôler les versions des modifications, manipulez manuellement les méthodes Up () et Down () . migration.

Aujourd’hui, j’ai été confronté à ce problème et essayé les solutions possibles affichées ci-dessus, mais aucun d’entre eux ne m’a aidé. UnitOfWork pattern a été implémenté et le système a UnitOfWork les données en dernier après avoir ajouté tous les enregistrements.

Dans mon cas, le système combinait les deux modèles et interrogeait la firebase database

Nom d’object non valide ‘dbo.RoleModelUserModel’.

où il y avait deux modèles différents en réalité.

J’ai corrigé cela en réorganisant les instructions d’insertion et en ajoutant d’abord l’entité parent. Dans ce cas, l’utilisateur ajouté en premier et le problème résolu.