Transaktion / ODBC-Aufruf fehlgeschlagen

F

FrankSausB

New Member
Hallo Experten!

Ich hoffe, daß mein Beitrag hier richtig ist und daß ihr mir helfen könnt.

Ich habe mit Access2K+SQLServer2000+DAO eine Transaktionssteuerung für gebundene Formulare gebaut. (Workspace, Datenbank, Recordset)

Beim Aufruf des Formulars wird der erste Datensatz angezeigt und BeginTrans ausgeführt. Beim Wechsel des Datensatzes wird abhängig von IsDirty und Anwenderfrage entweder Rollback oder Commit ausgeführt und dann wieder BeginTrans. Für die Anwendung funzt das prima. Jetzt mein Problem. Wenn ich nach dem ersten Begintrans via zweiter Access-DB oder via Enterprise-Manager in die entsprechende Tabelle reinschau und in ihr scrolle ist alles ok. Wenn ich aber einmal den Datensatz gewechselt habe und somit einmal Commit oder Rollback und dann wieder BeginTrans ausgeführt wurde und dann wieder von "zweiter Stelle" in die Tabelle reinschau gibt es nach einer gewissen Zeit den "ODBC-Aufruf fehlgeschlagen" -Fehler, keine Fehlernummer nur der Text. Dann wird die Tabelle geöffnet und in jedem Feld steht "#Name?".

Daraufhin habe ich ODBC-getract und es finden sich zwei Einträge mit einer Duration von jeweils 60000 (ms) im Protokoll für "Lock: Cancel" und "SQL Transaction" (Die Duration entspricht der in den Access-Optionen eingestellten ODBC-Aktualisierung)

Was ist da los? Warum geht das nach dem ersten BeginTrans und nach dem zweiten (und dem ersten Commit/Rollback) nicht mehr?

Über eine Antwort würde ich mich sehr freuen :)

Gruß
Frank
 
Ohne mit Deiner konkreten Konfiguration Erfahrungen zu haben...
Das klingt, als ob Deine erste "Sitzung" die Tabelle (mindestens seitenweise) gelockt hat, nachdem die ersten Aenderungen gemacht wurden.
Das kann z.B. passieren, wenn ein Glied in der Kette (z.B. Access in dem Moment in dem Du das Anzuzeigende Resultset holst) implizit eine Transaktion aufmacht.
Du hast dann zwei ineinander geschachtelte Transaktionen von denen Du selbst nur die innere explizit oeffnest und auch schliesst, aber die Aeussere ist womoeglich noch offen.
Die sollte auch implizit geschlossen werden, wenn die erste Sitzung die DB-Verbindung wieder abbaut.
Wenn Deine zweite Sitzung dann nicht einen dirty read macht / machen kann, dann wird diese keinen Zugriff auf die gelockten Saetze bekommen.
Das sollte sich aber im Enterprise-Manager beochten lassen, da gab es mal eine Auflistung der Prozesse in der z.B. das letzte Statement und sowas wie deadlocks angezeigt werden, und es muesste irgendwo noch eine Auflistung ueber Transaktionen/Locks geben.

Ciao,
Mercy.
 
Hallo,

Danke für Deine Antwort.

Es ist schon komisch, aber nachdem ich meinen Rechner neu aufgesetzt habe, geht es wieder. Aber Dein Hinweis hat mich dazu veranlaßt die Codezeilen nochmal in eine optimierte Reihenfolge zu bringen. Nun wenn man nach dem Commit dem Formular das Transaktions-Recordset entzieht werden die Änderungen in anderen Listen sichtbar. Sonst ist da nämlich in der Tat noch eine Sperre.

Danke!
Frank
 
Doch nicht :(

Hi!

Es wäre ja auch zu schön gewesen...

Aber jetzt weiß ich woran es liegt und das ist höchsinteressant.

Wenn Du ein Formular öffnest und die Datenherkunft ist ein Recordset (via Recordset/Workspace) und darin dann Daten änderst, also eintippst, dann findet keine Sperre statt. Schreibst Du aber via VBA in einzelne Formularfelder für diesen DS was rein, bewirkt das eine Sperre. So als ob das ein zweiter User wäre, für den die Lockedits=false-Option nicht gilt. Und genau das war der Fall. Erst beim Anzeigen des zweiten DS wurden via VBA Daten verändert. (Beim Öffnen, also im ersten Fall, greift anscheinend noch das Click-Event, das diese Änderungen auslöst, eines Controls nicht)

Was tun?
Die Änderungen via VBA auf ein Recordsetclone des Formulars machen.

Ich find mich echt gut. :)

Danke.
 
You must log in or register to reply here.
Back
Top