Parallelitätsverletzung nach Delete

verwendetes Datenbanksystem: MySQL

Hallo,

ich bekomme des öfteren eine Parallelitätsverletzung wenn ich eine Zeile per Delete lösche und dann per TableAdapterManager ein Update durchführe.

Zu dem Thema habe ich viele Threads gefunden, allerdings beziehen sich diese meist darauf, dass die Primärschlüssel nicht aktualisiert sind im Dataset oder dergleichen.
Der Primärschlüssel wird von mir selbst als GUID vergeben.
Wenn ich eine Zeile erstelle, diese meinem Dataset hinzufüge und dann durch den TableAdapterManager in die Datenbank schrieben lasse ist alles ok. Danach rufe ich Dataset.AcceptChanges auf. Wenn ich dann allerdings die Zeile per Delete() lösche und dann wieder das Update aufrufe bekomme ich die Parallelitätsverletzung.
Wenn ich zwischen dem Einfügen und Löschen das Programm neu starte und das Dataset neu fülle klappt es. Also es sieht genau wie das Problem mit den Primärschlüsseln aus aber die erstelle ich ja selbst und ändere sie auch nicht.
Die betroffene Zeile hat beinhaltet Fremdschlüssel, allerdings bleiben die referenzierten Zeilen alle erhalten und sind auch schon in der Datenbank.

Ich hoffe jemand weiß da einen Rat was ich überprüfen kann.

Gruß
-Hades-

Es wird nicht durch Schlüssel hervorgerufen, sondern die ParallelitätsExeption kommt immer, wenn die (vermeintlich) gelesenen Daten nicht mit denen in der DB übereinstimmen.

Aber die wird ja durch das Sql erzeugt die der ( unsägliche ) TableAdapter erzeugt.
Da kannst du auch genau sehen was da schief läuft.

Hey FZelle,

warum unsäglich? Sollte ich anstatt des TableAdapterManager etwas anderes benutzen?
Wie kann ich denn da sehen was da schief läuft?

Also außer einem Primary Key mit AutoIncrement kann doch eigentlich nichts die Daten der Zeile ändern oder? Ich schreibe ja alle Daten selbst in die Zeile und da gibts auch keinen anderen Benutzer der auf die Datenbank zugreift.

Es sei denn, dass MySQL die Daten der Zeile eigenständig beim Einfügen verändert, das wäre dann natürlich das dümmste was passieren kann, dann würde ich um ein erneutes Fill ja gar nicht herum kommen, das kanns ja nicht sein.

Hallo,

ich erinnere mich dunkel dass früher Mysql automatisch Datums- oder Zeitstempelspalten automatisch gesetzt hat wenn diese leer waren. Prüf das mal ob das bei Dir vorkommt. Der Treiber könnte dann wirklich glauben dass jemand anders die Daten zwischenzeitlich manipuliert hat und verweigert das Update (Optimistisches Sperrkonzept). Du kannst mal per Wireshark schauen welches SQL gesendet wird und was die Antwort vom DBServer ist.

Also ich habe eine Spalte mit Zeitstempeln, allerdings gibt es keine Zeile mit leerem Zeitstempel...
Kann es vielleicht an der Formatierung des DateTime liegen?
Andere Spalten sind Booleans und z.B. ein Byte-Array als Blob, welches auch nicht leer ist.
Einzig einige Boolean-Spalten werden nicht von mir gesetzt und sind demnach dann DBNull.

Hi,

hast Du in der Tabelle irgendwo einen Default Wert definiert? Diese werden dann anstelle von NULL verwendet. Wenn nein würde ich mal nach Besonderheiten bei der BLOB-Verabeitung suchen. So kann Oracle z.B. zwei BLOBs nicht ohne weiteres Vergleichen.

Gruß
f_igy

Kannst Du nicht einfach den Where des DeleteCommand auf den PK reduzieren ? Dann entfällt der Wertvergleich.

Hallo Programmierhans,

danke für die Idee. Kann ich den TableAdapter denn erweitern? Denn der eigentliche Code wird ja generiert, da ich ein typisiertes Dataset benutze. Diesen möchte ich nicht abändern, da sich im Laufe der Zeit immer mal wieder was an der Datenbank ändert.

Ich nehme die Blobs mal raus und teste es dann erneut.
Default-Werte habe ich nicht gesetzt.

Poste doch mal Deinen Code.
Im übrigen halte ich es mit Fzelle: Schreib die SQL-Kommandos selbst, dann weißt Du genau was passiert.