Mehrbenutzerzugriff mit ADO und MSSQL

[Peter Geyer]

Hallo,

ich soll in unserer Firma ein kleines Verwaltungsprog schreiben das Multiuser fähig ist.
Eigentlich dachte ich, das das nicht soo schwer sein kann, aber weit gefehlt. Ich komme seit einer Woche irgendwie nicht weiter.
Entweder ist es so einfach, das niemand drüber spricht, oder ich bin zu doof
Ich habe halb Google auswendig gelernt, aber irgendwie war nicht das richtige dabei.
Ich hoffe bei Euch gibt es Leute die sowas schonmal gemacht haben.

Also, ich schreibe erstmal was ich bereits verwende und was ich schon alles Versucht habe.

Ich möchte per Delphi ADO Komponenten auf einen MSSQL2000 Server zugreifen.
Dazu verwende ich TADOConnection und TADOQuerry.
Ich habe schon oft gelesen man solle die BetterADO verwenden, allerdings ist der Download nicht zu erreichen.
Es sollte ja auch mit den eigenen Komponenten klappen.

Ich habe folgendes bereits gemacht:
Der user sieht ein DBGrid dessen Inhalt über ein Querry gefüllt wird. Nun soll man einen Datensatz doppelklicken und ein
Detailfenster erscheint wo nun die Änderungen gemacht werden können. Mit OK wird das Fenster geschlossen und die Daten geschrieben. Die Prozedur mit der ich die Daten schreiben sieht folgendermaßen aus:

Delphi-Quellcode:

