Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi ADO + Mehrbenutzerbetrieb + Transaktionen + SQL Server (https://www.delphipraxis.net/134333-ado-mehrbenutzerbetrieb-transaktionen-sql-server.html)

hoika 20. Mai 2009 08:56

Re: ADO + Mehrbenutzerbetrieb + Transaktionen + SQL Server
 
Hallo,

solange du noch 2000 unterstützen musst wohl nicht.
Ab 2005 gibt es Snapshot als Isolation Level,
ist fast schon ein MGA (wie bei Firebird)
Das sollte viel bringen.

Wenn man mit dem SQL-Server arbeitet,
muss man sich halt mit dessen Vor- und Nachteilen beschäftigen
*klugscheiss*

Was mich wundert ist, dass zwei Selects (Read) sich bei dir blockieren.
In meiner URL vom vorigen Posting stand beim der Antwort noch was mit Deadlock-Logging

Schon mal ausprobiert ?
Bist du dir sicher, dass die Timeouts von 2 Selects kommen ?

Vielleicht reicht es ja erst mal, die kritischen Selects mit NoLock zu ergänzen.

Du solltest nur erst mal prüfen, ob der 2000-er das auch schon kennt.


Heiko

mschaefer 20. Mai 2009 09:40

Re: ADO + Mehrbenutzerbetrieb + Transaktionen + SQL Server
 
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


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:15 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz