Mehrbenutzerzugriff mit ADO und MSSQL

[Generalissimo]

@Robert_G: Vielleicht verstehen wir uns falsch, aber gehst du davon aus die ganze Zeit ne Transaktion offen zu halten??
Sprich Ernie fängt an und öffnet ne Transaktion und beendet sie erst Stunden später?? Dies sollte man eh nicht
machen. Transaktionen sollten so kurz wie möglich offen gehalten werden.

Es können doch beide arbeiten. Es werden doch von Ernie nur die Datensätze gesperrt auf die er auch zugreift. Bert kann doch wunderbar die anderen ungelesen Datensätze verändern. So ne Transaktionseinstellung geht doch nicht auf ne ganze Tabelle (was man auch machen kann) sondern nur auch die angeforderten Datensätze. Beider können arbeiten.

Zudem ist das von mir oben genannte ist nicht radikales sperren. Dies wäre wenn der erste alle Rechte hat und der nachfolgende gar kein Zugriff mehr erhält.


Der Käsemann

[Bernhard Geyer]

Zitat von Peter Geyer:

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.

Es gibt halt für diese Problem keine allgemeingültige Lösung. Je nach Anzahl der Benutzer, der Rount-Trip-Delay-Zeit, der Anzahl der Änderungen pro Zeiteinheit, ... ist die eine oder ander Lösung geeigneter.

Selbst habe ich schon mal eine Lösung auf Basis einen "Lockservers" realisiert.
Wird ein Datensatz zum evtl. bearbeiten geöffnet, so wird der Lockserver angefragt. Erhält der User die Erlaubnis den Eintrag zu sperren, so wird der Dialog im Änderungsmodus geöffnet. Jeder weitere User erhält auf seine Anfrage eine vermerk, das der Datensatz schon zum bearbeiten geöffnet ist.

Das Problem mit evtl. abstürzenden Clients ist nicht gegeben, da der Server ein DCOM-Objekt war, und DCOM per "Ping" die existenz der Clients abfrägt und bei nicht mehr erreichen diesen die Sperre zurücknimmt.

Eine Alternative wäre z.B. auch für jede Tabelle eine Zeitstempel-Spalte einzuführen. Damit könnte relativ einfach ohne Serverkomponente vor einem Schreiben gechecket werden, ob sich der Datensatz geändert hat (Der vergleich mit allen Spalten ist problematisch, wenn BLOB/Binary-Felder ins Spiel kommen).

Sperren auf DB-Ebene ist immer Schlecht, da vor allem beim MS-SQL-Server u.U. auch reine Lese-Abfragen gesperrt werden.

[Robert_G]

Zitat von Generalissimo:

@Robert_G: Vielleicht verstehen wir uns falsch, aber gehst du davon aus die ganze Zeit ne Transaktion offen zu halten??

Jupp, wir haben uns falsch verstanden.

Ein Alert flag würde niemals abgeschickt werden, wenn die Transaktion nicht mit einem Commit abgeschlossen wird.

Von Table locking auf record ebene halte ich persönlich nicht viel.
Selbst wenn sich mehrere Sessions mit alert flags oder pipes zuschieben, ist die allgemeine Performance WESENTLICH höher als bei ständiger Prüfung, ob ein Record gesperrt wurde oder nicht.

Nachtrag:

Zitat von Peter Geyer:

Der Käsemann

Sorry, das war absolut nicht böse gemeint.

Zitat von Bernhard:

Sperren auf DB-Ebene ist immer Schlecht, da vor allem beim MS-SQL-Server u.U. auch reine Lese-Abfragen gesperrt werden.

Das sehe ich ganz anders. Ich finde das sämtliche Logik, die in der DB realisiert werden kann, auch genau dorthin gehört.
Dein DCOM- Server klingt verdammt interessant, dürfte aber IMHO für wesentlich mehr Roundtrips sorgen als eine Kommunikation auf DB-Ebene.
Im neuen Entwickler gibt es einen Artikel über eMail-Benachrichtigungen bei betimmten Events auf dem SQL Svr. -> Es _MUSS_ also auch dort eine Möglichkeit zur sessionübergreifenden Kommunikation geben. (MS ist sowieso schon seit langem dabei sämtliche fancy Features von Oracle für ihren Spross zu kopieren. )

Über die Sinnlosigkeit des Sperrens bei einem SELECT habe ich mich, glaube ich, schon in einem anderen Thread ausgelassen.

