Office: (Office 2010) Microsoft Access und seine Mehrbenutzerfähigkeiten in Bezug auf Transaktionen

Hallo zusammen !

ich habe mal eine Frage zu MS Access (diese betrifft eigentlich eine gängigen Versionen von MS Access).

Der MS SQL Server von Micorosft unterstützt ja implizite und explizite Transaktionen, d.h. gerade gelesene Daten oder Datensätze durch einen Benutzer bzw. seine Session werden vor anderen Benutzern verborgen, solange seine Transaktion nciht abgeschlossen, also Commitet oder Rollbacked wurde. Erst dann kann der Benutzer ja die gesperrten daten wieder lesen.

Wie genau ist das denn in der Jet Engine von MS Access geregelt? Gibt es da auch so etwas (eben nur im Kleinformat bzw. für nur eine begrenzte Anzahl von Userns), oder ist das ausschließlich im Microsoft SQL Server möglich?

Danke schön für die Unterstützung !

Grüße
Kossy

:)

 

Hallo Kossy,
durch meine Tests in diesem Thema (Klick) stellte ich fest, dass Access die Datensätze (besser Speicherseite! - Im Test waren die ersten vier DS gesperrt, obwohl nur der erste bearbeitet wurde.) sperrt bis die Transaktion abgeschlossen ist.
Das Verhalten ist aber auch von der gewählten Einstellung zum Sperren von Datensätzen in den Access-Optionen abhängig!

 

Hallo,
@Marsu: Wir hatten ja gestern schon miteinander das Thema Transaktionen in Access.

Ich habe meine Anwendung auf einen Server gesetzt um das Verhalten in einer Mehrplatzumgebung zu testen. Wenn man als 2ter Nutzer einen in einer Transaktion befindenden Datensatz editieren möchte, reagiert Access erst mal gar nicht, eigentlich friert das Form ein. Die Fehlermeldung 3218 erscheint 3-5 Sekunden später und danach reagiert das Form sehr träge, eigentlich so nicht akzeptabel. Man sollte vor dem Zugriff auf einen Datensatz prüfen ob sich dieser in einer Transaktion befindet und dann den Zugriff mit einer vernünftigen Meldung unterbinden. Hast Du Erfahrung wie man prüfen kann, ob sich ein Datensatz in einer Transaktion befindet? Ich habe nichts dazu gefunden….

Gruss, Quint

 

Hast du FE und BE getrennt?
Hat jeder Benutzer sein eigenes FE?
Treten beim Kompilieren Fehler auf?

Wie erfolgt der Zugriff?
An welcher Stelle tritt der Fehler auf? (Debugger)

Wenn beide User im selben FE arbeiten, kann ich mir gut vorstellen, dass es Probleme gibt, da Transaktionen geschachtelt werden können.

 

Hallo,

die Anwendung ist in FE und BE aufgeteilt, jeder Nutzer hat sein eigenes FE. Es treten keinerlei Fehler beim kompilieren auf.

User1 bearbeitet einen Datensatz; die Transaktion wird durch FormDirty gestartet. User2 bearbeitet den selben Datensatz, ebenso wird durch FormDity eine Transaktion gestartet. User2 will seine Änderungen speichern, CommitTrans wird ausgeführt und es kommt zu einer Fehlermeldung 3260, manchmal 3218 ( siehe Bild im Anhang). Vom starten des Edit-Vorgangs bis zur Fehlermeldung vergehen gute 3-5 Sekunden. User1 kann seine Änderungen über CommitTrans ohne Probleme speichern.
User Admin sperrt angeblich den Datensatz. Es gibt keinen user Admin, ich benutze auch keine mdw zur Benutzerverwaltung.

Gruß Quint

Neu: Ich habe gerade nochmals getestet: Die verschiedenen Fehlermeldungen kommen durch Änderung des Sperrverhalten unter Access-Optionen; Sie sagen aber eigentlich das selbe aus!

