Zitat von
Generalissimo:
Da muss man nicht erst in einer Tabelle was setzten.
Du musst die jenige Transaktionseistellung wählen die jedem Leserechte gibt, aber nur dem jenigen, der als erster zugreift auch Schreibrechte genehmigt. Leider hab ich keine Ahnung wie das bei
ADO hies. LockOptimistic oder so.
Beim Interbase heisst die Einstellung Snapshot Table Stability (Nur-Lesen Tabellenstabilität)
Sorry, aber das war Käse.
Die Problematik ist ja eigentlich folgende:
Ernie & Bert arbeiten beide am gleichen Projekt.
Dabei halten sie sich aber meistens an verschiedenen "Ecken" der dazugehörigen Tabellen auf.
Ab & zu gibt's mächtig Zank weil Bert schon wieder Ernies Arbeit überschrieben hat ohne es zu bemerken.
Jetzt kommt Samson und baut das ein, was Generalissimo vorgeschlagen hat.
Die Folge ist, dass
ENTWEDER Ernie
ODER Bert arbeiten können.
Daraufhin wurden dann beide ziemlich stinkig.
Kurz und knapp: Dieses extreme Sperren der Tabellen ist in der Praxis alles andere als benutzerfreundlich.
Zitat von
Neo:
Man könnte ja auch ein weiteres Attribut in die Entität einfügen, in dem du einen Wert setzt in dem du den Datensatz logisch sperrst.
Wenn ich das richtig verstanden habe,
, mag ich es auch nicht.
Mitagspause ist zu Ende.
Ernie öffnet die Tabelle um 14:00. Bert hat sich schon 13:45 vollgefressen unter seinen Schreibtisch gequetscht.
Um 14:01 speichert Bert.
Was nun?
Ich mache es mir dabei ziemlich einfach.
In Oracle gibt es eine Pseudospalte namens RowID, die ist IMMER eindeutig (sie beschreibt schließlich die physische Position des DS auf der Fäschtpladde).
Desweiteren können sich Sessions auf 2 Arten miteinander "unterhalten":
- Pipes - so etwas wie eine Rohrpost. Die Nachrichten werden in Echtzeit versendet und empfangen.
- Alert flags - diese Nachrichten werden erst bei einem Commit an alle registrierten Sessions verschickt.
Genau die brauchen wir. (Das ist der Moment, in dem du das Gegenstück dazu für den SQL Svr suchen musst 
)
Beim Öffnen der Tabelle hat sich Ernies Session für ein Alert flag namens "Sesam Straße" registriert.
An der Tabelle sitzt ein before-Update Trigger, der für jeden geänderten Eintrag ein Flag mit der RowID verchickt.
Als Berts Session jetzt ein Commit absetzt bekommt Ernie mit, dass sich 3 Einträge geändert haben.
Diese 3 Einträge kann man jetzt abfragen und mit der derzeitigen Ansicht synchronisieren. (unter .Net ist das ein 3-Zeiler, unter Delphi32 wird's ein Krampf
).
Bei Überschneidungen kann Ernie jetzt PRO Eintrag gefragt werden, ob er seine lokalen Änderungen verwerfen, oder lieber Berts Eintrag überschreiben will.
So, mein Oraclekrempel ist gerade fertig geworden (in der Langeweile wurde aus dem Post glatt 'ne Episode Sesam straße
)
OT:
Das ist ein schreibfähiger Cursor in Oracle
SELECT ... FOR UPDATE
Interessant wird es mit der Erweiterung...
SELECT ... FOR UPDATE NOWAIT
Dann springt er dir in dem befürchteten Fall sofort ins Gesicht. (Aber ohne die fancy Möglichkeiten die eine Kommunikation zwischen den Sessions ermöglicht.
)