Hallo,
mit Bordmitteln geht das wie folgt,
Bsp. geht davon aus, dass der primkey id heisst und der aktuelle Record id=5 ist
A: starttransaction
update table1 set id=5 where id=5
B: starttransaction
update table1 set id=5 where id=5 <- Fehler
A hält die transaktion offen, und solange er kein rollback oder commit macht,
kommt keiner an den Datensatz ran.
Nachteil: offene Transaktion
(
http://entwickler-forum.de/archive/i...p/t-18455.html)
Andere Rangehensweise:
Vorm Ändern wird die ID in eine Sperr(Lock)Tabelle geschrieben,
klappt das, kann es weitergehen.
Klappt es nicht (unique index), ist gerade eine dran am Ändern.
Die Sperre wird mit einem TimeStamp geschrieben
und über Thread / Time vom Client (deiner App) ständig aktualisiert.
Vor dem Versuch, was einzutragen, werden "alte Sperren" entfernt,
z.B. die > 15min.
Ds wären dann die von abgstürzten Apps.
Vorteil :
Du kannst sagen, Datensatz wird gerade bearbeitet von XXX (User packst du mit in die Locktable),
seit (TimeStamp).
Nachteil: Programmieraufwand.
Es wird mind IBX benötigt, um readcommited als Transaktions-Modus einzustellen
(kann das die
BDE ?)
Die Locktable sieht etwas so aus
Id: AutoInc Generator)
TableId / TableName
KeyField Integer
Gen_Date TimeStamp
UserId / UserName
In einer alten Entwickler (6-2003) war das mal als Bsp
"Ich sperre, also bin ich" drin.
Heiko