SQL Server Express 2005 / Mehrplatzumgebung / Access

[singasong]

Hallo zusammen,

ich habe einen SQL-Server-2005-Express auf einem Server (Win 2003) eingerichtet und mit dem Migrationstool von ms eine MDB-Datei als Datenbank übernommen. Mehrere Benutzer greifen mit einer Access-ADP auf die Datenbank zu. Hat soweit alle gut funktioniert. Zugriff erfolgt mit Windows Autentifizierung.

Beim konkurrierenden Zugriff (mehrere user greifen auf den selben Datensatz editierend zu) wird allerdings nur die übliche Access-Fehlermeldung ausgegeben ("in die Zwischenablge", "eigene Änderungen verwerfen" und so weiter), der Datensatz wird nicht gesperrt. Das ist in der adp-Variante genauso wie in der mdb-Variante (also über ODBC-Verknüpfung).

Muss ich für die Datenbank noch irgendwas eingestellen, dass der bearbeitete Datensatz gesperrt wird?

Ich weiss, klingt simpel, habe aber nichts gefunden.

Danke
T.

[hwoess]

Was willst du damit erreichen? Der SQL-Server sperrt den Datensatz während des Schreibvorganges und macht ein AutoCommit (in der Standardeinstellung). Wenn jemand zu lange an einem Datensatz herumarbeitet und jemand anderer ist schneller, kommt eben eine Fehlermeldung, dass sich der Datensatz inzwischen geändert hat. Ist okay so, finde ich (und hat in meinen mittlerweile fast 15 Jahren arbeiten mit Datenbanken noch nie ein Problem gemacht).

bye,
Helmut

[singasong]

danke für die Antwort.

Das Problem (das selbst mit Access-mdb-Datenbankdateien mit einer einfachen Einstellung über die weiteren Optionen gelöst werden kann) besteht eben darin, dass ein user einen Hinweis bzw. ein Sperrkennzeichen erhalten soll, wenn sich ein Datensatz in der Bearbeitung befindet. Eine Editierung soll während eines Editiervorganges eines anderen users gesperrt werden (eine wohl übliche Datenbankanforderung, wie ich meine)

Gruß
T.

[Bernhard Geyer]

Eine Desktopdatenbank kannst du schlecht mit einem richtigen SQL-Server vergleichen. Das was Access mehr oder minder stabil mittels Sperrdatei anbietet kann man so nicht auf eine SQL Datenbank mit u.U. mehreren 1000 gleichzeitigen Benutzern skalieren. So wie Access bei zu viel gleichzeitigen Benutzern schon mal seine Datenbank zerschießt wurde so ein Standardmechanismus bei einer richtigen SQL Server Datenbank ein Performancegrab darstellen.

Jedes DBMS bietet aber Mechanismen an um sowas doch noch zu ermöglichen. Entweder über entsprechende Abfragen (SELECT *... FOR UPDATE), Notificationservices (beim MS SQL Server) oder anderen Lösungen wie einer 3-Tier-Architektur.

[Andreas Kosch]

Hallo,

...eine wohl übliche Datenbankanforderung, wie ich meine...

Nicht unbedingt ;-)

Der Grund, warum ACCESS zu pessimistischen Datensatzsperren gegriffen hat lag doch darin, dass die Microsoft JET Engine auf jedem einzelnen Benutzerrechner ausgeführt wurde und alle diese JET-Instanzen auf die gleiche Netzwerkdatei zugegriffen haben. Bei einer datensatzorientierten Desktopdatenbank waren die Sperren somit ein "notwendiges Übel" (d.h. im Datensatz gab es ein spezielles Feld, indem ein Flag abgelegt wurde, wenn eine JET-Instanz den Datensatz gesperrt hat).

Im Gegensatz dazu arbeitet eine SQL-Datenbank mengenorientiert, wobei nur ein auf dem Server ausgeführter Prozess auf die physische Datenbankdatei zugreift. Aus diesem Grund können SQL-Datenbanken mit den optimistischen Sperren arbeiten.

Wenn ein Benutzer einen bestimmten Datensatz reservieren will, muss er das über seine Transaktion festlegen, indem der Sperrhinweis UPDLOCK übergeben wird:

SELECT a,b,c FROM Tabelle WITH (UPDLOCK)

Der Sperrhinweis UPDLOCK garantiert, dass kein anderer Benutzer (Datenbanksitzung) diesen Datensatz während der Zeitdauer der eigenen Transaktion beschreiben kann, so dass der Anwender seine Bearbeitung in jedem Fall erfolgreich abschließen kann. Allerdings haben lange Transaktionszeiten (deren Zeitdauer vom Anwender kontrolliert werden) erhebliche Nebenwirkungen, so dass man sich diese Geschichte sehr gut überlegen sollte ;-)

[singasong]

Vielen Dank für die umfassende und kompetente Antwort!!
Gruß