UpdateBatch und Unique Index

[Peinhard]

Folgendes Szenario: ich lade im Modus ltBatchOptimistic eine Tabelle mit Positionen, die anhand einer PosNr, auf der ein Unique Index liegt, sortiert werden. Sortiere ich diese Positionen jetzt um - vertausche also bspw zwei PosNr - und rufe dann UpdateBatch auf, setzt es natürlich schon beim ersten Update-Statement eine Schlüsselverletzung (weil zB PosNr 4 zu PosNr 3 geändert werden soll, während die ursprüngliche PosNr 3 noch unverändert in der DB steht).

Wie geht ihr mit diesem Problem um?

[mkinzler]

Erst die eine ans Ende Schieben (unbelegte PosNr) dann die 2. an die ursprüngliche Stelle der ersten, dann diese an die ursprünglich Stelle der 2.

[Peinhard]

Hallo m,

is schon klar, so mache ich das natürlich auch, wenn ich direkt auf der Datenbank arbeite. Hier aber ist der Dataset 'abgekoppelt' und es können beliebig viele Umsortierungen vorgenommen werden, die dann 'in eins' zurückgeschrieben werden sollen. Wie würdest du da vorgehen?

[mkinzler]

Vielleicht die lokale Kopie um ein Feld erweitern, das die alte Position aufnimmt.
Dann die alten Datensätze in der Datenbank anhand der alten Positionen lLschen und an die neuen Anfügen.

BTW. Es ist immer gefährlich Positionen zu ändern.

[Peinhard]

Auf sowas wird es wohl hinauslaufen: vor einem UpdateBatch alle Records durchgehen und eventuelle Pos-Änderungen feststellen (dazu bietet sich auch OriginalValue an). Wenn es eine solche gibt, alle Records, die auf rsModified stehen erst löschen und dann für jeden rsModified/rsInsert eigene Insert-Statements absetzen, den ganzen UpdateBatch mittels CancelUpdates 'verwerfen'. Alternativ den Unique Index verwerfen. Alles nicht richtig 'schön', aber die Funktionalität wird gewünscht.

Fällt jemandem noch etwas eleganteres ein?

[marabu]

Hallo Peinhard,

ist deine Tabelle eine Detailtabelle aus einer 1:n Beziehung? Und ist die PosNr Teil eines compound primary key (foreignKey, posNr)?

Grüße vom marabu

[Peinhard]

Hallo marabu,

ja, das ist das momentane 'Design'.

Gruß, Peinhard

[marabu]

Dann kann das unique constraint aber nicht auf PosNr alleine liegen - und der compound key ist ja wegen primary bereits unique. Ich denke das Problem ist hausgemacht. Kannst du nicht einen surrogate key (identity) in der Detailtabelle einführen? Dann wird nur noch ein sort index auf (foreignKey, PosNr) benötigt, welcher nicht unique sein muss. Die Behandlung der PosNr bei Verschiebungen kannst du dann prinzipiell so machen, wie Markus beschrieben hat, allerdings im Puffer - so sollte der batch update möglich sein und auch keinen Grund zum Meckern finden.

Grüße, marabu

[Peinhard]

Wenn ich dich recht verstehe meinte ich das, absichtlich etwas 'unscharf' formuliert, mit 'Verwerfen' des Unique Index. Nachteil wäre, das es von seiten der DB keine 'Versicherung' gegen doppelte PosNr (bzw Doppelpärchen foreign key/PosNr) mehr gäbe. Verstehe ich dich richtig...?

Das Verschieben im Puffer ist ohnehin kein Problem.

Gruß, Peinhard

[marabu]

Die Absicherung gegen doppelte "PosNr" hast du, wenn der Benutzer die "PosNr" nicht direkt manipulieren kann und das Vertauschen von Positionsnummern durch eine Exchange()-Routine von dir erledigt wird.

Grüße, marabu