Legacy-Anwendung TTable->TFDTable LockTable

[Poelser]

Moin zusammen,

wo gerade ein Thread über den Umgang mit Legacy-Anwendungen am Laufen ist, habe ich hier ein Problem mit dem Sprung von D7 auf D10.4.2.

In dem alten Code sind solche Sachen drin, wie TabelleXYZ.LockTable(ltWriteLock) bzw. UnLockTable(). Dies Locks sind in der alten Unit DBTables drin.
Aber die gibt es ja nicht mehr. FireDAC hat da scheinbar nix Passendes, und Google war auch nicht wirklich hilfreich 20 Jahre zu überspringen .
Hat irgendwer einen Link o.ä. um mir da mal auf die Sprünge zu helfen?

[Uwe Raabe]

Zitat von Poelser:

In dem alten Code sind solche Sachen drin, wie TabelleXYZ.LockTable(ltWriteLock) bzw. UnLockTable(). Dies Locks sind in der alten Unit DBTables drin.
Aber die gibt es ja nicht mehr. FireDAC hat da scheinbar nix Passendes,

Nein, Locking geht einfach nicht mehr. FireDAC geht da einen anderen Ansatz, so nach dem Motto: Mach erst mal und reagiere, wenn es nicht klappt.

Wenn ein geänderter Datensatz gespeichert wird, kann man über UpdateMode entscheiden, welche Felder in der WHERE Klausel angegeben werden. Bei upWhereAll werden alle abgerufenen Felder eingesetzt. Damit kann man sicherstellen, dass zwischenzeitlich keines der Felder verändert wurde. Bei upWhereChanged sind das nur die Felder, die man selbst verändert hat. Das lässt sich noch über die ProviderFlags in jedem einzelnen Feld feintunen.

Schlagt nun ein solches Update fehl, weil z.B. ein Feld von anderer Stelle verändert wurde, kann man im OnReconcileError der Query entsprechend darauf reagieren.

[Frickler]

Die Frage ist: wofür wurde das verwendet? Wurden tatsächlich in einer Firebird-Datenbank ganze Tabellen gelockt?

[Poelser]

Zitat von Frickler:

Die Frage ist: wofür wurde das verwendet? Wurden tatsächlich in einer Firebird-Datenbank ganze Tabellen gelockt?

Ja. Das hatte wohl den Sinn, dass da z.B. irgendwelche Prozentsätze nicht geändert werden durften, wenn die in einer Kalkulation gelesen wurden.

Wie Uwe schon geschrieben hatte, ist diese Vorgehensweise wohl ohnehin nicht mehr möglich. Ich bin momentan da wohl eher besser beraten, dass ganze transactionbasiert umzusetzen. Glücklicherweise bin ich in der Situation, dass nicht 1:1 umsetzen zu müssen. Und der Aufwand dafür hält sich in Grenzen, da diese alte Technik in dem Fossil nicht sooo oft benutzt wurde .

[BerndS]

Da ich die BDE nicht mehr installiert habe, kann ich nur vermuten, dass das nur innerhalb von Anwendungen funktioniert, die die BDE verwenden. Sollte ich mich richtig erinnern, gab es eine Datei, auf die alle Anwendungen Zugriff haben mussten. Das standen dann die Sperren usw. drin.
Aber 100% sicher bin ich mir da nicht.

Wir haben das in Firebird mit eine Sharetabelle gelöst. Da stehen der Tabellenname, die ID des Datensatzen oder ID = 0 für die ganze Tabelle drin. Zusätlich so Name, Grund und eine ConnectionID, so dass erkannt werden kann, ob die Sperre noch gültig ist.
Über den Tabellennamen + ID gibt es einen eindeutigen Index, wodurch eine Sperre nur einmal möglch ist.

Dadurch funktionier das ganze nur, wenn man die Sharetabelle auch auswertet und beschreibt.