Grrrr.. Ich habe - glaub ich - das Problem gefunden. Bei Ändern von Feldern führe ich gewisse Prüfroutinen durch. So prüfe ich zum Beispiel nach Änderung des Feldes Menge, ob ein Staffelpreis greift. Hierzu werden rst gebildet, die Werte übergeben. Diese rst greifen u.a. auf die selbe Tabellen wie die angschobene Transaktion zu. Da die Transaktionen von 2 usern ja offen sind werden die neuen rst auch in die bestehenden Transaktionen eingebunden und gesperrt. Deswegen wohl die Fehlermeldung auch bei Datensätze die nur von einem user bearbeitet werden( Bsp. im Bild Pos 1.3) und über die Prüfroutinen beim editieren durch user2(Beispiel Pos 1.5) mit eingebunden sind. Ich habe mal bei einem Feld die Prüfroutine rausgenommen; die Änderungen von user2 konnten über CommitTrans sauber gespeichert werden. Ich glaube die Jet-Engine bekommt ein abarbeiten von verschiedenen Transaktionen nicht hin, oder? Der SQL-Server kann das wohl und es ist mit ihm wohl auch ein Sperren auf Datensatzebene (SELECT FOR UPDATE) möglich.

Es ergeben sich jetzt folgende Fragen:

1. War die Umstellung meiner gesamten Warenwirtschaft umsonst....? Ich dachte, ich hätte endlich das leidige Thema "Datenkontrolle in Ufos" beendet.
2. Ist es möglich innerhalb einer Transaktion rst zu bilden, die nicht in die laufende Transaktion eingebunden werden?
3. Kann Access Transaktionen in einer Art Stapelverarbeizung abarbeiten?

Liebe Grüße vom verzweifelten Quint

 

Benutzt du Transaktionen mit gebundenen Formularen?
Beschreib doch mal genauer was du vorhast und machst:

 

Wer außer dir kann das wissen *wink.gif*

Wenn die Recordsets in einem anderen Workspace geöffnet sind.
Zu 3. und wie schon oben gepostet:
Beschreibe was dein Ziel ist und wie du das bisher realisierst ...

 

Schau mal, ich habe meine letzten Beitrag noch mal geändert...

Ich benutze nicht direkt gebundene Forms, weise über ein Property ein selektiertes rst dem Form zu.

Beispiel:
Code:

In dem Bild des vorigen Beitrags hat das Form gar keine Daten, nur ein Grid, das eine DAO-Anbindung hat.

Was habe ich vor?

Ich habe meine gesamte Warenwirtschaft auf "Transaktionen" umgestellt um Änderungen jederzeit rückgängig machen zu können. Also Neue Positionen, Änderungen und Löschen von Positionen laufen alle in einer Transaktion. Somit habe ich auch das Problem mit den Access-Ufos gelöst, in denen ja beim Verlassen des Ufo eine unkontrollierte Speicherung erfolgt. Deswegen auch ein Grid für die Positionen und kein Endlosform. Im Grid habe ich jede Zelle im Griff, im Endlosform ist keine vernünftige Datenkontrolle möglich. Das Grid ist somit auch in eventuelle Transaktionen eingebunden. Das klappt lokal auch alles bestens, ich war echt glücklich mit den Ergebnissen. Da ich jetzt aber die Anwendung auf Mehrplatzfähigkeit teste, merke ich, dass ich wohl gravierende Probleme mit meinem Transaktionsmodell habe.


Zu 3. und wie schon oben gepostet:
Beschreibe was dein Ziel ist und wie du das bisher realisierst ...

Eine Stapelverarbeitung wäre doch perfekt: Wer zu erst da war wird zuerst bearbeitet, danach die anderen user. Das ist aber wohl nur ein Traum?

Quint

 

Hallo

ich habe hier mal eine Prozedur die während einer Transaktion gestartet wird auf ein neues Workspace geändert:
Code:

bei rst.Edit bricht sie ab mit der schon erwähnten Fehlermeldung: Daten können nicht aktualisiert werden, da gesperrt...

Du sagtest ja

