Sperrverhalten beim SQLServer mit ADO

[Andreas Brueck]

Hallo Entwicker!

Ich arbeite seit neustem mit ADOExpress und habe eine Anwendung geschrieben, wo ich mittels einer TADOTable-Komponente auf einer SQL-Server-Tabelle (MS SQL-Server 7) zurgreife. Ich habe anschließend das Programm auf zwei Rechnern gestartet und mußte feststellen, daß es ohne weiters möglich war mit beiden Rechnern gleichzeitig den gleichen Datensatz zu bearbeiten. Von der BDE (und Paradox) her bin ich aber gewohnt, daß derjenige der einen Datensatz zurerst bearbeitet diesen sperrt, sodaß kein anderer diesen verändern kann.

Wie erreiche ich das mit dem SQL-Server?

Danke im vorraus
Andreas Brück

[Andreas Kosch]

Hallo,

alle SQL-Server verwenden das optimistische Sperrverfahren. Aber fast jeder Server stellt eine Hintertür zur Verfügung, über die zum pessimistischen Sperrverfahren gewechselt werden kann. Allerdings muss man dann auch alle unerwünschten Nebenwirkungen in Kauf nehmen.

Der <b>Microsoft SQL Server 7</b>verwendet mit den sogenannten <b>Hints</b> eine Erweiterung zum SQL-Standard, mit dem eine Tabelle für bestimmte Aufgaben gesperrt werden kann. Somit wechselt der SQL-Server vom optimistischen Sperrverfahren auf das pessimistische Sperrverfahren:

SELECT * FROM SomeTable <b>WITH (ROWLOCK)</b>

UPDATE SomeTable <b>WITH (ROWLOCK)</b><br>
SET SomeField = SomeValue

Neben ROWLOCK stehen noch weiter Lock-Hints zur Verfügung

[Andreas Brueck]

Hallo Herr Kosch,

vielen Dank erstmal für die schnelle Beantwortung meine Anfrage. Sie schreiben, daß man beim pessimistischen Sperrverfahren Nebenwirkungen in Kauf nehmen muß. Was sind das für Nebenwirkungen?

Gruss Brüc

[Andreas Kosch]

Hallo,

nun - ein pessimistisches Sperrverfahren macht im ungünstigsten Fall aus einem SQL-Server eine Einzelplatzdatenbank. Wenn der User mit seiner Sperre einen Index "erwischt", können alle anderen erst einmal Kaffee kochen gehen ;-)<br>
Nur beim <b>InterBase</b> behindern Lesezugriffe keine Schreibzugriffe und Schreibzugriffe keine Lesezugriffe. Der MS SQL Server verwendet hingegen ein klassisches Prinzip - daher gibt es ja auch die vielfältigen Lock-Hint-Alternativen, um den Server auf die eigenen Anforderungen konfigurieren zu können

[Andreas Brueck]

Hallo Herr Kosch,

in solch einem Fall würde ich mir das Sperren der Datensätze selber programmierien. Hierfür würde ich mir eine Sperr-Tabelle anlegen, wo ich für jeden Schreib-Zugriff auf meiner Haupttabelle einen Eintrag mit dem Benutzer mache. Dies ist bei diesem Projekt möglich, da ich nur eine Haupttabelle habe. Macht dies Sinn oder haben Sie eine bessere Lösung? Wenn Sie meiner Lösung zustimmen, wie ermittele ich eine eindeutige Identitätsnummer für eine Benutzer auf einem Rechner (Problem: Ein Benutzer meldet sich mit dem gleichen Namen auf mehreren Maschine gleichzeitig an.)

Gruss Brüc

[Andreas Kosch]

Hallo,

ja - ich stimme Ihrem Ansatz mit der Sperr-Tabelle zu. Das ist in der Branche üblich und wird häufig eingesetzt. Das einzige Problem dabei besteht darin, unfreiwillig getrennte Datenbankverbindungen erkennen zu können (d.h. der User loggt sich nicht ordnungsgemäss aus).

Als eindeutiges Kennzeichen würde ich mir von COM eine <b>GUID</b> (Global Unique Identifier) ausborgen, diese Nummer ist garantiert eindeutig:
<pre>
uses
ActiveX, ComObj;

procedure TFormMain.SBtnGetClick(Sender: TObject);
var
aTGUID : TGUID;
begin
CoCreateGuid(aTGUID);
ListBoxGUID.Items.Add(GUIDToString(aTGUID));
end;
</pre&gt

[Andreas Brueck]

Hallo Herr Kosch,

vielen Dank für Ihre Idee mit der GUID-Nummer. Sie sprachen das Thema "unfreiwilig getrennte Datenbankverbindungen erkennen" an. Haben Sie auch hier einen Lösungsansatz?

Gruss Brüc

[Andreas Kosch]

Hallo,

man kann im eigenen Programm beim ersten Start an einem Tag dafür sorgen, das alle Sperr-Einträge für diesen Benutzer (Name) gelöscht werden, die nicht vom gleichen Tag stammen. Somit hat man eine "selbstreparierende" Anwendung, bei der ein Datensatz im ungünstigsten Fall nur einen Tag gesperrt bleibt. Da ein Rechnerabsturz relativ selten vorkommt, ist das in vielen Fällen gerade noch tolerierbar

[Andreas Brueck]

Hallo Herr Kosch,

vielen Dank für Ihre Unterstützung.

Gruss
Andrea