INSERT crasht im Multiuserbetrieb DAO/ODBC

[PhilS]

Vielleicht zeigst du nochmal deinen Code, auf das notwendige Minimum reduziert.

[ebs17]

Eine komplette Transaktion kann bei mir bis zu 5 Sekunden dauern.

Hältst Du es für ausgeschlossen, dass es auch schneller geht? Massendatenaktion statt Einzelschreiben?

Um welche Datenmengen geht es da?

Sowie: Wenn Deine Power-User praktisch parallel Massenschreibaktionen loslassen, dürfte ein Access-Backend (dummes File) als Backend weniger gut geeignet sein. Das wäre für sich schon ein Grund, auf ein aktives DBMS umzusteigen -  das ist nämlich ein Dienst mit eigener "Intelligenz", der Anfragen entgegennimmt und bearbeitet in einer Folge, wie er sie bewältigen kann. Wenn die Anweisungen dann im DBMS selber vorliegen (in dessen ureigenen Sprachdialekt) statt von außen aufgesetzt zu werden, wird es dann noch einmal schneller und unproblematischer laufen.

[Milvus]

Habe eine Ursache identifiziert:

Eine Recordset lässt sich nicht optimistisch öffnen. Code auskommentiert und die Transaktionen laufen wieder gleichzeitig.

[Wurliwurm]

Durch die neuen Recordsets ist es aber so, dass immer nur ein User schreiben kann und zwar so lange, bis die Transaktion beendet ist. Erst dann kann ein nächster rein.
(...)
Ich arbeite mit DAO und habe schon auf eine optimistische Sperre gesetzt
(...)
Eine Alternative wäre evtl. ein Batch-Update mittels ADO?
(...)
Noch mal, was gemacht werden soll: INSERT/AddNew in 10 Tabellen, Update in 2 Tabellen (das alles ganz oder gar nicht)

Es ist bei einer Transaktion immer so, daß nur ein User auf einmal schreiben darf, Stichwort ist "Serialisierbarkeit". Wie sehr sich die gegenseitigen Transaktionen behindern, hängt von der Granularität der Sperren ab. Anhand der Beschreibung kann man vermuten, daß mit den Recordsets jetzt breiter gesperrt wird als vorher.

Das Problem ist und bleibt das File-Backend. Egal, was Du vorne eingibst in deinem VBA, adLockPessimistic, adCursorServer, adSerializable etc. pp, kann das JET nicht.

Die Transaktionen, die du fährst, sind recht schwergewichtig. Wie bereits beschrieben, kann ein aktives Datenbanksystem die Serialisierbarkeit und die Granularität der Sperren ordentlich managen. In der Praxis wirkst sich das so aus, daß es läuft wie Butter und nicht wie beim JET lange dauert und immer die Gefahr von Crashs und Datenkorruption droht.

Hier ist recht anschaulich die Theorie erklärt
https://studentenportal.ch/dokumente/dbs1/480/

[Milvus]

Hallo Wurli,

ich habe mir dein Übersichtsblatt für Transaktionen mal näher angeschaut.
Wenn ich auch nicht alles verstehe, sind die Grundannahmen dort (insbes. x und s-Lock) auch für Transaktionen unter Access gegeben? Mein logischer Sachverstand zwingt mich zu der Annahme, dass dies die Grundlage für die daraus vielfach erwähnte Serialisierbarkeit ist.

Ich würde ja so sagen, wenn x und s konsequent durchgezogen werden, müssen Transaktionen aufeinander warten (wenn z.B. ein Lesezugriff auf ein noch nicht commitetes x-Lock ansteht oder ein Schreibzugriff auf ein noch nicht gelesenes s-Lock usw.) oder es führt zu Fehlern, was wiederum zu Rollbacks führt.

Ist das mehr oder weniger ein Standard für alle DB-Systeme oder spielt da Access eine Ausnahme?

Danke für jeden Input an der Stelle. Das ist mit Abstand mal das nützlichste Forum für mich, in dem ich je unterwegs war.

[Wurliwurm]

Hallo Milvus,

Serialisierbarkeit ist bei DB-Systemen Standard, wenn diese korrekt umgesetzt ist, entstehen auch nur selten solche Situationen, wo eine Transaktion gekillt werden muß wegen Konflikten. Ein Student müßte es so formulieren: "Der Graph darf keinen Zyklus enthalten", was im Klartext bedeutet, daß es immer dann nicht gutgeht, wenn A endlos wartet, daß B endlich seine Sperre freigibt, und B nicht weiterkommt, weil er wiederum auf A wartet.

Dein Vertrauen ehrt mich, aber ehrlich gesagt kenne ich die Feinheiten von Access hier nicht. Nicht daß ich nicht gegoogelt hätte, und hier wird auch viel Halbwissen in den englischsprachigen Foren verbreitet. Eine richtig tiefe Beschreibung von Jet habe ich nicht gefunden, der englischsprachige Wikipedia-Artikel ist immerhin besser als der deutsche.

Was ich weiß: Jet kennt pessimistische Sperren gar nicht. Es gibt also solche serialisierbaren Warteschlangen dort nicht, sondern es wird davon ausgegangen, daß alles gut geht und erst beim Update gibt es ggfalls. eine Fehlermeldung.

Allein die Architektur von Jet unterscheidet sich grundlegend von Datenbanksystemen, weil man aktive DBMS nicht mit einem File-Backend vergleichen kann. Bei DBMS gibt es einen Prozess, der die DML-Kommandos verarbeitet, bei Files gibt es viele Windows-Computer, die auf eine Datei zugreifen. Access ist als Backend für den Multiuserzugriff einfach nicht gebaut. Deshalb kann man die Ausführungen in Lehrbüchern zu Sperrkonzepten und Transaktionen im Datenbankbereich nicht auf Access anwenden.