wie kann man datensatzsperre realisieren???

[ake]

hallo,

ich habe bisher nur mit desktop-datenbanken wie paradox, access und konsorten gearbeitet. c/s ist völliges neuland. derzeit habe ich begonnen eine kleine datenbank mit den ibx kompos zu schreiben. neue daten fügen ich über einen extra form ein (wird mit showmodal aufgerufen). wenn nun ein user bereits einen datensatz editiert (wird auch über das formular zum einfügen getätigt), und ein anderer user den selben datensatz editieren möchte, soll eine mdleung kommen "datensatz gesperrt" in der art. der code sieht folgendermaßen aus:
<pre>

if InsertRecForm.ShowModal = mrOK then
begin
with StoredProc3 do
begin
Prepare;
Params.ParamByName('NAME_IN').AsString := T1;
Params.ParamByName('VNAME_IN').AsString := T2;
Params.ParamByName('TEL_IN').AsString := T3;
Params.ParamByName('PAR_NAME').AsString := InsertRecForm.Edit1.Text;
Params.ParamByName('PAR_VNAME').AsString := InsertRecForm.Edit2.Text;
Params.ParamByName('PAR_TEL').AsString := InsertRecForm.Edit3.Text;
ExecProc;
end;
RefButtonClick(Sender); //Automatisches aktualisieren.
end;
Database1.Commit;
except //Wenn Datensatz von anderem User bearbeitet wird.
Database1.Rollback;
MessageDlg('Satz gesperrt!', mtWarning, [mbOK], 0);
end;
</pre>

als ich das selbe mit den normelen kompos (über die bde) gemacht habe funktionierte es, seit ibx kommt keine meldung, es wird also offensichtlich keine exception ausgelöst. wer kann mir sagen, wie ich sowas realisieren kann??

mfg
ake

[ake]

hallo,

ich bin erstaunt das ich noch immer keine antwort erhalten haben, bei so einem wichtigen aspekt. setzt man das in interbase nicht ein, oder habe ich mich falsch ausgedrückt????

mfg
ak

[Christian Schankweiler]

Hallo Ake.
Ich bin momentan bei der Umstellung eines BDE-Projekts auf MSSQL, IB, ORA. Dabei hab ich mir dieselbe Frage gestellt. Auf der einen Seite, sollte das die jeweilige DB selber berücksichtigen, da ich mich nicht darauf verlassen will bzw. bei späteren DB-Erweiterung (mySQL) nicht kann, habe ich in jeder Tabelle ein Feld sys_locked (Integer default -1). Beim Editieren wird dieses Feld durch die BridgePattern auf > -1 gesetzt bzw. wenn man das Login/Logout der Anwender mit speichert (separate Tabelle), dann die ID des Anwenders darin gespeichert wird (so mache ich es; dadurch kann ich die Meldung "Datensatz wird vom Anwender Müller bearbeitet!" ausgeben). Sollte nun ein anderer Anwender diesen Datensatz versuchen zu Editieren, dann wird der WErt abgefragt und bei <> -1 die Bearbeitung abgeblockt. Beim Post wird das Feld dann auf -1 zurückgesetzt.
<br>
Hoffe ein wenig geholfen zu haben.
<br>
<br>
Gruß,<br>
Christia

[ake]

hallo,

erst einmal vielen dank für die antwort. das system das du einsetzt mit der zusätzlichen spalte wird auch von dbase verwendet, paradox nimmt dazu die datei pdxusr.net oder ähnlich. wie machen das die anderen? verlassen die sich auf das dbms? ich finde diesen punkt nun einmal sehr wichtig...

mfg
ak

[Andreas Kosch]

Hallo,

alle SQL-Datenbanken arbeiten mengenorientiert und nutzen daher bevorzugt das optimistische Sperrverfahren. Nur die Desktop-Datenbanken wie dBASE, Paradox, ACCESS etc. benötigten die "Krücke" des pessimistischen Sperrens, da es dazu keine technische Alternative gibt.

Man kann auch bei einer SQL-Datenbank eine pessimistische Sperre setzen (also auch beim InterBase), aber die Nebenwirkungen im Mehrbenutzerbetrieb sind so nachteilig, dass in der Regel auf so etwas verzichtet wird.

In meinem Buch <i>InterBase Datenbankentwicklung mit Delphi</i> beschreibe ich auf den Seiten 352...354 ein Programm, dass eine pessimistische Datensatzsperre nutzt. Das Programm nutzt das Transaktionsverhalten des InterBase aus, um während der "Sperrzeit" den Datensatz "schutzig zu stempeln", so dass alle anderen Benutzer (andere Datenbankverbindungen) außen vor bleiben

