ADO + Mehrbenutzerbetrieb + Transaktionen + SQL Server

[mschaefer]

Mal abgesehen von den technischen Raffinessen muß man sich auch im Klaren sein wie der Arbeitsablauf sein soll.

1. Bei Preisänderungen von Artikeln ist "Snapshot" eine feine Sache. Solange ein Artikel bearbeitet wird, kann im Warenverkauf noch die Beschreibung der alten Version angezeigt werden. Wenn der Rekord dann aktualisiert ist, ist er eingepflegt und gut.
-> typisches "with no Lock" Szenario -<

2. Zwei Anwender dürfen prinzipiell nicht gleichzeitig die selbe Rechnung zur gleichen Zeit bearbeiten. Da ist kein "Snapshot" gefragt! Der Record muß einfach für die Zeit des Bearbeitens für die anderen gesperrt bleiben.
-> typisches "pessimistic Locking" -<


Im 2. Fall muß auch die Architektur der Anwendung daruaf abgestimt sein: Änderbare Listenansichten á la DBGrid sind hier nicht hilfreich, sondern es sollte ein Änderungsbereich aufgemacht werden mit vorgelagertem Test ob eine Sperrung vorliegt.

Leidlich erscheint mir dabei, dass man bei den meisten Systemen den geperrten Datensatz erst ducht eine Ghostwrite herausbekommt. Derzeit wird unter Delphi "pessimistisches Locking" weder durch Zugriffskomponenten noch durch die Gridanzeige ernsthaft unterstützt. Üblicherweise wird dann sogar eine seperate Sperrtabelle eingesetzt, aber alles mit Handarbeit.

Grüße in die Runde // Martin