Record Locking mit Delphi

[GreenHorn3600]

Hallo Zusammen,

ich weiss, dass dieses Thema nicht sonderlich populär ist (die Suche gibt 4 Treffer aus, welche mir nicht weiterhelfen), aber vielleicht kennt ja doch jemand wie man einen Datensatz in einer Datenbank via ODBC locken kann. ich stelle mir das wie folgt vor....

Code:

lock record for update (primary index fields) in table xxx;
if locked then 
begin
 ....
 release locked record;
end
else
 fehlermeldung(record konnte nicht gelockt werden);

kennt jemand hierzu die konkreten befehle um so etwas zu realisieren?

Herzlichen Dank
GreenHorn

[mkinzler]

In modernen DBMS ist Locking nur selten nötig, da dies durch eine Transaktionssteuerung teilweise umgangen werden kann oder sie besitzen besondere SQL-Erweiterungen wie "with lock" select .. for update" welchen dann ein Locking veranlassen.
Aus deiner Fragestellung geht jetzt nicht genau hervor, ob du mit Access arbeiten willst oder noch ein geeignetes DBMS suchst.
Warum ODBC?

[GreenHorn3600]

hallo MKinzler,

für keine Datenspeicherungen nehme ich gern Access, da die Daten in nur einer Datei abgespeichert werden. So lange das Progy auf nur einen Rechner läuft, fühle ich mich wohl. Wenn ich es jedoch im Netzwerk einsetzen möchte, kommt automatisch die Frage, wie kann man die Daten vor gegenseitigen überschreiben schützen. Dabei schwebt mir vor, dass zwischen den letzten lesen, wo der status in ordnung war und der update operation, der datensatz vor veränderung geschützt wird, nur wie kann man diesem entsprechend allokieren, damit er nicht verändert wird? Eine Abstraktionsschicht auf dem Server einzuziehen, bei dem die Datensätze "logisch" gesperrt werden können, ist eine Möglichkeit, hab nur keine Lust so ein Monster zu Programmieren, da dies doch eine Funktion der Datenbank sein muss (für was braucht man sonst eine Datenbank, um nicht die integrität der Daten zu gewährleisten).

Hoffe dies dient zur Erläuterung. Wie umgeht Ihr so die Problematik des gegenseitigen überschreibens?

Grüsse
GreenHorn

PS:

• nehme auch noch gern den MS SQL Server, dieser ist jedoch nicht transportabel.
• ODBC nehme ich gern, um unabhängig von der Datenbank zu sein und ggf. auch auf einer anderen Datenbank aufsetzen zu können

[mkinzler]

Ich kenne mich mit Access (programmiertechnisch) nicht so aus, kenne nur dessen Zicken als Anwender und würde deshalb von dessen Anwendung abraten.
Wenn du ein richtiges DBMS einsetzt umgehst du deine Probleme.
Vom MSSQL-Server gibt es verschiedene Versionen z.B. die MSDE/SQL2005 express oder compact, so das die Dateien transportabel sind.
ODBC ist veraltet und einfach portierbar sind die Anwendungen dann trotzdem nicht.
es gibt hier im Forum viele Beiträge, die sich mit DB-Alternativen beschäftigen, vielleicht findest du dann auch die Datenbank, die für deine Problem geeignet ist

[marabu]

Hallo,

Locking mittels ADO geschieht standardmäßig und vollautomatisch auf Page-Level (2048 Byte), sodass in der Regel mehr als ein Record gesperrt wird. Der Entwickler kann aber der automatischen Lock Escalation reinpfuschen, wenn er Sperren auf RecordSet- oder Database-Level anfordert. ODBC bietet keine Locking Funktionalität und sollte ADO über ODBC eingestzt werden, dann ignoriert ODBC Sperrversuche solange es geht und bringt ansonsten Fehlermeldungen.

Bei den automatischen Sperrmechanismen lässt sich noch der LockMode einstellen: Optimistic oder Passimistic. SQL-Server arbeiten in der Regel optimistisch (Sperren so spät wie möglich), Access und Co. mit pessimistischen (so früh wie möglich) Sperren.

