|
Mehrbenutzerzugriff mit ADO und MSSQL
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 :wall: 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:
Das ganze klappt ja eigentlich schon ganz gut nur bekomme ich das Problem nicht in den Griff, das
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; 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
SQL-Code:
gelesen, nur scheint das nur mit MySQL zu laufen.
SELECT ... FOR UPDATE
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:
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 :cry:
UPDATE Tabelle
SET SpalteA = 1, SpalteB = 2 WHERE SpalteA = 'Alte Daten von A' AND SpalteB = 'Alte Daten von B' 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 :idea: in diesem Sinne grüße Peter :dp: :dp: *schleim* :zwinker: |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
Hallo Namenskollege,
vieleicht bringt dir ja der Beitrag  Wie richtig mit Transaktionen und ADO umgehen? auf ein paar gute Ideen. |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
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 |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
@ Bernhard
Hallo, das ist ja witzig :-D 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 :wiejetzt: 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:
Wie mach ich denn nu weiter? Soll ich meinen Code verbrennen, oder kann ich damit noch was reißen? danke und Grüße Peter |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
|
Re: Mehrbenutzerzugriff mit ADO und MSSQL
Zitat:
Zitat:
|
Re: Mehrbenutzerzugriff mit ADO und MSSQL
Erstmal enttschuldigung, war kurz vorher bei der DB-Vorlesung an der Hochschule.
Zitat:
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. |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
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) |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
Zitat:
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. :arrow: Daraufhin wurden dann beide ziemlich stinkig. :mrgreen: Kurz und knapp: Dieses extreme Sperren der Tabellen ist in der Praxis alles andere als benutzerfreundlich. Zitat:
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":
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 :lol: ) OT: Das ist ein schreibfähiger Cursor in Oracle :mrgreen:
SQL-Code:
Interessant wird es mit der Erweiterung...
SELECT ... FOR UPDATE
SQL-Code:
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. ;) )
SELECT ... FOR UPDATE NOWAIT
|
Re: Mehrbenutzerzugriff mit ADO und MSSQL
Moin, danke erstmal für die vielen Vorschläge,
Zitat:
aber wenn ich fragen würde wie ich in ein Edit etwas reinschreibe würde als Antwort kommen:
Delphi-Quellcode:
Klar das ist ja auch einfach :roteyes:
Edit1.text:='Herr Bert';
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. :twisted: @Robert Danke für die wirklich schöne Sesamstraßen Episode :thuimb: Genau von dem beschriebenen Problem habe ich gesprochen. 8) Zitat:
Die
SQL-Code:
ist irgendwie anders bei MSSQL gelöst. Wenn ich so ein Statement schreibe kommt als Fehlermeldung, das
SELECT ... FOR UPDATE
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 |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
@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 :freak: |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
Zitat:
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. |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
Zitat:
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:
Zitat:
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:
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) |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
Zitat:
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, ...). |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
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 |
Re: Mehrbenutzerzugriff mit ADO und MSSQL
Zitat:
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) |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 16:40 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz
