Entity Framework: "Store update, insert oder delete statement betraf eine unerwartete Anzahl von Zeilen (0)".

Question

Ich verwende Entity Framework, um ein Grid-Steuerelement aufzufüllen. Manchmal, wenn ich Updates mache, erhalte ich den folgenden Fehler:

Die Anweisung zum Aktualisieren, Einfügen oder Löschen eines Speichers betraf eine unerwartete Anzahl von Zeilen (0). Entitäten können seit dem Laden der Entitäten geändert oder gelöscht worden sein. Aktualisieren Sie die ObjectStateManager-Einträge.

Ich kann nicht herausfinden, wie man das reproduzieren kann. Aber es könnte etwas damit zu tun haben, wie dicht ich die Updates mache. Hat jemand dieses Problem gesehen oder weiß jemand, worauf sich die Fehlermeldung bezieht?

Edit: Leider bin ich nicht mehr in der Lage, das Problem, das ich hier hatte, zu reproduzieren, da ich mich von diesem Projekt zurückgezogen habe und mich nicht mehr daran erinnern kann, ob ich letztendlich eine Lösung gefunden habe, ob ein anderer Entwickler das Problem behoben hat, oder ob ich es umgangen habe. Daher kann ich keine Antworten akzeptieren.

Answer 1

Ich stieß auf dieses Problem, das dadurch verursacht wurde, dass das ID-Feld (Schlüssel) der Entität nicht festgelegt wurde. Als der Kontext also die Daten speichern wollte, konnte er keine ID = 0 finden. Stellen Sie sicher, dass Sie einen Haltepunkt in Ihre Aktualisierungsanweisung einfügen und überprüfen Sie, ob die ID der Entität festgelegt wurde.

Aus Paul Belloras Kommentar

Ich hatte genau dieses Problem, weil ich vergessen hatte, die versteckte ID anzugeben Eingabe in die .cshtml-Bearbeitungsseite aufzunehmen

Answer 2

Das ist ein Nebeneffekt einer Funktion namens optimistische Gleichzeitigkeit.

Nicht 100% sicher, wie man es ein-/ausschalten in Entity Framework, aber im Grunde, was es Ihnen sagt, ist, dass zwischen, wenn Sie die Daten aus der Datenbank gegriffen und wenn Sie Ihre Änderungen gespeichert jemand anderes die Daten geändert hat (was bedeutete, wenn Sie ging, um es zu speichern 0 Zeilen tatsächlich aktualisiert wurde). In SQL Begriffen, ihre update Abfrage where Klausel enthält den ursprünglichen Wert jedes Feldes in der Zeile, und wenn 0 Zeilen betroffen sind, weiß es, dass etwas schief gelaufen ist.

Die Idee dahinter ist, dass Sie keine Änderungen überschreiben, von denen Ihre Anwendung nicht weiß, dass sie stattgefunden haben - es ist im Grunde eine kleine Sicherheitsmaßnahme, die von .NET bei allen Aktualisierungen eingebaut wird.

Wenn es konsistent ist, stehen die Chancen gut, dass es innerhalb Ihrer eigenen Logik passiert (EG: Sie aktualisieren die Daten tatsächlich selbst in einer anderen Methode zwischen dem Select und dem Update), aber es könnte einfach eine Race Condition zwischen zwei Anwendungen sein.

Answer 3

Wow, viele Antworten, aber ich habe diesen Fehler bekommen, als ich etwas etwas anderes gemacht habe, das niemand sonst erwähnt hat.

Um es kurz zu machen: Wenn Sie ein neues Objekt erstellen und EF mitteilen, dass es mit der Option EntityState.Modified dann wird diese Fehlermeldung ausgegeben, da sie noch nicht in der Datenbank vorhanden ist. Hier ist mein Code:

MyObject foo = new MyObject()
{
    someAttribute = someValue
};

context.Entry(foo).State = EntityState.Modified;
context.SaveChanges();

Ja, das erscheint unsinnig, aber es ist entstanden, weil die betreffende Methode früher mit foo zu einem früheren Zeitpunkt erstellt wurde, hat sie jetzt nur noch someValue übergeben und erstellt foo selbst.

Einfache Lösung, einfach ändern EntityState.Modified a EntityState.Added oder ändern Sie die ganze Zeile in:

context.MyObject.Add(foo);

Answer 4

Ich war mit dem gleichen erschreckenden Fehler konfrontiert... :) Dann wurde mir klar, dass ich vergessen hatte, eine

@Html.HiddenFor(model => model.UserProfile.UserId)

für den Primärschlüssel des zu aktualisierenden Objekts! Ich neige dazu, diese einfache, aber sehr wichtige Sache zu vergessen!

Im Übrigen: HiddenFor ist für ASP.NET MVC.

Answer 5

Ich habe denselben Fehler, weil ein Teil der PK eine Datetime-Spalte war und der eingefügte Datensatz DateTime.Now als Wert für diese Spalte verwendet. Entity Framework würde den Wert mit Millisekundengenauigkeit einfügen und dann nach dem Wert suchen, den es gerade eingefügt hat, ebenfalls mit Millisekundengenauigkeit. SqlServer hatte den Wert jedoch auf Sekundengenauigkeit gerundet, so dass das Entity Framework nicht in der Lage war, den Wert mit Millisekundengenauigkeit zu finden.

Die Lösung bestand darin, die Millisekunden aus DateTime.Now vor dem Einfügen abzuschneiden.