kann man rst innerhalb einer Transaktion ausführen ohne das diese in die Transaktion eingebunden werden. Bei mir klappt das nicht. Kann es sein, dass mein neues workspace nicht angenommen wird?

Gruss, Quint

 

Hi Quint,
wir meinen verschiedene Sachen.
Du willst, so wie ich es inzwischen verstanden habe:
-Start einer Transaktion (zb.auf Tabelle1)
-Zwischendurch anderweitige Bearbeitung der der Datensätze in Tabelle1
-Beenden der Transaktion (Commit/CallBack)
Soweit ich bisher experimentiert habe, ist die Tabelle 1 (Jedenfalls die entspr. Speicherseiten) solange gesperrt, bis die Transaktion aufgelöst wird.
Eine Transaktion über einen längeren Zeitraum offen zu halten ist also in einer Mehrbenutzerumgebung kontraproduktiv *wink.gif*

Ich war davon ausgegangen, du meinst folgende Situation:
-Start einer Transaktion (zb.auf Tabelle1)
-Zwischendurch Bearbeitung der der Datensätze in Tabelle2 (außerhalb der Transaktion)
-Beenden der Transaktion (Commit/RollBack)

Also die Bearbeitung eines Recordsets innerhalb einer offenen Transaktion, ohne das die Änderungen in Tabelle2 bei einem mögl. RollBack zurückgenommen werden. Das funktioniert m.H. eines separaten Workspace-Objektes.

Um die Bearbeitung der Daten ohne Tabellensperrung vorzunehmen, kannst du evtl. mit ungebundenen (ADO-)Recordsets arbeiten. Da habe ich selbst nur rudimentäre Erfahrungen. Es finden sich jedoch einige Beispiele im Netz.

BTW: Du erstellst in deinem Code zwar ein neues Workspace-Object aber du verwendest es nicht!

 

Hallo Marsu,

ich habe das jetzt mit einer Sperrroutine gelöst, der DS ist so lange zur Bearbeitung gesperrt, bis die Transaktion abgewickelt ist. Ich denke damit kann man gut leben, zumal die Wahrscheinlichkeit, dass 2 user den selben DS zur selben Zeit bearbeiten wollen eher gering ist.

Ich würde mich aber doch noch sehr für das neue workspace interessieren, insbesondere wie ich es dann auch benutzen kann:
workspace erstellen:
Set wrk = CreateWorkspace("Pos", "Admin", "")
nur wie aktiviere ich das neue workspace? so?
Set db = wrk.Databases(0)

Also wenn Du hier noch mal den Nebel in meinem Hirn auflösen könntest.....

Gruss, Quint

 

Folgt man dem Objektmodell sieht das in etwa so aus:
Code:

Beachte: Wird eine Tabelle von einer Transaktion berührt, ist diese aber in alle Workspaces für die Bearbeitung gesperrt. Jedoch ist die Fehlermeldung etwas aussagekräftiger:
3188: Aktualisierung nicht möglich; momentane Sperrung durch eine andere Sitzung auf diesem Rechner. (Fehlertritt beim rs.UPDATE auf)

Die Grundidee Transaktionen wg. der vorhandenen RollBack-Möglichkeit zur Dateneingabe zu "missbrauchen" ist gut, jedoch durch das Sperrverhalten in einer Mehrbenutzer-DB nicht brauchbar.
Ich hab noch einmal hier im Forum geguckt. Alternativ kommt eine temporäre Änderungstabelle in Betracht, in welche die Datenänderungen zwischengespeichert werden und schließlich beim Speicher-Befehl in die Originaltabelle geschrieben werden. (Das käme deiner "Stapelverarbeitung" schon sehr nah *wink.gif*)
Oder wie oben schon erwähnt disconnected Recordsets.

 

Hi Marsu,

Danke für Deine Infos.

Gruß, Quint

 

Hallo
lies einmal hier:
http://www.ms-office-forum.net/forum...14#post1381114
in #10
evtl. ist das auch was für Dich