Ich habe ein ziemliches Problem mit einer schon etwas älteren Access-Anwendung (von ursprünglich Access97 auf 2010 portiert) - die bisher aber einwandfrei funktionierte. In einem Batch-Lauf kommt die Fehlermeldung: "Fehler Nr. 3003 (ausgelöst von DAO.Recordset): Transaktion konnte nicht gestartet werden; bereits zu viele verschachtelte Transaktionen vorhanden."
In dem ganzen Lauf gibt es EIN BeginTrans, und zwar ganz am Anfang. Der Fehler wird ausgelöst beim Versuch eines Updates auf ein Recordset - genau derselbe Update ist vorher aber schon sieben mal erfolgreich gelaufen. Die Tabelle hinter diesem Recordset hat genau drei Felder: ein Integer- und zwei Datumsfelder. Der Code soll ein Kalenderjahr nach bestimmten Kriterien (die aus anderen Tabellen gelesen werden) immer feiner aufteilen, so dass am Ende X Perioden (=Datensätze) entstehen.
Ach ja: alle Tabellen stecken in einer verknüpften Datenbank.
Hat irgendjemand eine Idee?
Access 2010, Win 7
Hallo,
Zitat...die bisher aber einwandfrei funktionierte...
naja, dann wird sich nach 'bisher' irgendwas geändert haben ;)
ZitatIn dem ganzen Lauf gibt es EIN BeginTrans
Nun - Access verträgt 5 verschachtelte Transaktionen.
Man kann eine Transaktion mit BeginTrans einleiten und innerhalb dieser noch weitere mit BeginTrans starten.
Jede mit BeginTrans gestartete Transaktion muss mit CommitTrans übernommen oder per Rollback zurückgesetzt werden!
Wird das vergessen, wird es nach dem Schließen des betroffenen 'Workspace-Objektes', was unter bestimmten Voraussetzungen auch am Prozedurende automatisch erfolgen kann, ein Fehler ausgelöst.
Überprüfe daher bitte ob JEDE mit BeginTrans gestartete Transktion auch mit CommitTrans abgeschlossen wird.
Deiner Beschreibung entnehme ich, dass es sich bei der verknüpften DB um einen MS QL-Server handelt?
Wenn ja - warum verlagerst du aufwändige Transaktionen nicht in StoredProcedures am SQL Server?
Das mit den 5 Transaktionen ist schon klar. Wie kommt es aber, dass unmittelbar nach dem Starten der "Anwendungs-Datenbank" und dem Aufruf des besagten Batch-Programms (mit einem BeginTrans) der geschilderte Fehler auftritt - und zwar bei einem Update-Kommando? Geplant (und programmiert) ist, dass dass die Transaktion nach Ende der Batch-Verarbeitung committed (oder zurückgesetzt) wird. Das workspace-Objekt ist eigentlich die ganze Zeit über aktiv ...
Kann man irgendwie ausgeben lassen, wie viele Transaktionen aktiv sind? Kann es sein, dass Transaktionen IMPLIZIT gestartet werden - und wenn ja, wodurch?
Bei der "Daten-Datenbank" handelt es sich ebenfalls um eine Access-Datenbank. Hier drin stecken NUR Tabellen, nichts weiter. Diese Aufteilung stammt aus den Anfangszeiten von Access und erscheint mir auch heute noch durchaus logisch und sinnvoll.
Hallo,
Zitat...dass die Transaktion nach Ende der Batch-Verarbeitung committed (oder zurückgesetzt) wird.
Werden in diesem Batch-Programm mehrere Transaktionen gestartet hilft es u.U. JEDE der Transaktionen mit BeginTrans einzuleiten und mit CommitTrans zu übernehmen oder im Fehlerfall durch Rollback zurück zu setzen.
ODER
Bei meinen Recherchen bin ich auf folgendes gestoßen:
http://www.vbarchiv.net/forum/read.php?f=20&i=1794&t=1794
Im angegebenen Link wird u.A. dein Problem beschrieben, den Sortierfehler lässt du einfach unbeachtet.
HTH
p.s.
ZitatDiese Aufteilung stammt aus den Anfangszeiten von Access und erscheint mir auch heute noch durchaus logisch und sinnvoll.
An dieser Sinnhaftigkeit hat sich bis Access 2013 nichts geändert. ;)
Hallo,
der Link hilft leider nicht wirklich weiter; dort wird von der Möglichkeit geredet, auf ADO zu wechseln, das war's dann - ansonsten keinerlei hilfreiche Hinweise.
Was mich nach wie vor verwirrt: wieso kommt dieser Fehler bei einem Update? Nachdem vorher sieben dieser Updates korrekt gelaufen sind?
Das BeginTrans ist nach den Deklarationen und einer Zuweisung der erste Befehl in der Start-Funktion (über eine globale Workspace-Variable). Der Lauf selber besteht aus mehreren Teilen (Unterfunktionen im selben Modul), und erst wenn alle OK sind, gibt's ein CommitTrans - das steht nur einmal im Code. Ansonsten gibt's in der Exit-Prozedur ein Rollback - auch das steht nur einmal da.
Und irgendwo zwischen dem einzigen BeginTrans und dem einzigen Commit oder Rollback gibt's diesen Fehler. (Danach wird die Rollback-Prozedur ordungsgemäß durchgeführt). How come???
Hallo,
Zitat...dort wird von der Möglichkeit geredet, auf ADO zu wechseln, das war's dann
Und dort steht auch, daß der Fehler durch DAO verursacht wird - das war's dann auch ;)
Zitatwieso kommt dieser Fehler bei einem Update? Nachdem vorher sieben dieser Updates korrekt gelaufen sind?
Nur mal so als Interessenfrage - warum versuchst du nicht einmal diese 7 Transaktionen mit BeginTrans und CommitTrans einzugrenzen, so wie ich dir das bereits vorgeschlagen habe?
Werden die 7 Transaktionen alle von der Start-Funktion aus gestartet oder 'in Serie' aus den aufgerufenen Unterfunktionen?
ZitatAnsonsten gibt's in der Exit-Prozedur ein Rollback
Gibt's da eine eigene Prozedur für's Rollback?
Hallo,
die grundsätzliche Arbeitsweise des Programms kann man dem beiliegenden excerpt.txt entnehmen. Hauptprogramm ruft Unterprogramm A, anschließend Unterprogramm B, das ruft Unterprogramm BB, danach (mit anderen Parametern) nochmal BB - und hier kommt der Fehler. Gestartete Transaktion wird im Hauptprogramm "gerollbacked".
Wenn ALLES korrekt ist - also alle Unter- und Unter-Unterprogramme fehlerfrei durchlaufen wurden - wird die Transaktion committed.
Ich habe hier (gezielt) nur EINE BeginTrans - wie kommt Access darauf, dass es mehrere sein könnten? Habe ich irgendetwas übersehen?
Vielen Dank für weitere Ideen und Hinweise!
Hallo,
wo und wie sind die benutzten Objekte und Variablen deklariert und was machen die Funktionen, deren Code du nicht gezeigt hast?
Die zitierte Felermeldung erinnert mich an den ebenfalls schwer zu klärenden Fehler "Mehr Datenbanken können nicht geöffnet werden".
Ich vermute, auch hier kommt es auf jedes Detail an.
Hallo,
ich häng mal die gesamte Modul-Datei (mdlAbrechnung) mit an und das Ergebnis der Print-Statements. Im internen Debug sieht man als letzten Eintrag: "Vor: rsP.Update".
Das scheint schon irgendwie ein Mengenproblem zu sein; soweit ich mich erinnern kann, wurde "PeriodeSplitten" in der "Do While Not rsV.EOF"-Schleife noch nie mehr als dreimal durchlaufen. Allerdings stört es offensichtlich nicht, dass es in der "Do While Not rsK.EOF"-Schleife öfter aufgerufen wird. Ich sehe aber, ehrlich gesagt, keinen vernünftigen Grund dafür ...