Record Locking mit Delphi

[bttb930]

Ihr diskutiert zuviel was ihr wollt. Es wurde nach Locking gefragt, und nicht nach einer Abstimmung wer für und wer gegen Access ist.

Wie hier ja schon durchschimmert, musst du tatsächlich als Entwickler alles selber machen. Es gibt da mehrere Möglichkeiten:

- Datensatz lesen. Er ist nicht gelockt.
- Datensatz in der Anwendung ändern.
- Datensatz soll gespeichert werden - dazu per Dataset (TQuery oder TTable) öffnen für Edit. Dadurch wird er gelockt. Jetzt nicht direkt schreiben sondern erstmal prüfen: Sind da die gleichen Daten drin wie du gelesen hast? Falls ja: Daten schreiben und speichern (Post). Falls nein: Meldung an Benutzer oder was-weiß-ich und schließen.

Alternativ - da hast du weniger zu tun, nur legt ein anwender dann alle anderen still:

- Connection öffnen
- Transaktion starten. Bei MSSQL-Server würdest Du REPEATABLE READ nutzen.
- Datensätze öffnen, wenigstens einen beschreiben (dadurch ist dann die gesamte tabelle für alle anderen benutzer gesperrt).
- Datensätze in der anwendung verändern lassen und dann schreiben.
- Transaktion beenden.

Finde ich persönlich sehr schlechte lösung. Wäre aber wohl das, wonach du gefragt hast.

Dritte Alternative, die auch schon oben angegeben wurde, aber nicht in einzelschritten:

- Datensätze lesen und jeweils sperren indem du in eine andere Locking-Tabelle schreibst, wer welchen datensatz wann gesperrt hat. Beim lesen prüfst du natürlich, dass der zu lesende datensatz nicht schon gesperrt ist.
- datensätze verändern und speichern
- lcoking-eintrag entfernen.

Problem wurde oben auch genannt: was ist wenn der rechner abstürzt. Dazu könnte man beispielsweise die oben erwähnte 10-min-regel machen. Eine ideale lösung gibt es dafür nicht.

Die unterschiede sind:
- ganz oben lockst du gar nichts und prüfst nur ob die daten in der zewichenzeit verändert wurden. Ggf wird der anwender eine "wurde verändert"-meldung bekommen.
- in der mitte sperrst du so restriktiv, dass dem anwender der da sperrt nichts passieren kann, alle anderen in dem moment aber nicht arbeiten können. das ist natürlich in einer mehrbenutzerumgebung ein ko-kriterium.
- und unten sperrst du indirekt durch die locking-tabelle, die du selbst verwaltest. der nachteil ist, dass bei rechner-absturz evtl. datensätze erstmal nicht mehr erreichbar sind (für die anderen). aber diesen nachteil kann man wie gesagt ganz gut lösen.

also nichts mit automatisch.

PS: um auch nochmal was zu access zu sagen: Leute die schreiben: "Access ist scheiße. Hab nie damit gearbeitet, ist aber so!"... was soll man denn von denen halten? Wir haben alle unsere vorurteile gegen microsoft, aber ich habe viel mit access gearbeitet und muss sagen: Wenn man diese DB richtig einsetzt, dann ist sie wirklich sehr sehr gut! Sehr stabil, mir ist noch nie eine DB kaputt gegangen, sehr performant und so weiter. Es ist nunmal eine Desktop-Datenbank, die hat ihre Grenzen. Aber die meisten anwendungen können mit diesen grenzen gut leben (wer verwaltet schon 60 Mio Kunden). Und auch in Mehrbenutzerumgebungen hatte ich mit Access nie Probleme. Das wirkliche Problem bei Access ist, dass es relativ leicht ist, sich dort was zurechtzuklicken. Daraus entstehen dann datenbanken, die nicht wartbar sind, weil die ersteller keine ahnung hatten. Da ist das problem aber nicht access, sondern die ersteller der dbs sind das problem. Also schimpft nicht immer gegen access solange ihr die db nicht wirklich kennt. Euer geschimpfe zeigt nur eure ignoranz und eigentlich zeigt ihr damit nur, dass ihr euer fähnchen in den wind haltet.

[majmarcus]

[quote="bttb930"]
- Datensatz lesen. Er ist nicht gelockt.
- Datensatz in der Anwendung ändern.
- Datensatz soll gespeichert werden - dazu per Dataset (TQuery oder TTable) öffnen für Edit. Dadurch wird er gelockt. Jetzt nicht direkt schreiben sondern erstmal prüfen: Sind da die gleichen Daten drin wie du gelesen hast? Falls ja: Daten schreiben und speichern (Post). Falls nein: Meldung an Benutzer oder was-weiß-ich und schließen./quote]

Hallo, geht besonders einfach wenn ein extra Feld (not nullable) bspw. ("rowversion") in jeder Tabelle mit dabei ist und bei jedem update der Zeile hochgezählt wird. Damit kann schnell und einfach ein konkurierendes Update erfaßt und darauf wie auch immer reagiert werden.

Initialisieren beim Insert mit 0 wäre dabei hilfreich

[alzaimar]

Zitat von bttb930:

Ihr diskutiert zuviel was ihr wollt. Es wurde nach Locking gefragt, und nicht nach einer Abstimmung wer für und wer gegen Access ist.

Das hat nix mit Duskussion zu tun: Es ist ein noch nicht mal gut gemeinter Rat, sondern einfach eine Aufschrei: "LASS DIE FINGER VON ACCESS BEI MEHR ALS 1 ANWENDER!eins!!elf'

[mkinzler]

Außerdem heißt der Thread ja "Access oder auch was anderes"

[hoika]

Hallo,

aus "habe ich gehört und gesehen"
20 gleichzeitige Nutzer bremsen Access extrem aus.
Absturz, Exclusiv reingehen, reparieren, weiter

Ein Umstieg auf SQL-Server (per Access Project)
gehob das Problem.


Zu den Locks und den 10 Minuten.
Führe eine Locking-Tabelle mit, in der UserId, Tabelle (Id), zu lockender PrimKey
und Datum/Uhrzeit) mitgelockt werden.
Und nu kommst !!
Per Timer oder Thread werden die aktuellen Locks aufgefrischt,
also Datum/Uhrzeit aktualisiert.
Schmiert das Programm ab, "verfällt" die Sperre irgendwann (z.B. nach 5 Minuten)

Beim Start der App oder beim Setzen irgendeines Locks
werden alle Locks < X Min gelöscht (am besten per stored procedure).
Die Tabelle hat den Vorteil, dass man auch eine Meldung ala
"Datensatz wird gerade bearbeitet von XXX seit YYY"

Zum Locken allgemein.
Ein Locken bei Mehrbenutzerbetrieb ist notwendig.
Wenn ich einen Kunden bearbeiten will und verhindern
will, dass zum gleichen Zeitpunkt das jemand anders soll,
was bliebt mit anderes übrig ?
Das Locken hat hier natürlich nichts mit den DB-Locksbei konkurrierenden
Zugriffen zu tun, sondern ein lock innerhalb der Anwendung.


Heiko