Wir möchten einzelne Datensätze einer Tabelle exklusiv für einzelne Benutzer
sperren. D.h. sobald ein Benutzer den Datensatz öffnet, sollen
Öffnungsversuche anderer Benutzer abgewiesen werden. Solange, bis der erste
den Datensatz wieder schließt. Folgender Versuch schlug fehl:
Dim Conn As New ADODB.Connection
Dim ARS As New ADODB.Recordset
Conn.CursorLocation = adUseClient
Conn.Open "PROVIDER=Microsoft.Jet.OLEDB.4.0;" & _
"DATA SOURCE=N:\Test\Testdatenbank.mdb"
ARS.CursorLocation = adUseClient
ARS.Filter = "ID = eindeutig" ' es wird nur ein DS gefunden
ARS.Open "SPERRTABELLE", Conn, adOpenKeyset, adLockPessimistic
PAUSE
An dieser Stelle soll das Programm anhalten, der DS ist geöffnet. Wenn ein
anderer Benutzer nun den selben DS mit dem selben Coding öffnet, bekommt er
keine Fehlermeldung! Auch können beide User in den DS schreiben, der letzte
gewinnt!
Die Testdatenbank ist übrigens identisch mit
Application.Currentproject.Connection, denn die Sperrtabelle ist da natürlich
drin (verlinkt auf eine Backend-mdb). Liegt hier vielleicht das Problem
irgendwo ??
Vielen Dank für Tipps
Raimund Gryszik, Berlin
PS: Wenn das mit ADO nicht geht, geht's vielleicht irgendwie mit SQL? Beim
Lesen des Threads von Zwillsperger/Habermacher vom 31.1.2007 wird mir
schwindlig. Geht es auch kürzer? Auf jeden Fall können wir kein
Bildschirmformular für diese Tabelle gebrauchen, denn die Sperren haben einen
anderen Zweck, nämliche zentrale/eindeutige Nummernvergabe/Themensperrung.
In anderen Threads ist öfter die Rede von Timestamp-Feldern, die man
hinzufügen soll und die das Problem lösen. Habe ich in Access 2000 nicht
gefunden, was ist das?
Bitte keine Hinweise auf Deadlocksituationen durch Zombiesperren, denn das
Problem ist bekannt. Auch ein Umstieg auf andere DB-Maschinen kommt bei uns
wegen zentraler Groß-DV nicht in Frage.
Raimund Gryszik:
> Auf jeden Fall k�nnen wir kein Bildschirmformular f�r diese Tabelle gebrauchen,
> denn die Sperren haben einen anderen Zweck,
> n�mliche zentrale/eindeutige Nummernvergabe/Themensperrung.
ok, ich beziehe mich mal darauf. Ich halte Deinen Ansatz f�r
fragw�rdig. Wenn ich eine eindeutige (ggf. auch fortlaufende)
Nummernvergabe erreichen will, erzeuge ich mir z.B. eine GUID (wird
nicht weiter verwendet, dient nur zur eindeutigen Kennzeichnung der
Session beim Speichern) und versuche diese in eine zentrale Tabelle zu
speichern, zusammen mit der n�chsten Nummer (auf dieser liegt
nat�rlich ein Unique Index). Gelingt mir das, kann ich es �ber die
Pr�fung der GUID best�tigen, wenn nicht: neuer Versuch. Kommt ohne
Sperrungen nur mit Logik aus.
Gruss - Mark
--
Informationen fuer Neulinge in den Access-Newsgroups unter
http://www.doerbandt.de/Access/Newbie.htm
Bitte keine eMails auf Newsgroup-Beitr�ge senden.
Raimund Gryszik wrote:
> In anderen Threads ist �fter die Rede von Timestamp-Feldern, die man
> hinzuf�gen soll und die das Problem l�sen. Habe ich in Access 2000 nicht
> gefunden, was ist das?
Das hat mit Jet nichts zu tun. Der Feldtyp Timestamp bezieht sich auf SQL
Server und Hintergrund ist, dass bei vorhandenem Timestamp der ODBC-Treiber
an selbigem erkennen kann, ob der Datensatz seit dem Zugriff geaendert
worden ist. Er muss also nicht alle Felder pruefen, was schnell zu
Performancproblemen fuehren kann. Innerhalb Access wuerdest du den Feldtyp
nur in mit SQL-Server verknuepften Tabellen sehen.
Gruss - Peter
--
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
Raimund Gryszik meinte:
> Hallo Profis!
>
> Wir möchten einzelne Datensätze einer Tabelle exklusiv für einzelne
> Benutzer sperren. D.h. sobald ein Benutzer den Datensatz öffnet,
> sollen Öffnungsversuche anderer Benutzer abgewiesen werden. Solange,
> bis der erste den Datensatz wieder schließt.
Du könntest folgendes tun:
Dim Conn As New ADODB.Connection
Dim ARS As New ADODB.Recordset
Conn.CursorLocation = adUseServer
Conn.Open "PROVIDER=Microsoft.Jet.OLEDB.4.0;" & _
"DATA SOURCE=N:\Test\Testdatenbank.mdb"
ARS.CursorLocation = adUseServer
ARS.Filter = "ID = eindeutig" ' es wird nur ein DS gefunden
ARS.Open "SPERRTABELLE", Conn, adOpenKeyset, adLockPessimistic
ARS.Sperrfeld=1
STOP
Prinzip:
Du verwendest als CursorLocation adUseServer
Du fügst der Tabelle ein Feld hinzu, das nur dazu dient, einen
Wert zu ändern, um die Sperre zu erzeugen.
Sobald ein zweiter Benutzer
ARS.Sperrfeld=1
ausführt, bekommt er einen Fehler.
Gruß Acki
> Du k�nntest folgendes tun:
Praktisch zum Testen zB so:
Option Compare Database
Dim Conn As ADODB.Connection
Dim ARS As ADODB.Recordset
Function Test_Start()
On Error GoTo err_fct
Set Conn = New ADODB.Connection
Set ARS = New ADODB.Recordset
Conn.CursorLocation = adUseServer
Conn.Open "PROVIDER=Microsoft.Jet.OLEDB.4.0;" & _
"DATA SOURCE=N:\test.mdb"
ARS.CursorLocation = adUseServer
ARS.Filter = "ID = 1"
ARS.Open "TABELLE", Conn, adOpenKeyset, adLockPessimistic
ARS.Fields("Ftext") = "Test"
exit_fct:
Exit Function
err_fct:
MsgBox Err.Description
Resume exit_fct
End Function
Function Test_Ende()
Set ARS = Nothing
Set Conn = Nothing
End Function
Gru