Nachtrag:
Wenn man sämtliche Logik vom DB-Server auslegern würde, wären Datenbanken wie der SQL Svr, Oracle, Caché oder PosGreSQL (BTW die ist ein genialer Geheimtipp für alle Geizhälse mit dem Anspruch auf eine "richtige" DB) witzlos und wir könnten alle mit "Billigkram" wie mySQL, Paradox, MS Jet und Konsorten arbeiten.

Zitat von Peter Geyer:

Ich fürchte nämlich das die Kommunikation zwischen den Sessions wirklich ein Krampf werden.

Das glaube ich nicht.

Ich weiß nicht wie es bei euch "SQL Svr"'lern implementiert ist. Aber ich denke es ist auch dort möglich sich für eine Art Event/Benachrichtigung oder sonstwas zu registrieren.

Wenn es kein Gegnstück zu Oracle's RowID gibt, musst du fix die PrimKeys der Tabelle in den Trigger schreiben (oder eine SP basteln, die das für dich erledigt ).

Ansonsten hast du dann pro Tabelle einfach einen Trigger der Before Update, Before Insert und Before Delete feuert. Er muss dir jetzt nur den Schlüssel des DS liefern (wenn es keine Gegenstück zur RowID gibt, auch den Tabellennamen). Eine Möglichkeit, wie du im Programm darauf reagieren kannst, habe ich dir weiter oben schon vorgeschlagen.
Das Ganze wird in ein paar Stunden Bastelei und theorie ausarten, aber das Ergebnis wäre eine Chance, dieses Problem elegant, ohne Zusatzserver zu umschiffen. (Bei mir klappt es einwandfrei, sogar bei "bösen" Bulk DML Statements mit 5-stelligen DS-Zahlen)

[Bernhard Geyer]

Zitat von Robert_G:

Das sehe ich ganz anders. Ich finde das sämtliche Logik, die in der DB realisiert werden kann, auch genau dorthin gehört.
Dein DCOM- Server klingt verdammt interessant, dürfte aber IMHO für wesentlich mehr Roundtrips sorgen als eine Kommunikation auf DB-Ebene.
Im neuen Entwickler gibt es einen Artikel über eMail-Benachrichtigungen bei betimmten Events auf dem SQL Svr. -> Es _MUSS_ also auch dort eine Möglichkeit zur sessionübergreifenden Kommunikation geben. (MS ist sowieso schon seit langem dabei sämtliche fancy Features von Oracle für ihren Spross zu kopieren. )

Sicherlich könnte man möglichst viel Logik auf DB-Ebene verlagern. Als ich mein Programm für den MS-SQL-Server entwickelt hatte, war für das Projekt die Version 6.5 relevant. Und dort gibt es sowas wie Ebentbenachrichtigung nicht. Auch waren die Rountrips für das damalige Projekt nicht relevant, das maximal bis zu 20 User in einem Deutschlandweiten Netz darauf zugriffen.
Aktuell bin ich an einem Projekt welches DB-Unabhänig laufen soll (MS-SQl, Oracle, MySQL, ...). Und dort kann man solche Features wie Eventbenachrichtigung nicht einbauen. Man ist schon froh wenn sich die DB's im Standard-SQL nicht zu sehr unterscheiden (Blobs, Sperrverhalten, ...).

[ChristofSch]

Also ich löse das immer so.

1. Neue Transaktion starten
2. Gleichzeitig einen Timer aktivieren, der Timer fängt bei jedem on Change Erreignis von vorne an.
3. Wenn der Timer ausgelöst wird mache ich ein Rollback

Wenn ein User nun zum Mittag geht wird seine Transaktion durch den Timer gecancelt.

2 User können eh nicht am gleichen Datensatz arbeiten.

Gruß
Christof

[taran_seven]

Zitat von Peter Geyer:

Hallo,
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.

Ein Trick wäre: Beim wechseln in den Edit-Modus einen Timer setzen, der regelmäßig automatisch speichert.
Ebenso vor "BeforeEdit" ein Refresh aufrufen um vor dem eintippen des ersten Zeichens die aktuellen Daten zu sehen.


Leider sind die ADO-Datasets sehr fehlerhaft... Der LockTyp=Pessimistic den Du bräuchtest geht nicht, weil er sich immer auf BatchOptimistic stellt. Auch die DBExpress ist mit MS-SQL2000 nicht wirklich glücklich...
Am besteh geht es mit Firebird... nur leider habe ich Merge-Replikation mit Laptops gebraucht und das kann nur MS-SQL wirklich gut. (vor allem ohne großen Programmieraufwand)