Es ist Aufgabe des Entwicklers auf die Fehler zu reagieren, die durch konkurrierende Zugriffe im Mehrbenutzerbetrieb auftreten. Die Sperren selbst werden optimal von der Transaktionskontrolle der DB-Engine verwaltet.

Grüße vom marabu

[GreenHorn3600]

hallo Marabu,

wenn ich dich recht verstehe, brauche ich da nichts zu machen, da der Server das sperren automatisch übernimmt. demnach vom letzten lesenden auf dem schreibenden/lesenden zu griff.

klingt ja nett... :thumb: nur so ganz glauben kann ich es nicht :gruebel:

grüsse
und noch einen schönen Sonntag.

[marabu]

Hallo,

hier noch ein wenig Hintergrundinfo, versteckt in den VB-Quellzeilen dieses Knowledgebase-Artikels: How to Use the Three Levels of Database Locking in VB 3.0

Dir auch noch einen schönen Sonntag.

[alzaimar]

GreenHorn3600: Access ist eine Desktop-Datenbanke (Einzelplatz), die mit viel Mühe mehr schlecht als recht auf 'Mehrbenutzer' getrimmt wurde.

Mehrbenutzerbetrieb und Access schließen sich gegenseitig aus, auch wenn immer noch sehr viele MB-Anwender mit Access entwickelt werden.

Lass die Finger davon.

Wir haben einen Lockmechanismus bei einer Kundenverwaltung implementiert: Benutzer A fordert Kundendatensatz XY an und will ihn verändern. Vorher schickt er eine Lock-Anforderung an die Mittelschicht. Sofern die Lockanforderung erfolgreich war, kann er den Datensatz verändern, die Änderungen speichern und den Lock wieder aufheben.

Du musst dann Vorkehrungen treffen, das das 'Unlock' z.B. infolge eines Rechnerabsturzes nie aufgehoben wird, beispielsweise durch ein 'Zwangsunlock' nach 10 Minuten: Der Benutzer muss sich dann eben etwas beeilen.
100% vollautomatisch und ohne jegliche manuelle Eingriffe in seltenen Extremsituationen wird das nicht funktionieren, wiel nach Murphy immer irgendwo etwas schief geht.

Nach meiner Erfahrung ist dieses Locking keine gute Idee, besser ist eine Konfliktbehandlung, also wenn zwei Anwender Änderungen am Datensatz simultan vornehmen wollen.

[Bernhard Geyer]

Zitat:

Zitat von marabu

Locking mittels ADO geschieht standardmäßig und vollautomatisch auf Page-Level (2048 Byte),

Diese Regel gilt aber auch nur beim MS SQL Server auch aufgrund der einschränkungen der Implementierung? AFAIK kann die 2005er-Version auch Sperren auf Satz-Ebene.

[marabu]

Hallo Bernhard,

time flies.

Dein von mir zitierter Satz bezog sich leider auf eine ältere Version von Access, denn soeben habe ich beim Recherchieren gelernt, dass Access 2000 seinen default lock mode auf Optimistic setzt. Darüber hinaus scheint Pessimistic bei diesem Produkt ein Synonym für Record-Level Locking zu sein. Die Page-Size wurde auch verdoppelt. KB225926

Meine Aussagen bezogen sich in erster Linie auf MS Access, da der OP es bei seinem Beitrag als DBMS angegeben hat. Mit SQL Server 2005 habe ich noch keine Erfahrungen, aber wenn wir da von Neuerungen sprechen wollen, dann müsste das Thema RLV (Row Level Versioning - Hallo Interbase) heißen - oder? Technet

Ansonsten kennt schon der SQL Server 2000 eine Page-Size von 8KByte und insgesamt sechs Lock Typen, darunter zwei auf Record-Ebene: Einer sperrt Records auf einem Heap und der andere Records in einem Index. Ich vermute, dass diese Sperren nicht vom Entwickler kontrolliert werden können, bin mir aber keineswegs sicher.

Ich verlinke mal Server Books Online 2005, da ich schlecht auf meine 2000-er Ausgabe verlinken kann: klick

Freundliche Grüße