[ake]

hallo,

dein buch "interbase mit delphi" habe ich natürlich. was ich jetzt aus deiner antwort heraushöre ist, das man im normalfall den mehrbenutzerzugriff dem dbms überlassen sollte und nur in besonderen ausnahmefällen so etwas wie eine zusätzliche (dem pessimistischen verfahren nachempfundene) sperre einbauen sollte, ist das richtig?

mfg
ak

[Andreas Kosch]

Hallo,

&gt;..ist das richtig?

Ja - denn dazu sind die SQL Server ja schließlich da :-) <br>
Bei dBASE, Paradox oder ACCESS greift der Client direkt auf die physische Datenbankdatei zu, so dass man dort zwingend einen Sperr-Mechanismus braucht. Im Fall einer SQL Datenbank greift aber nur der Prozess des SQL-Servers selbst auf die Datei zu, ein Client kann nur "Wünsche" in Form von SQL-Anweisungen zum Server schicken. Über die Transaktionen schottet der SQL Server die Datenbank so ab, dass jeder Client "denkt", er sei der Einzige.

Nur dann, wenn ein bestimmter Datensatz "reserviert" werden soll (d.h. ein anderer Client bekommt sofort die Info, dass ein anderer User damit arbeitet), macht ein eigener Sperr-Mechanismus Sinn

[Bruno Danuseg]

Hallo,

ich habe noch eine Frage zu dem (eigens gepflegten) Feld "sys_locked", das die Benutzernummer des z.Zt. bearbeitenden Nutzers speichert: Im Beitrag stand "...beim Post wird das Feld auf -1 zurückgesetzt...". Heisst das denn, dass - während der Nutzer den Datensatz editiert - eine Transaktion offen ist? wenn ja, sehe ich zwei Probleme: Zum einen sollte die Dauer einer Transaktion nicht vom Nutzer bestimmt werden (Thema "Frau A. geht während der Änderung Kaffee holen...), zum anderen kann es sein, dass ein anderer Nutzer je nach Transaktionslevel die Sperrung gar nicht mitbekommt.

Wenn dies nicht so ist, d.h. der Wert in sys_locked wird vor Start der Transaktion gesetzt, stellt sich die Frage, wie das Feld wieder "freigemacht" werden kann, wenn das Programm/der PC/der Server vor dem Ende der Bearbeitung abstürzt

[Christian Schankweiler]

Hallo,<br>
<pre>: Zum einen sollte die Dauer einer Transaktion nicht vom Nutzer bestimmt werden (Thema "Frau A. geht während der Änderung Kaffee holen...)</pre>
es wird ein TimeOut-Intervall gesetzt, der in einem solchen Fall nach einer bestimmten Zeit zurücksetzt.<br>
<pre>zum anderen kann es sein, dass ein anderer Nutzer je nach Transaktionslevel die Sperrung gar nicht mitbekommt</pre><br>das werden die Tests ergeben, prinzipiell darf das natürlich nicht vorkommen.<br>
<pre>wie das Feld wieder "freigemacht" werden kann, wenn das Programm/der PC/der Server vor dem Ende der Bearbeitung abstürzt.</pre><br>
dazu gibt es ein Werkzeug zum Freigeben der Datensatzsperren, basierend auf den entsprechenden Anwender-Locks.
<br>
<br>
Diese Prinzip der Datensatzsperren basiert auf einer vorherigen Version des Programms. Dort lief es einwandfrei. Die jetzige Version ist eine Erweiterung und sollte auch problemlos funktionieren

[Bruno Danuseg]

Hallo,

nun, wenn die Transaktion gestartet wird, dann das Locking-Feld upgedatet wird, dann die Änderungen vorgenommen werden und erst dann die Transaktion beendet wird, sollte ein zweiter Nutzer a) diese Sperre nicht bemerken oder b) bei Committed Read no record version wait so lange warten müssen, bis die Transaktion des ersten abgeschlossen ist.

Grundsätzlich finde ich aber die Verfahrensweise gut, den Nutzer schon beim Versuch der Änderung zu informieren, dass dieser Datensatz bereits von Nutzer X bearbeitet wird. Die Lösung des "schmutzig stempeln" von Herrn Kosch empfinde ich aber auch nicht als das Non-plus-Ultra, da ja hier eine Transaktion offenbleibt, während sich der Satz in der Bearbeitung befindet