Sperrstrategie, Access & MS SQL Server

[Gast]

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.

[asc]

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.

[asc]

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é

[hustbaer]

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

[Unix-Tom]

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.

[asc]

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é

[tfa]

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.

[asc]

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é

[tfa]

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.

[asc]

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é