Transactionhandling bei Interbase - suche die beste Methode

[grips-net]

Hallo!

Ich habe eine kleine Anwendung, die Interbase als Datenbank nutzt und die im Netz verwendet wird.

Das folgende Problem ist klar:

Zitat:

Benutzer A bearbeitet Satz 11. Er ändert Feld "xxx".
Gleichzeitig bearbeitet Benutzer B den gleichen Satz. Er ändert das Feld "zzz".

Einer der beiden wird nun die Änderungen des jeweils anderen überschreiben. Dies sollte aber verhindert werden. Um dies zu verhindern habe ich die folgenden Möglichkeiten gefunden:

1. Schreibschutzfeld
Jede Tabelle erhält eine neue Spalte "Schreibschutz". Sobald ein Nutzer in den Edit-Moduls wechselt, wird dieses Feld mit einem bestimmten Wert gefüllt. Dies verhindert, dass ein weiterer Benutzer diesen gerade gesperrten Satz ebenfalls bearbeitet.
Diese Methode hat den Nachteil, dass z.B. bei einem Programmabsturz der Datensatz zunächst gesperrt bleibt. Es müssen hier also gewisse Sicherheitsmechanismen eingebaut werden. So ganz überzeugt mich diese Möglichkeit nicht.

2. Abgleich
Sobald ein Nutzer in den Edit-Modus wechselt, werden die Daten (z.B. in einem Array) lokal zwischengespeichert. Vor dem Speichern (UPDATE) wird der komplette Datensatz neu angefordert und mit den lokalen Daten verglichen. Haben sich in der Zwischenzeit Änderungen ergeben, wird der Benutzer darauf hingewiesen. Er kann nun entscheiden, ob er seine Änderungen verwirft, die Änderungen des anderen Nutzers überschreibt oder sogar die beiden Änderungen kombiniert.
Auch diese Möglichkeit hat wieder gewisse Fallen. Außerdem erfordert Sie einen recht hohen Programmieraufwand

Gibt es vielleicht eine andere - elegantere - Möglichkeit um mein Problem, vor dem sehr viele stehen dürften, möglichst einfach zu lösen? Wie habt ihr das Problem gelöst?

Danke für die Antworten....

[Bernhard Geyer]

Eine ähnliche Diskussion gab es schon (nur mit anderer Datenbank):Wie richtig mit Transaktionen und ADO umgehen?

[grips-net]

Nur zur Information: Habe eine - wie ich finde sinnvolle, konsistente und recht einfache Möglichkeit gefunden:

Sobald ein Benutzer einen Satz bearbeitet SELECT elefant FROM afrika wird eine Transaction gestartet und mit einem Fake-UPDATE nach dem Muster UPDATE afrika SET elefant=elefant WHERE id=:ID belegt.
Nun ist der Datensatz für alle anderen gesperrt. Das richtige Update UPDATE afrika SET elefant=dumbo WHERE id=:ID überschrtibt das Fake-Upadte. Ein Commit beendet die Transaction.

Diese Art der Problemlösung ist für mich konsistent und wohl im Sinne der Interbase-Entwickler.
Leider funktioniert ja bei Interbase das SELECT elefant FROM afrika FOR UPDATE nicht.


Grüße

Michael

P.S.: Danke für den Hinweis Bernhard. Diese Diskussion hatte ich nicht gefunden - wohl die falschen Suchbegriffe. Wirklich geholfen hätte sie auch nicht. Trotzdem Danke.

[Bernhard Geyer]

Diese Lösung ist jedoch sehr Server-Resourcen-Lastig, da ja für jeden bearbeiteten Datensatz eine Transaktion gestartet wird, welche evtl. über mehrer Stunden aktiv ist (Formular öffnen, Anschließend Mittagessen und nach Mittagessen bis 15:00 Uhr Besprechung). Und wenn das jetzt viele User machen ist die Datanbank entsprechend ausgelastet. Transaktionen sollten so kurz wie möglich dauern.

[Albi]

Hallo,

willst Du einfach nur das bearbeiten von einem Datensatz zweier User verhindern? Das regelt doch der Interbase alleine, must es im nur sagen.

Das kannst Du über die Transaktion-Eigenschaften deiner Transaktion einstellen.

[grips-net]

Das Problem ist ganz einfach zu beschreiben:

Es gibt eine Liste mit Einträgen (z.B. Adressen). Diese werden über SELECT * FROM adressen ausgelesen. Nun kann der Benutzer einen Eintrag auswählen und diesen in einer anderen, modalen FORM bearbeiten.

Dazu wird der Satz für diese Form neu angefordert. SELECT * FROM adressen WHERE id=:ID .

Leider gibt es in Interbase kein FOR UPDATE. Zumindest scheint es nicht zu funktionieren.
Denn nun kann ein anderer Benutzer ja den gleichen Satz öffnen.
Beide machen ihre Änderung und speichern ab:

UPDATE adressen SET aenderung="änderung" WHERE id=:ID Entweder überschreibt der, der zuletzt speichert die Änderungen des ersten oder - je nach Einstellung der Transaction - werden die Änderungen des zweiten nicht angenommen. Einer der beiden wird sich ärgern.

Schon beim Abrufen des Satzes für die Änderung muss dem zweiten Benutzer meiner Meinung nach mitgeteilt werden, dass sich der Datensatz gerade in Bearbeitung befindet. Dies mache ich eben durch den Versuch eines Pseudo-UPDATES das fehlschlägt, wenn eine andere Transaction den Datensatz in Bearbeitung hat.

@Bernhard: Inwiefern diese Methode den Server belastet muss ich jetzt testen. Daran hatte ich nicht gedacht. Hoffentlich schafft er es.

@Albi: Kennst du eine weitere Methode? Deine Nachfrage zielt nämlich genau ins Schwarze.


Danke schonmal...

Michael