Wie richtig mit Transaktionen und ADO umgehen?

[andy3453]

Hallo,

ich möchte ein Programm schreiben mit dem mehere User gleichzeitig arbeiten sollen.
Dazu verwende ich D7, ADO und einen MSSQL2000 Server.

Ich hab mich bereits ein wenig mit Transaktionen in Delphi und ADO auseinandergesetzt, aber habe keine richtige Lösung für das
Problem des 'Lost Updates' gefunden.

Mein Code für ein Update sieht bislang erstmal so aus:

Delphi-Quellcode:

 ADOConnection1.BeginTrans;
  try
    QKunde.Active:=false;
    QKunde.SQL.Clear;
    QKunde.SQL.Add('UPDATE Kunde SET KName1=Hanswurst WHERE KundeID=288');
    QKunde.ExecSQL;
   ADOConnection1.CommitTrans;
      except
    on E:Exception do ADOConnection1.RollbackTrans;
    end;

Soweit klappt das Ganze auch ganz gut, im Profiler kann ich die Transaktion verfolgen und ich das Prog zwichendurch abschieße
gibt´s nen feinen RollBack. :spin2:

Nur wie macht man es richtig das wenn zwei User gleichzeitig in der Kundenmaske sind der eine dem anderen nicht das Update versaut.(Lost Update) Klar ich könnte grundsätzlich den Datensatz sperren und eine Meldung ausgeben, nur ist das nicht so richtig schön finde ich. Ich hatte schon gedacht den kompletten Datensatz in ein Array zu speichern und dann den Inhalt des Array im Moment des Updates mit dem jetzt aktuellen Inhalt zu vergleichen. Würde dann ein Unterschied sein könnte ich ein Rollback auslösen.

Hmm, irgendwie komm ich da nicht wirklich weiter. Ist das überhaupt der richtige Ansatz den ich da habe?
Oder macht das ein schlauer Programmierer ganz anders? :roll:

In diesem Sinne, danke schonmal für Eure Hilfe...

Andy

[Bernhard Geyer]

Das Problem mit Multi-User-Zugriff kannst Du (wie Du teilweise schon angemerkt hast) auf mehrere Arten lösen:

1, Wenn der User einen Datensatz öffnet, so wird dieser gesperrt (z.B. über einen "Sperrserver" oder eine Sperrtabelle). Jeder weitere user der diesen Datensatz zum bearbeiten öffnen will, bekommt einen Meldung das dieser Datensatz in Bearbeitung ist und Nur-Lesend geöffnet werden kann.

2, Beide User öffnen den Datensatz und der erste schreiber gewinnt. Der zweite Schreiber bekommt beim Versuch des Speichern eien Fehlermeldung das seine änderungen nicht gespeichert werden können. Dies kann auf mehrere Arten festgestellt werden:
a, Du führst eine Abfrage der Art: "Select * from xyz where ... (for Update)". Auf den Ergebnissdatensatz werden die änderungen Eingetragen und beim Posten stellt die DB fest das es schon eine neuere Version des Datensatzes gibt und lößt eine Fehlermeldung aus (Geänderter Datensatz vn 2ten User erst mal nicht in DB übertragbar).
b, Du führst bei deinen Tabellen jeweils einen Zeitstempel mit (welche von der DB bei änderungen gefüllt wird), so das beim Update (mittels Update-Commando) auch auf diese Spalte verglichen wird. Wird nun vom Update-Kommando kein Datensatz geändert, so kannst Du eine Fehlermeldung generieren und evtl. die unterschiedlichen Tabellenspalten anzeigen lassen um nochmal einen Update (ohne Zeitstempel-Spalte) durchzuführen.

Welches Verfahren nun das bessere/optimalere für deine Anwendung ist kann man so nich generell sagen. Es kommt auch darauf an was deine Anwender für ein Verfahren bevorzugen bzw. wie häufig kollisionen zu erwarten sind. Denn je nachdem ist das eine oder andere Verfahren sinnvoll/zu bevorzugen. Ich selbst habe schon mal nach Version 1 mittels "Sperrserver" eine größere Anwendung entwickelt.

[andy3453]

Hallo Bernhard,

danke für Deine Antwort. :-D

Zitat:

a, Du führst eine Abfrage der Art: "Select * from xyz where ... (for Update)". Auf den Ergebnissdatensatz werden die änderungen Eingetragen und beim Posten stellt die DB fest das es schon eine neuere Version des Datensatzes gibt und lößt eine Fehlermeldung aus (Geänderter Datensatz vn 2ten User erst mal nicht in DB übertragbar).

Diese Variante halte ich bei der Anwendung für Sinnvoll, allerdings ist mir nicht ganz klar wie ich das genau Anstellen soll.
Kannst Du mir nochmal ein kleines Bisschen helfen:?:

Wie muss denn das Select genau aussehen, und wie erzeuge ich die Entsprechende Fehlermeldung?
Dieser Bereich ist mir im Moment noch etwas schleierhaft :gruebel:

viele Grüße

Andi

[Bernhard Geyer]

Dazu erstellst Du mal folgendes Testprogramm.

Hänge an eine DB-Grid über die entsprechenden DB-Komponenten eine Testtabelle (oder eine Tabelle deines Projekts). ergänze einen TDBNavigator.

Starte das Programm 2 mal und positioniere dich in beiden Grids auf einen bestimmten Datensatz und gehe in den Edit-Modus.
Ändere im ersten Programm Daten und speichere sie. Anschließden ändere im zweiten Programm die Daten und versuch sie zu speichern. Es sollte eine entsprechende Fehlermeldung kommen. Delphi hat mit seinen Komponenten schon dieses Verhalten als Standartverhalten implementiert. Über den Profiler solltest Du mitbekommen was auf SQL-Seite passiert.

[andy3453]

Hi,

ja das klappt natürlich, Delphi wirft eine Meldung aus.

Nur wenn ich das mit einem sql "UPDATE Tabelle SET..." mache meckert er nicht. Hat der erste User seine Tranaction abgeschlossen
kann der zweite in Ruhe sein Statement abfeuern.

Was meintest Du mit

Zitat:

"Select * from xyz where ... (for Update)"

:?:

Das klingt genau nach dem was ich suche...

vielen Dank
Andi

[Bernhard Geyer]

Du machst ja mit dem zusammengebauten Beispiel ziemlich das was die SQL-Anweisung bedeutet. Das (for Update) kann man bei bestimmten DB's mit angeben, wenn man weis das die Ergebnismenge aktualisiert wird (aber da schaust Du am besten in der SQL-Beschreibung der DB nach).

Das bei deiner "UPDATE Tabelle SET..." die DB nicht meckert ist klar. Woher soll die DB wissen, das Du mit veralteten Daten arbeitest? Das weis sie nur, wenn die Daten durch ein TDataset-Komponente (z.B. TQuery) kommt, welche auch noch die alten Daten kennt (und damit entsprechend eine SQL-Anweisung zusammenstellen kann).

[andy3453]

Jo danke,

die FOR UPDATE Klausel funktioniert scheinbar nur im Zusammenspiel mit Cursorn.
Ich werde mich also jetzt mal durch dieses Thema beißen und weiter berichten :coder:


Grüße
Andi

[ZeroQool007]

Bernhard Geyer, mich würde deine 1.Methode interessieren...kannst du mal plz nen bissl QUellcode posten?!
thx