Self-Tracking Entitäten - AcceptChanges kann nicht fortgesetzt werden, da das Objekt Schlüssel-Werte-Konflikt mit einem anderen Objekt in der ObjectStateManager

Ich Hänge schon länger mit diesem problem seit über einer Woche jetzt. Hoffentlich jemand kann mich in die richtige Richtung.

Beginne ich mit einer kurzen Beschreibung von meinem schema.

Anlage 1--->1 Adresse *-->1 *-->1 Region *-->1 Land

Paket 1-->* Asset

Nutzung von Self-Tracking-Einheit (STE) + WCF.

Schritte:

  1. Rufen Sie Daten speichern, die für eine Liste von Vermögenswerten.
  2. Rufen Sie Daten speichern, die für eine Liste von Paketen.
  3. Benutzer wählt ein Paket und weisen Vermögen.
  4. Sparen Paket.

In Schritt 2, wird der Aufruf verwendet, eager loading Adressen.

from p in context.Assets.Include("Address.Area.Region.Country")

Dies ist der Fehler, wenn Sie versuchen, um call

context.Packages.ApplyChanges(package)

AcceptChanges nicht weiter, weil
das Objekt ist Schlüssel-Werte-Konflikt mit
ein anderes Objekt in der
ObjectStateManager. Stellen Sie sicher, dass die
Schlüssel eindeutige Werte vor dem Aufruf
AcceptChanges.

BEARBEITEN

Nach Schnüffelei, ich fand, dass dies ein STE Frage. Das problem ist Sie kann nicht beibehalten werden ein Diagramm mit mehreren Instanzen der gleichen Entität-wie dargelegt hier. Hier ist meine Frage.

Wie kann ich eine Person zu meiner Person
Sammlung. Das neue Unternehmen kann
Verwandte Entitäten, die den gleichen
- Schlüssel wie bereits in der Sammlung.
I. e. Fügen Sie ein neues Objekt enthalten kann
die gleiche Adresse, das Gebiet, die region oder
Land Einheit.

Hier meine Einschränkungen:

  1. Ich muss die Navigations-Sammlung, weil es Auswirkungen auf die UI.
  2. Ich kann nicht pre-fetch alle Entitäten, die beteiligt sein werden, da die Datenmenge ist einfach zu groß.
  3. Ich muss in der Lage sein zu nehmen, snap-shots von der Entität jederzeit in Ordnung zu halten, eine Geschichte und es verwenden, um "rückgängig" alle änderungen.

Ich bin mir bewusst, mögliche Lösungen vorgeschlagen, von Diego B Vega, aber die sind nicht die Optionen, die ich verwenden kann für meine Lösung. Hat jemand irgendwelche anderen Ideen?

Sie haben doppelte Schlüssel, was nicht erlaubt ist. Das ist alles kann ich sagen ohne code.
Ich glaube, Sie brauchen, um die post-minimalistische code-Beispiel wo der Fehler Auftritt. Es ist kaum möglich, etwas zu sagen, anstatt Sie haben doppelte Schlüssel aus der info in deinem post.

InformationsquelleAutor Tri Q Tran | 2010-07-28

  1. 8

    FYI, ich schrieb einen blog-post mit ein paar zusätzliche Anregungen zu dem, was ich geantwortet hatten bereits in der EF-Foren. Hier ist der blog-post.

    Dies ist ein sehr nützliches blog. Genau das, was ich brauchte. Die Grafik iterator ist, lohnt ein Blick in.
    Es wäre schön, wenn EF möchte hinzufügen, den Namen der betreffenden Objekte/Schlüssel ist zu lang Fehlermeldungen. Für jemanden, der die Aufrechterhaltung einer bestehenden Anwendung, eine kleine änderung im code bewirken, dass versehentlich ein ganz neues Objekt-graph erstellt werden. Genaue Fehlermeldungen sind von unschätzbarem Wert. Vielen Dank für Ihren blog.

    InformationsquelleAutor divega

  2. 8

    Haben Sie sich überlegt, einfach aufzugeben auf ORM-s und gehen zurück zu normal zugreifen, wenn du weißt, was ich meine 🙂

    Nicht verarschen - von der Zeit Ringen Sie mit einer einzigen Frage, wie das eine (das riecht wie ORM Fehler mehr als alles andere), können Sie sich gerollt haben, Ihre eigenen 5-10 Funktionen zum normalen sproc Anrufe und einfacher Datentyp-Konvertierung und dann sind Sie wieder die volle Kontrolle, und nicht hängen von Bibliotheken, die gehen, um die anderen, wie 5yr zu stabilisieren.

    Zumal Sie scheinen sehr saubere schema - das bedeutet ganz einfach Abfragen und straight-forward updates.

    Ich mag den Gedanken, dass ich aber leider nicht ganz so viel Flexibilität wie das. Ich werde es in Erwägung, in Zukunft Projekt-designs.
    Ich habe gerade abgebaut, wie 2. mo Monat, so ist es aus der persönlichen Erfahrung 🙂 Noetigen nur eine einfache Klasse zu erstellen/cleanup-Verbindung und excecue Leser (es DataReader 99% der Zeit sowieso) und eine statische Klasse zu konstruieren, In/Out params on-the-fly (6-8 Arten) und wandelt null-Werte zulässt Ergebnisse (6-8 Arten wieder) mit kurzen Funktionen (so kann ich weniger Tippen 🙂 ach ja, und einer intelligenten template-Klasse auto-entsorgen-reader und Verbindung. Was für eine Erleichterung - nicht zu erwähnen, perf Schub 🙂
    das problem ist die Verwaltung dieser "5-10 Funktionen" für jedes feature der Website. ORM ist von mehr als Sparte Zeit vorne. es ist nicht mit einer änderung in 5 Orten jedes mal, wenn Sie hinzufügen/ändern einer Eigenschaft

    InformationsquelleAutor ZXX

  3. 3

    Ich hatte das gleiche Problem und endlich eine Lösung. Die grundlegende Idee ist, zu verhindern, dass bestimmte Navigations-Klasse Typ von Befestigung an der ObjectContext.
    Hier ist was ich getan habe:

    1. Verändert den Kontext.tt-Vorlage zu machen SelfTrackingEntitiesContextExtensions Klasse teilweise.
    2. Kopieren Sie die 2 ApplyChanges-Funktionen, um neu erstellte Benutzerdefinierte.Kontext.- Erweiterung.cs und benennen Sie Sie als CustomApplyChanges. Jeder wird ein zusätzlicher parameter als array vom Typ

    public static void
    CustomApplyChanges(diese
    ObjectContext context, string
    entitySetName, TEntity entity, Typ[]
    excludeTypes    ) where TEntity :
    IObjectWithChangeTracker

    1. Fügen Sie eine Bedingung der for-Schleife, um auszuschließen, jede Klasse Typ enthält, in den excludeTypes array.

    region Erste Entität Zustand

    foreach (IObjectWithChangeTracker
    changedEntity in
    entityIndex.AllEntities.Where(x =>
    x.ChangeTracker.State ==
    ObjectState.Deleted &&
    !excludeTypes.Enthält(x.GetType())))
    { HandleDeletedEntity(Kontext,
    entityIndex, allRelationships,
    changedEntity); }

    foreach (IObjectWithChangeTracker
    changedEntity in
    entityIndex.AllEntities.Where(x =>
    x.ChangeTracker.State !=
    ObjectState.Gelöscht &&
    !excludeTypes.Enthält(x.GetType())))
    { HandleEntity(Kontext, entityIndex,
    allRelationships, changedEntity); }

    endregion

    1. Die Nutzung

    Typ[] excludeTypes = { typeof(Asset), typeof(Adresse), typeof(Region)};

    rep.Personen.CustomApplyChanges(entity, excludeTypes);
    var changedEntry = rep.Kontext.ObjectStateManager.GetObjectStateEntries>(System.Daten.EntityState.Hinzugefügt | System.Daten.EntityState.Geändert | System.Daten.EntityState.Gelöscht);
    foreach (var e in changedEntry)
    {
    wenn (excludeTypes.Jeder(c => c == e.Entität.GetType()))
    {
    rep.Kontext.Detach(e.Entity); //trennen der Objekte unverändert
    }
    }

    Ich habe diese Methode mit großem Erfolg. Danke für das teilen.
    Ich habe eine Entität, die hat 2 Vereine auf eine andere Person und erhalten die Fehlermeldung im original-post. Ich habe diese umgesetzt. Es scheint, dass dieser code ist nur zum trennen des Exclude-Typen, so dass diese nicht gerettet werden, an alle. Ich habe nicht die Fehler, sondern die Verbände (Wo die Ids gesetzt sind), nicht gerettet werden? Nicht sicher, wie dies funktionieren wird? Habe ich etwas verpasst?

    InformationsquelleAutor drchip.PL

  4. 1

    Ich gelöst, indem das zurücksetzen der Foreign Key-Ids, die erforderliche Einstellung der Navigations-Wert auf null, bevor Sie Sie speichern.

    ...so etwas wie dieses:

    var countryToId = address.CountryToId;
var countryFromId = address.CountryFromId;
documentAddress.CountryTo = null;
documentAddress.CountryFrom = null;
documentAddress.CountryToId = countryToId;
documentAddress.CountryFromId = countryFromId;

    InformationsquelleAutor Mark Redman

  5. 0

    Ich wurde immer diese Fehlermeldung, denn ich war das löschen der Datensätze einer Entität, Nachsaat und dann nachfüllen der Entität mit neuen Daten.

    Als self-tracking aktiviert wurde, wird auf diese Entität, die es gar nicht zulassen, dass das hinzufügen der Datensatz mit dem gleichen Schlüssel, obwohl ein Datensatz mit diesem Schlüssel gelöscht worden war früher.

    Da ich nicht brauchen, self-tracking in dieser situation, ich habe ihn deaktiviert wie:

    dbcontext.entity.MergeOption = System.Data.Objects.MergeOption.NoTracking;

    InformationsquelleAutor gunnerz

Schreibe einen Kommentar