procedure Datenupdaten;
begin
  
  Form1.ADOConnection1.BeginTrans;
  try
  With Form1.Artikel do
    Begin
    SQL.Text:='UPDATE Artikel SET 
                      ArtNr=:_ArtNr,
                      ArtName=:_ArtName
               WHERE  ID=:_ID'; 

    Prepared := True;
    With Parameters Do
    Begin
      ParamByName('_ArtNr).Value := Form_Arikel.Edit1.Text
      ParamByName('_ArtName).Value := Form_Artikel.Edit2.Text;
    End;
    Form1.QKunde.ExecSQL;
    end;
    Form1.ADOConnection1.CommitTrans;
  except
    on E: Exception do Form1.ADOConnection1.RollbackTrans;
  end;
  Form_Arikel.Close;
end;

Das ganze klappt ja eigentlich schon ganz gut nur bekomme ich das Problem nicht in den Griff, das
zwei User die Detailmaske eines Artikels aufmachen,
-User1 Kaffee trinken geht
-User2 etwas ändert und speichert
-User1 zurückkommt und seine eigenen Änderungen speichert bzw. einfach nur OK drückt und die alten daten zurückschreibt.
Damit sind dann die Änderungen von 2 einfach weg.

Es ist übrigens ausdrücklich gewünscht, das alle User den selben Datensatz lesen können, aber nur der "erste" ihn auch ändern und speichern kann. Die anderen sollen halt dann nur "schnell was nachschauen" dürfen. Ich hoffe Ihr wisst was ich meine.

Überall im Netz finde ich Bruchstückhafte Anweisungen wie das zu lösen sei. Konkrete Codeschnipsel sind allerdings immer Fehlanzeige. Auch die OH von delphi und MSSQL geben nur wenig Aufschluß.

Die Möglichkeit der Sperrtabelle finde ich recht unelegant, da muss der Zeitstempel ein Verfallsdatum haben damit nach einem Absturz der Datensatz nicht ewig gesperrt bleibt und so weiter...

Ich habe auch schon etwas von SELECT ... FOR UPDATE gelesen, nur scheint das nur mit MySQL zu laufen.
Bei MSSQL gibt es einen Fehler der besagt das es nur in Verbindung mit CURSOR möglich sei. - Hmmpf.

An anderer Stelle wurde gesagt das das innerhalb der UPDATE Klausel geht, etwa so:

SQL-Code:

UPDATE Tabelle
SET    SpalteA = 1, 
       SpalteB = 2
WHERE  SpalteA = 'Alte Daten von A' 
AND    SpalteB = 'Alte Daten von B'

So würde nur ein Update geschehen wenn sich die Daten in der Zwischenzeit nicht geändert hätten, und eine Exeption ausgelöst sofern die Daten nicht eingefügt wurden. Ich weiss nur nicht wie das gehen soll

Ich bin total verzweifelt, weil ich nirgendwo mal ein echtes stückchen Code, oder Anleitung finden konnte, die ich hätte adaptieren können.

Bin ich denn der einzige Mensch der dieses Problem hat? Es gibt doch tausende von Multiuser Anwendungen die genau so funktionieren.

Ich würde mich riesig freuen, wenn jemand mir da weiterhelfen könnte. Oder mir auch sagen, das ich so wie ich das vorhabe, auf dem Holzweg bin.

Wenn keiner ein Stück Code hat, gibt es vieleicht gute Bücher die das Problem konkret beschreiben? Ich habe hier schon einen Stapel, aber die sprechen mit Vorliebe über Interbase...

Bitte, bitte, bitte, ich brauche eine


in diesem Sinne

grüße Peter


*schleim*

[Bernhard Geyer]

Hallo Namenskollege,

vieleicht bringt dir ja der Beitrag Wie richtig mit Transaktionen und ADO umgehen? auf ein paar gute Ideen.

[neolithos]

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.

Wichtig ist das du dabei Transaktionen verwendest, damit bei einem Rechner/Programm-Abstürz nicht der DS für immer gesperrt bleibt.


[EDIT/WICHTIG] Herzlich Willkommen in der DP

[Peter Geyer]

@ Bernhard

Hallo, das ist ja witzig
Soo häufig ist der Nachname jetzt ja nun auch nicht. Aber ich komme aus Kiel, bei Dir hört sich das eher nach Süden an...

Ja, Hmmm, ich hab den Beitrag schon gelesen, nur irgendwie hatte der mich auch nicht so richtig weitergebracht.
Denn die endgültige Lösung gibt´s dort auch nicht.

@neo

ich oute mich auch gerne als >Dummer Sack<, aber ich hab nicht wirklich viel verstanden von dem was Du geschrieben hast.

Ausser natürlich

Zitat:

Herzlich Willkommen in der DP

Dankeschön

Wie mach ich denn nu weiter?
Soll ich meinen Code verbrennen, oder kann ich damit noch was reißen?

danke und Grüße

Peter

[Jelly]

Hallo Peter,

google doch mal nach pessimistic lock mssql...

Gruß,
Tom

[Bernhard Geyer]

Zitat von Peter Geyer:

Hallo, das ist ja witzig
Soo häufig ist der Nachname jetzt ja nun auch nicht. Aber ich komme aus Kiel, bei Dir hört sich das eher nach Süden an...

Stimmt, H'aurach liegt ein paar Kilometer nördlich von Nürnberg

Zitat von Peter Geyer:

Ja, Hmmm, ich hab den Beitrag schon gelesen, nur irgendwie hatte der mich auch nicht so richtig weitergebracht.
Denn die endgültige Lösung gibt´s dort auch nicht.

Aber Ansätze wie man das Problem lösen könnte.

[neolithos]

Erstmal enttschuldigung, war kurz vorher bei der DB-Vorlesung an der Hochschule.

Zitat von neolithos:

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.

Attribut = Spalte, Feld
Entität = Tabelle

Mit Logisch Sperren meine ich du setzt einfach einen Wert für, ist gerade in Bearbeitung!

Ich hoffe das ist jetzt klarer.

[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)

[Robert_G]

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. )

[Peter Geyer]

Moin, danke erstmal für die vielen Vorschläge,

Zitat von Bernhard Geyer:

Aber Ansätze wie man das Problem lösen könnte.

Ja, Ansätze. Aber nicht so viel darüber hinaus. Ich meine das jetzt nicht böse (wie auch )
aber wenn ich fragen würde wie ich in ein Edit etwas reinschreibe würde als Antwort kommen:
Edit1.text:='Herr Bert'; Klar das ist ja auch einfach


Es will einfach nicht in meinen Kopf das, Delphi, ADO und MMSQL für dieses
"wirklich seltene und fast nie vorkommende" Problem keine Lösung in der Tasche hat.

@Robert

Danke für die wirklich schöne Sesamstraßen Episode Genau von dem beschriebenen Problem habe ich gesprochen. 8)

Zitat von Robert_G:

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. )

könntest Du das nochmal genau erklären? Ich fürchte nämlich das die Kommunikation zwischen den Sessions wirklich ein Krampf werden.
Die
SELECT ... FOR UPDATE ist irgendwie anders bei MSSQL gelöst. Wenn ich so ein Statement schreibe kommt als Fehlermeldung, das
die FOR..UPDATE Clausel nur in Verbindung mit Declare Cursor erlaubt ist.

Kennt jemand die genaue Verwendung der FOR UPDATE bei MSSQL


danke an alle

Peter