|
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 21:07 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-2025 by Thomas Breitkreuz