2011-01-12 2 views
31

Ich versuche, einen Fehler sehr ähnlich dem hier beschriebenen zu lösen:Welchen Einfluss haben die verschiedenen EF 4 SaveOptions auf den ObjectContext?

InvalidOperationException when calling SaveChanges in .NET Entity framework

Es scheint, dass die Lösung (die ich noch nicht versucht haben, zugegebenermaßen) ist System.Data.Objects passieren .SaveOptions.None als SaveOptions-Parameter für die SaveChanges() -Methode.

Also bevor ich das tue, versuche ich genau zu verstehen, wie die verschiedenen SaveOptions funktionieren (None, AcceptAllChangesAfterSave, DetectAllChanges). Ich konnte jedoch weder eine klare Erklärung dafür finden, noch bin ich mir sicher, was der Standard ist. Kann jemand klären?

Danke!

UPDATE: ich das eigentliche Problem Frage hier gepostet haben: System.InvalidOperationException when trying to iteratively add objects using EF 4

Antwort

17

Gute Frage (+1).

Auf den Punkt gebracht (von dem, was ich verstehe):

SaveOptions.DetectChangesBeforeSave: Dies ist die Standardeinstellung. Wenn Sie ObjectContext.SaveChanges() tun, wird die Methode DetectChanges() aufgerufen, um Entitäten im OSM zu synchronisieren.

SaveOptions.AcceptAllChangesAfterSave: Wenn Sie ObjectContext.SaveChanges() tun, das Verfahren AcceptAllChanges() heißt -, die die Eingeweide des OSM ist, wo die Einheiten in der Grafik wiederholt werden, Adressen und auf Unverändert/Frei stehend.

SaveOptions.None: Wenn Sie ObjectContext.SaveChanges() tun, werden Änderungen sofort gespeichert - keine Synchronisation überhaupt. Was auch immer in der Grafik zu sehen ist, wird gespeichert.

Meiner Erfahrung nach habe ich das nicht durcheinander gebracht - ich habe es als Standard (DetectChangesBeforeSave) belassen.

Manchmal mit POCO's Ich habe gehört, dass Sie explizit DetectChanges anrufen müssen, aber ich habe noch nie eine Empfehlung/Lösung gesehen, die SaveOptions auf keine zu ändern.

Sind Sie sicher, dass die Lösung in dieser Frage darin besteht, SaveOptions auf None zu setzen? Vielleicht sollten Sie Details angeben (oder eine separate Frage stellen), was den Fehler betrifft, den Sie erhalten, da sich eine solche Änderung auf Ihre gesamte Persistenzschicht auswirkt.

+0

Dank - genau mein Grund, die Frage zu stellen, da es meine gesamte Bewerbung betrifft, nur um dieses eine Problem zu beheben. Ich zögere das mit einer Lösung, die ich nicht ganz verstehe. Worauf beziehen Sie sich, wenn Sie OSM sagen? Bearbeiten: ObjectStateManager. Ich habs. :) – morganpdx

+0

Und ja, ich sollte eine Frage stellen, da dies die einzige Lösung ist, die in dem anderen Problem angegeben ist, das behauptet zu arbeiten, das würde in meinem Fall gelten. Aber es scheint genau das gleiche Problem zu sein. – morganpdx

+0

@morganpdx - wie haben Sie EF-Setup? Verwenden Sie die Standardcodegenerierung oder verwenden Sie POCOs? Und wenn ja - verwenden Sie Änderungsverfolgung (z. B. Self-Tracking-Entitäten, Proxy-Objekte usw.). Stellen Sie eine Frage mit dieser Information und dem Fehler/Szenario/Problem, das Sie haben. – RPM1984

18

Kurzkorrektur für

SaveOptions.DetectChangesBeforeSave: Dies ist die Standardeinstellung. Wenn Sie ObjectContext.SaveChanges() ausführen, wird die Methode DetectChanges() zu synchronisierten Anhängentitäten in dem OSM zu aufgerufen.

Savechanges ist eine überladene Version von SaveChanges(SaveOptions optsions) Verfahren, in denen diese parameterlos Version dieses

SaveChanges(SaveOptions.DetectChangesBeforeSave | SaveOptions.AcceptAllChangesAfterSave) 

Saveoptions ruft eine ENUM-Flagge und abschließend ist SaveOptions.DetectChangesBeforeSave | SaveOptions.AcceptAllChangesAfterSave die Standardeinstellung von SaveChanges() nicht die DetectChangesBeforeSave

Verwandte Themen