Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VBA ADO Datensatz sperren im Multi-User-Betrieb, Access 2000

256 views
Skip to first unread message

Raimund Gryszik

unread,
May 27, 2009, 7:10:01 AM5/27/09
to
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. 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.

Mark Doerbandt

unread,
May 27, 2009, 7:27:12 AM5/27/09
to
Hallo, Raimund,

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.

Peter Doering

unread,
May 27, 2009, 7:44:48 AM5/27/09
to
Hallo,

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

Jörg Ackermann

unread,
May 27, 2009, 8:36:52 AM5/27/09
to
Hallo Raimund,

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

Jörg Ackermann

unread,
May 27, 2009, 9:07:52 AM5/27/09
to
Hi,

> 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�

0 new messages