Zugriff auf einen Datensatz sperren oder freigeben

[Eppos]

Hallo zusammen,

suche noch Anregungen für die Sperrungen eines Datensatzes, wenn ein Benutzer den Datensatz im Zugriff hat.

Also kurze Erklärung:

Benutzer "A" und Benutzer "B" arbeiten mit der Tabelle "XYZ"
Benutzer "A" öffnet den Datensatz "1".
Benutzer "B" öffnet eine Sekunde später den gleichen Datensatz. (Was er aber eigentlich nicht darf, da er gesperrt sein sollte)

Wie handhabt Ihr dieses Problem?
Gibt es da eine möglichkeit bei der Firebird-DB diese Problem zu handhaben?

Ich kenne schon eine Lösung, die dan einen benutzer bei diesem Datensatz hinterlegt, und ich das bei den anderen Benutzer immer abprüfe, ob dieser Datensatz im Zugriff ist oder nicht. Aber was ist wenn die Anwendung abbricht...?!

Vielen Dank!

Eppos

[mkinzler]

Locking ist unter FB dank des Multi Generatoren Architektur (MGA) oft nicht notig. Sonst kann man natürlich Datensätze auch locken

[bluesbear]

Zitat:

Datenbank: Firebird, Version: 1.5, Zugriff über: bde

Zugriff über BDE? :snowball: Grundsätzlich gebe ich mkinzler recht, aber ob die BDE das hinbekommt? Habe ich noch nicht ausprobiert, und werde es auch nicht tun.

[hoika]

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