Einzelnen Beitrag anzeigen

bttb930

Registriert seit: 6. Okt 2003
372 Beiträge
 
#11

Re: Record Locking mit Delphi

  Alt 24. Jun 2007, 21:41
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.
  Mit Zitat antworten Zitat