Sperrstrategie, Access & MS SQL Server
-
Ich bin mit der nachfolgenden beschriebenen Problematik konfrontiert, da ich mich zwar mit SQL aus Seite des Anwendungsprogrammierers auskenne, aber nicht die spezifischen Möglichkeiten von beispielsweise Access kenne, hoffe ich hier auf Hilfe.
Ausgangssituation:
Derzeit exestiert eine Anwendung mit einer Accessdatenbank, die in Zukunft auch den SQL Server (und ggf. Andere) unterstützen soll. Nun gibt es eine Aufgabe in der Anwendung wo die Daten vor Veränderung sowie auch Anlage geschützt werden müssen.Konkret sind es Zeitraumbasierte Daten, und der Idialfall wäre, das man eine Periode sperren kann in der andere Prozesse weder Datensätze anlegen noch verändern können. In der Accesslösung wird derzeit die ganze Tabelle gesperrt.
Wie kann man dieses Problem sowohl unter Access als auch mindestens unter SQL Server am geschicktesten lösen (es kann auch unterschiedlich pro DB sein)? Wichtig ist dabei das die Sperre auch sicher wieder entfernt wird (Sei es nun durch DB-Spezifische Mittel oder falls das nicht geht durch einen Zeitstempel (Die Aufgabe ist selbst in unser größten Datenbank nur im Bereich weniger Minuten am arbeiten).
Hat jemand entweder einen Lösungsansatz, oder eine Hilfreiche Quelle wo ich diesen vielleicht herleiten kann?
cu André
-
Hi,
Mir fallen sporadisch folgende Dinge ein, aber alles nur angedaut und ich weiss nicht wieweit Access da mitspielt.
- Schreiben durch eine Stored Proc, die den Datumsstempel prüft. Im Webbereich werden ja sowieso gerne StoredProcs zum Aktuelisieren von DB-Daten verwendet.
- Trigger, welcher ebenfalls das Datum prüft und ggfs wirft. (Wohl keine Lösung für Access)
- Auf das Rechtesystem auslagern: Die gesamte Tabelle ist read-only via Grants und nur der bearbeitbare Zeitbereich wird durch eine View beschrieben, welche DML-Erlaubnis besitzt. Apps müssen dann die View zum Aktualisieren evrwenden.
-
Zu Access kann ich nichts sagen, aber beim SQL Server sollte es reichen, von 'optimistic Locking' auf 'pessimistic Locking' umzustellen. Der Datensatz wird dann von dem Zeitpunkt an, von dem der Datensatz sich im Editiermodus befindet, bis zum Post() gesperrt. Andere User die in dieser Zeit auf den Datensatz zugreifen sollten eine Fehlermeldung bekommen.
-
Joe_M. schrieb:
Zu Access kann ich nichts sagen, aber beim SQL Server sollte es reichen, von 'optimistic Locking' auf 'pessimistic Locking' umzustellen. Der Datensatz wird dann von dem Zeitpunkt an, von dem der Datensatz sich im Editiermodus befindet, bis zum Post() gesperrt. Andere User die in dieser Zeit auf den Datensatz zugreifen sollten eine Fehlermeldung bekommen.
Da es hier nicht nur um eine Datensatzsperre (Veränderung) sondern auch das Verhindern von Neuanlagen (in einen Zeitraum x) geht, hatte ich diese Variante bereits ausgeschlossen.
-
witte schrieb:
... und ich weiss nicht wieweit Access da mitspielt ...
Das ist auch mein echtes Problem, auch wenn ich bislang nichts mit Datenbankadministratur etc. zu tun hatte, habe ich dennoch gewisse Grunderfahrungen von echten DB-Systemen (wie Oracle, PostgreSQL...).
Das Problem ist auch das die Komponenten über die wir in der Anwendung unsere Access-DB ansprechen demnächst auch austauschen müssen (keine Unterstützung in der nächsten Compilerversion), und ich in den Zuge auch gehofft habe an ein paar Access-Erfahrung zu kommen
cu André
-
hm.
idealerweise würde man vermutlich die applikation so umstellen dass keine solchen locks mehr nötig sind. wie das gehen könnte (bzw. ob überhaupt) kann man natürlich ohne weitere informationen nicht sagen.was SQL-server angeht, so könntest du TRANSACTION ISOLATION LEVEL SERIALIZABLE verwenden. hat allerdings den riesen nachteil dass dadurch sehr viele locks für sehr lange zeit gehalten werden. das können durchaus auch mal ganze table-locks sein, nämlich wenn es für bestimmte abfragen keinen passenden index gibt. z.B. wenn SQL-server einen table-scan machen muss um ein WHERE aufzulösen, dann hält er in level SERIALIZABLE einen table-lock bis zum ende der transaktion. eben um garantieren zu können dass das ergebnis der abfrage die dieses WHERE verwendet sich nicht ändern kann.
schön ist aber was anderes, also sollte man es vermutlich anders lösen.
mit snapshot isolation könnte man es auch machen, allerdings werden dann garkeine locks mehr gehalten, der check findet erst beim COMMIT statt. die transaktion die zuerst committed geht durch, alle anderen schlagen dann beim COMMIT fehl. (vorausgesetzt die erste transaktion hat etwas verändert was die spätere transaktion "gesehen hat bzw. gesehen hätte").
----
was du mit access machen sollst weiss ich nicht. access ist als multi-user DB IMO sowieso ein krampf. was dir jetzt aber natürlich auch nicht weiter hilft
-
Ich kann hustbaer nur zustimmen.
SChauen das man nichts sperren muss.
Es gibt noch die Möglichkeit über Trigger und spezielle Tabellen zu arbeiten.
Aber das ist alles ziemlich .... naja.
-
hustbaer schrieb:
idealerweise würde man vermutlich die applikation so umstellen dass keine solchen locks mehr nötig sind. wie das gehen könnte (bzw. ob überhaupt) kann man natürlich ohne weitere informationen nicht sagen.
Der betreffende Bereich kurz beschrieben:
Es gibt Veranstaltungen die einem Zeitraumbereich (z.b. 1.1-30.1) zugeordnet sind, ggf. mit festen Personen/Gruppenzuordnungen und Raumvorgaben. Diese werden irgendwann verplant. Dabei muss sichergestellt sein das sich während der Planung keine Veränderung in dem Zeitbereich ergeben, sonst ist das Planungsergebnis ungültig.Wenn man mir da einen Vorschlag für die Auflösung von Sperren machen kann, wäre ich nicht abgeneigt dies zu erfahren
cu André
-
Solche Dinge muss die Applikation sicherstellen und nicht die Datenbank (wenn man Access mal als Datenbank bezeichnen will).
Locks sollten nur den konkurrierenden Zugriff mehrerer Clients/Sessions auf die DB regeln und keine Businesslogik simulieren.
-
tfa schrieb:
Solche Dinge muss die Applikation sicherstellen und nicht die Datenbank (wenn man Access mal als Datenbank bezeichnen will).
Dann sag mir wie eine Anwendung dies Sicherstellen soll, wenn jemand anderes Daten verändert die ein Ergebnis des Ablaufes beeinflussen (Bereits jetzt eine Mehrbenutzerumgebung. Okay, ich hätte es eindeutiger sagen können als "...in der andere Prozesse weder Datensätze anlegen noch verändern können").
tfa schrieb:
Locks sollten nur den konkurrierenden Zugriff mehrerer Clients/Sessions auf die DB regeln und keine Businesslogik simulieren.
Genau das (Zugriff mehrerer Clients/Sessions) liegt hier vor.
cu André
-
asc schrieb:
tfa schrieb:
Solche Dinge muss die Applikation sicherstellen und nicht die Datenbank (wenn man Access mal als Datenbank bezeichnen will).
Dann sag mir wie eine Anwendung dies Sicherstellen soll, wenn jemand anderes Daten verändert die ein Ergebnis des Ablaufes beeinflussen (Bereits jetzt eine Mehrbenutzerumgebung. Okay, ich hätte es eindeutiger sagen können als "...in der andere Prozesse weder Datensätze anlegen noch verändern können").
Im Idealfall hat nur die Anwendung (als Application-Server einer 3-Schicht-Architektur) Zugriff auf die Datenbank und nicht jemand anders. Die Server-Applikation regelt dann welcher Client wann welche Daten bearbeiten kann. Ob sie jetzt eine Liste im Speicher hält oder in der DB persistiert ist erstmal völlig egal. Nur ist wichtig, dass die Client nicht direkt und unkontrolliert in die DB schreiben.
Wie lang ist denn der "Zeitaum x", zu dem bestimmte Datensätze gesperrt sein müssen? Ein paar Minuten während sie bearbeitet werden oder ein paar Tage? Ich hab das glaub ich noch nicht richtig verstanden. Echte DB-Locks sollten idealerweise nur ein paar Millisekunden oder Sekunden dauern, sofern sie nötig sind.
-
tfa schrieb:
Im Idealfall hat nur die Anwendung (als Application-Server einer 3-Schicht-Architektur) Zugriff auf die Datenbank und nicht jemand anders.
Es geht um eine Anwendung im recht kleinen Maßstab, für die ein Application Server nicht angebracht ist (Das Programm wird vorwiegend auf Einzelplatz oder kleinen Benutzergruppen von derzeit maximal 10 Benutzern [üblich eher 2-4] verwendet).
Nachtrag:
Es wäre jedenfalls für viele Kunden nicht verständlich wenn wir dort noch weitere Anforderungen Stellen. Das Programm wird zudem vorwiegend eher von Computerunerfahrenden verwendet, so das es derzeit aus genau zwei Dateien (einer exe und derzeit noch Accessdatenbank) besteht, und möglichst geringe Anforderungen an die Computerkenntnisse der Einzelnen legt.tfa schrieb:
Wie lang ist denn der "Zeitaum x", zu dem bestimmte Datensätze gesperrt sein müssen? Ein paar Minuten während sie bearbeitet werden oder ein paar Tage?
Im Extremfall wenige Minuten (eher noch etwas drunter), und das auch nur bei unseren Kunden mit der größten Accessdatenbank (unter SQL-Server dürfte sich die Zeitspanne nochmal weiter zusammenstreichen)
tfa schrieb:
Echte DB-Locks sollten idealerweise nur ein paar Millisekunden oder Sekunden dauern, sofern sie nötig sind.
Wir hoffen auch das SQL Server schneller als Access ist ;)... Aber er ist noch nicht im Einsatz (bzw. ich bin derzeit daran die Anwendung für verschiedene Datenbanken fit zu machen [hier fehlte vorher eine sinnvolle Trennung] und kann erste Versuche wohl Anfang/Mitte nächster Woche durchführen).
cu André
