J'ai été coincé avec ce problème pendant plus d'une semaine maintenant. Espérons que quelqu'un peut me signaler dans la bonne direction.
Je commence par une brève description de mon schéma.
Asset 1 ---> 1 adresse * -> 1 zone * -> 1 Région * -> 1 Pays
Emballage 1 -> * Asset
Utilisation de l'entité de suivi automatique (STE) + WCF.
Étapes: >
à l'étape 2, l'appel utilise un chargement impatient d'adresses. Ceci est l'erreur lors de la tentative d'appel Acceptchanges ne peut pas continuer parce que
Les valeurs clés de l'objet sont en conflit avec
un autre objet dans le
ObjectStateManager. Assurez-vous que le
Les valeurs clés sont uniques avant d'appeler
AcceptChanges.
edit Après avoir serré, j'ai constaté que ceci est un problème de Ste. Le problème étant que vous ne pouvez pas persister un graphique contenant plusieurs instances de la même entité que décrites ICI . Voici ma question. Comment puis-je ajouter une entité à mon entité
collection. La nouvelle entité peut avoir
entités liées qui contiennent le même
clé comme une fois dans la collection.
C'est à dire. Ajouter un nouvel actif pouvant contenir
la même adresse, zone, région ou
entité de pays.
Voici mes contraintes: Je suis conscient des solutions possibles suggérées par Diego B Vega , mais ce ne sont pas des options que je peux utiliser pour ma solution. A quelqu'un d'autres idées?
5 Réponses :
Avez-vous envisagé d'abandonner ORM-S et de revenir à un accès normal, si vous savez ce que je veux dire: -)
Ne rigole pas - au moment où vous vous battez avec un seul problème comme celui-ci (qui sent le biais d'ORM plus que toute autre chose), vous auriez pu déployer vos propres fonctions 5-10 pour faire des appels SproC normaux et une conversion de type de données plus facile. Et puis vous êtes de retour pour être en plein contrôle et et non bloqué par des bibliothèques qui vont en prendre un autre comme 5 ans pour se stabiliser.
Surtout depuis que vous semblez avoir un schéma très propre - ce qui signifie des requêtes assez simples et des mises à jour simples.
J'aime vraiment la pensée de cela, mais malheureusement, je n'ai pas aussi de flexibilité que cela. Je vais en tenir compte dans les projets de projets futurs.
Je viens de démanteler un, comme il y a 2 mois il y a 2 mois, il s'agit de l'expérience personnelle :-) Needded Juste une classe simple pour créer / nettoyer les lecteurs et exciserez les lecteurs (c'est DigneReader 99% des temps de toute façon) et une classe statique à construire dans / out Params sur la mouche (6-8 types) et convertissez des résultats nullables (6-8 types à nouveau) avec des fonctions courtes (donc je peux taper moins :-) OH et une classe de modèle intelligente pour éliminer automatiquement le lecteur et la connexion. Quel relief - ne pas mentionner perf other :-)
Le problème est de gérer ces "5-10 fonctions" pour chaque caractéristique du site. Orm est plus que sauvegardé le temps à l'avance. Il ne faut pas avoir à changer de 5 endroits à chaque fois que vous ajoutez / changez une propriété
J'ai rencontré le même problème et j'ai finalement eu une solution. L'idée de base est d'empêcher certains types de classe de navigation de fixer à l'objetContext. Voici ce que j'ai fait:
Vide statique public CustomApplyclychandes (Ceci ObjectContext contexte, chaîne EntitysetName, entité de tendance, Type [] Exclusretypes ) Où la tendance: Iobjectwithchangetracker
- Ajoutez une condition à la boucle pour exclure tout type de classe contient dans le tableau ExclusclusTypes.
Poignée de la région Etat d'entité initiale
foreach (iobjectwithchangetracker changement de change dans EntityIndex.Allenties.Où (x => x.changetracker.state == Butstate.deletted && ! Exclusretypes.Contains (x.getType ()))) {Handlélétédentité (contexte, EntityIndex, Allrelationships, changé); }
foreach (iobjectwithchangetracker changement de change dans EntityIndex.Allenties.Où (x => x.changetracker.state! = ObjectState.Deletted
&& ! Exclusretypes.Contains (x.getType ()))) {Hardinentity (contexte, entitéindex, toutes les anniverses, la modification de la modification); } Endregion
- L'utilisation
Type [] ExclusclusTypes = {typeOf (actif), typeof (adresse), typeof (région)};
repev.entities.customapplychanges (entité, exclustypes); var chandentry = rep.context.ObjectStaTextOnergener.getObjectSTATERIES> (System.Data.entityState.Added | System.Data.entityState.Modified | System.Data.entityState.Detred); foreach (var e en changé) { Si (Exclusretypes.ca (C => C == E.entity.getType ()))) { rep.context.detach (E.entity); // détacher des objets inchangés } }
J'ai utilisé cette méthode avec un grand succès. Merci pour le partage.
J'ai une entité qui possède 2 associations à une autre entité et obtenez le message d'erreur dans le message d'origine. J'ai mis en œuvre cela. Il semble que ce code ne soit que détacher les types d'exclusion, de sorte qu'ils ne sont pas du tout sauvés. Je ne reçois pas l'erreur mais les associations (où les identifiants sont définis) ne sont pas enregistrés? Vous ne savez pas comment cela va fonctionner? Ai-je manqué quelque chose?
FYI, j'ai écrit un article de blog avec quelques suggestions supplémentaires à ce que j'avais déjà répondu dans les forums EF. ici est le message du blog.
C'est un blog très utile. Juste ce dont j'avais besoin. L'itérateur graphique vaut la peine d'être examiné.
Ce serait bien si EF ajoutait le nom des objets / clés d'incrimination des messages d'erreur longs. Pour que quelqu'un entretienne une application existante, un petit changement dans le code peut provoquer une création d'un nouveau graphique d'objet entier. Les messages d'erreur précis sont inestimables. Merci pour votre blog.
J'ai résolu cela en définissant la réinitialisation des identifiants de clé étrangère, qui nécessitait la définition de la valeur de navigation sur NULL, avant d'économiser.
... quelque chose comme ceci: p>
var countryToId = address.CountryToId; var countryFromId = address.CountryFromId; documentAddress.CountryTo = null; documentAddress.CountryFrom = null; documentAddress.CountryToId = countryToId; documentAddress.CountryFromId = countryFromId;
Je reçois cette erreur parce que je supprimais les enregistrements d'une entité, la réensemenant, puis remplissant l'entité avec de nouvelles données.
Comme auto-suivi a été activé sur cette entité, il n'a pas permis d'ajouter l'enregistrement avec le Même clé, même si un enregistrement avec cette clé avait été supprimé plus tôt. P>
Étant donné que je n'avais pas besoin de suivi de soi dans cette situation, je l'ai désactivé comme suit: P>
dbcontext.entity.MergeOption = System.Data.Objects.MergeOption.NoTracking;
Vous avez des clés en double, qui n'est pas autorisée. C'est tout ce que je peux dire sans avoir votre code.
Je pense que vous devez poster un exemple de code minimaliste où l'erreur se produit. Il est difficilement possible de dire quoi que ce soit plutôt que vous avez des touches en double sur les informations fournies dans votre message.