Laden...

Parallelitätsverletzung

Erstellt von Tamer vor 17 Jahren Letzter Beitrag vor 17 Jahren 1.617 Views
T
Tamer Themenstarter:in
13 Beiträge seit 2006
vor 17 Jahren
Parallelitätsverletzung

hallo,

ich hole die daten mit dataadapter per fill methode aus Sqlserver express edition,
bearbeite diese und per update schicke ich die Änderungen an die DB zurück. dannach rufe ich acceptchanges() methode von DataTabele auf
Beim ersten Mal Klapt es ohne probleme, in sql server console sehe ich die Änderungen.
Aber wenn ich den gleichen datensatz nochmal bearbeiten und an die DB schicken will, lösst die daAdabper.update() eine DBConcurrencyException aus.

was mache ich hier falsch?

P.s. Ausser mir arbeitet niemand mit der DB

476 Beiträge seit 2004
vor 17 Jahren

hallo Tamer,

wenn du das Update über den DataAdapter machst, solltest du bei dem DataTable nicht AcceptChanges aufrufen müssen, das sollte automatisch geschehen sein. Lässt du das Update-Command des DataAdapters über einen CommandBuilder generieren? Dieser nimmt per default jeden "OriginalValue"-Wert in der Where-Klausel auf um die zu per Update zu ändernden Datensätze identifiziert. Findet er diesen nicht, weil sich Werte geändert haben (z.B.: durch AcceptChanges...) wirt er eine DBConcurrenyException, weil er davon ausgeht, dass der Datensatz von anderer Stelle bereits verändert wurde.

-yellow

Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).

Mein Blog: Yellow's Blog auf sqlgut.de

M
104 Beiträge seit 2005
vor 17 Jahren

Hallo,

die DbConcurrencyException hat mich heute fast den ganzen Tag beschäftigt. Zzt. arbeite ich an einer Anwendung, die mit verschiedenen DB-Servern kommunizieren können muss (Firebird, Oracle und MS SQL).

Beim Firebird läuft alles ohne Probleme. Nur die beiden "großen" DB-Server kommen mir mit einer DbConcurrencyException daher, wenn ich einen Datensatz das zweite mal speichern wollte.

Nach mehreren Stunden Suchen, Probieren und Fluchen, habe ich die DBs bei Oracle und SQL Server neu aufgesetzt. Allerdings hatte ich zu spät gemerkt, dass ich dabei ein älteres Script verwendet habe. Die Anwendung habe ich dann trotzdem einmal gestartet - und oh Wunder - keine Parallelitätsverletzung mehr.....

Über dem intensiven Verglich des alten und des neue SQL-Scriptes ist mir aufgefallen, dass einige Spaltennamen im neueren einen "_" (Unterstrich) enthalten, im alten aber nicht. Also: Neues Script geändert, eingespielt......... und es geht........

Kann es sein, dass der DbCommandBuilder keine "Sonderzeichen" in der DB (und dem zugehörigen DataSet) verträgt? Vielleicht kann ja jemand dieses Verhalten erklären.

Gruß
Morpheus