Multiuser Anwendung - MS SQL

Hallo,

ich habe eine C# Anwendung, die auf Daten einer MS SQL Datenbank zugreift.
Folgendes möchte ich implementieren. Und zwar soll der Zugang für 4 User ermöglicht werden (wird über das AD geschehen). Wenn nun ein User auf einen Datensatz zugreift und dieser bearbeitet wird, sollen andere User nur Lesezugriff darauf erhalten.

Wie kann ich das relativ einfach realisieren ?

Google mal nach Optimistic Locking. Das ist wahrscheinlich das, was Du willst.
Je nachdem wie breit die Anwendung wird (wie viel Clients, wie viel Server..) lohnt sich das ganze auch mit einem zwischengeschalteten Service.

Heutzutage lässt man Clients normalerweise nicht mehr direkt auf eine Datenbank.

Pessimistic Locking ist das eher.

Optimistic Locking ist was MS eigentlich betreibt, also alle lesen lassen, und vor dem schreiben erkennen wenn jemand die Daten geändert hat.

Das Pessimistische Locking lässt sich ohne Service nur sehr schwierig richtig implementieren.

Das Pessimistische Locking lässt sich ohne Service nur sehr schwierig richtig implementieren.

...naja. Sooo schwer ist das nun auch nicht, zumindest wenn man "den Ball flachhält" 8)
Wir tun das hier ungefähr wie folgt: Der Zugriff auf einen Datensatz erfolgt nicht über die Tabelle selbst, sondern über eine Stored Procedure, die beim Zugriff zwei (zusätzliche) Felder in der Tabelle bearbeitet bzw. auswertet. Das eine beinhaltet ggf. den Client, der den Datensatz gerade bearbeitet (also "das LOCK besitzt"), das andere den Zeitpunkt, bis zu dem die Sperre (noch) gültig ist.
Wenn ein Client "als erster" zugreift, werden die beiden Felder aktualisiert und er bekommt in einer weiteren (berechneten) Spalte im Ergebnis mitgeteilt, dass der Datensatz schreibbar ist.
Kommt nun ein zweiter Client, so wird dies an den beiden Spalten erkannt, und der Client kriegt über die berechnete Spalte mitgeteilt, dass der Datensatz Read-Only ist.

Zu beachten sind dann noch die folgenden Punkte:
a) Wenn ein Client das Lock für einen längeren Zeitraum braucht, muss ggf. das Timeout aktualisiert werden
b) Das normale Aufheben der Sperre muss sauber implementiert werden (z.B. beim Speichern), damit die anderen Clients nicht unnötig lange auf das Timeout warten müssen.
c) Die Dauer des Timeouts sollte sinnvoll gewählt werden
d) Die Logik der Stored Procedure muss natürlich auch mit ggf. abgelaufenen Timeouts umgehen können.
e) Das ganze ist natürlich auf einer gewissen Kooperation aufgebaut - d.h. wenn ein Client irgendwie anders zugreift oder das Read-Only Flag nicht beachtet, greift das natürlich nicht.

Gibt sicher noch ein paar Haken und Ösen bei dem Vorgehen, bei uns klappt das aber recht gut - wobei ich anmerken muss, dass unsere Clients keine Benutzer im eigentlichen Sinn sind, sondern Hintergrundprozesse, die ggf. auch mal warten können 😁

Bart Simpson