Office: (Office 2013) Access 2013; VBA; Unterformular stürzt ab

Das mit dem schließen wurde so quasi vorgeschlagen und daher dachte ich, dass es einen sinn macht. Z.B. kenne ich das in anderen Programmiersprachen (PHP, MySQL usw.) da öffnet man die "db" und am ende, wenn alles durch ist, schließt man sie wieder.

Habe das trotzdem raus genommen und es ausprobiert.
Nun bekomme ich eine ganz andere Fehlermeldung, und zwar:

Laufzeitfehler '-2147352567 (80020009)':
Sie haben einen Wert eingegeben, der für dieses Feld nicht gültig ist.

Wenn ich auf Debuggen klicke, wird die folgende Zeile markiert:

Code:

die letzte Zeile davon wird markiert.

 

Hast du für das Formularfeld txtAuftragID irgendwelche Formate oder Gültigkeitsregeln angegeben?
maike

 

Das dbFailOnError fängt zwar den Fehler dort auf aber man soll trotzdem ein Rollback benutzen um die Daten wirklich zurück zu rollen. (So laut meiner Recherche)

Ganz einfach. Die Unterformular soll nur eine Darstellung der Tabelle darstellen und man soll dort nur das entsprechende Datensatz auswählen können.
Wenn man aber in der Tabelle einige Datensätze ändern möchte, dann soll es nicht im Unterformular passieren, sondern in den jeweiligen Textfeldern (ungebundene Feldern) ...

Weil sonst hätte man direkt alles in der entsprechenden Tabellen gemacht. Das ist aber nicht der Sinn eines Formulars. Man nimmt Datensatz / Datensätze, man bearbeitet die und speichert die wieder in die jeweilige Tabelle(n) ...

MfG
Daniel

 

maike

Sorry konnte dir hier nicht ganz folgen?
Die Prozedur hier ist soweit richtig. Das Problem besteht in den obigen Quelltext was ich zuvor bzw. im 1. Beitrag gepostet habe.

Kannst du es mir etwas anders schildern?
Vielleicht habe ich dich falsch verstanden ...

 

Also was denn jetzt - Fingerübungen oder echte Datenbank *confused.gif* ?
Für Fingerübungen ist das Ganze incl. Rollback ja vielleicht ganz nett,
für eine echte Datenbank bindet man das Formular an die Tabelle (Datenherkunft) und erspart sich den ganzen Ärger.

Das Problem manifestiert sich vielleicht im "obigen Quelltext", es kann aber ganz woanders entstehen.
Zeigt sich auch daran, dass das Weglassen von wrk.Close den ersten Fehler scheinbar beseitigt hat und jetzt der nächste gemeldet wird (Gültigkeit).
maike

 

Nein, außer das ich das Feld gesperrt habe. Damit der Nutzer (in dem Fall ich selbst) die ID nicht ändern kann

 

Es dient für beides. Es ist eine Herrausvorderung und es ist eine echte Datenbank bzw. soll es werden.

Ja die Schiene mit einfach das Formular an die Tabelle binden ist nicht ideal und entsprechend für verschiedene User nicht beschränkt und empfehlenswert ...
Abgesehen davon sollte man auf die Transaktionen nicht verzichten, zu mal die Tabellen verschiediene Beziehungen zueinander haben. Das sorgt dafür das wenn etwas schief läuft und mehrere Tabellen betroffen sind, dass die Datensätze nicht fälschlich irgendwo hängen bleiben usw.

 

Wo hast du denn diese Weisheiten her *rolleyes.gif* ?

Häh?

Wie Eberhard schon sagte, dbFailOnError macht genau dieses.

maike

 

Das macht man auch in anderen Programmiersprachen nicht, dass man Objekte schließt, die anderswo noch benötigt werden.

Du machst im Prinzip folgendes:
Code:

"Trotzdem" ist gut - du darfst den falschen Code auch gerne drinnen lassen. *biggrin.gif*

mfg
Josef

 

Die Weisheiten habe ich von zig Literaturen her und wird wirklich auch so empfohlen ...

Hm dann nehme ich dbFailOnError mal raus und probiere das so. Weil auch dies wird in zig beispielen so gehandhabt. Da bin ich jetzt überfragt und lasse mich von euch quasi leiten ... Access, da bin ich total noch anfänglich ...

In anderen Programmiersprachen habe ich sehr gute Kenntnisse ...

 

Wieso denn jetzt das *rolleyes.gif* ? Hab' ich das irgendwo gesagt?
maike

 

Ja das stimmt. Da Widerspreche ich dir nicht und gebe dir recht. Ich bin nur davon ausgegangen, dass dies, also nach dem das durch ist, dass man es danach schließen kann... Habe es anscheinend falsch interpretiert.

Ah das klingt gut, dass probiere ich mal aus.

Hehe, hast guten Humor, dass muss ich dir lassen ;-)
Finde ich gut ...

 

.. aber dann müsstest du selbst eine Workspace-Instanz erzeugen und darin dann die Datenbank öffnen usw.

Gleich noch ergänzt, da das auch immer wieder "empfohlen" wird: Alle Datenbank-Objekt schließen.

Code:

.. db verweist auf die Standard-DB der Access-Anwendung und die darf man nicht schließen, weil man sie nicht geöffnet hat.

Das "Lästige" dabei: Access verzeiht so ein Schließen sogar ein wenig, weil es die DB einfach im Hintergrund wieder aufmacht, wenn sie neu über Currentdb angefordert wird. => Folge: dieser falsche Code fällt nur in bestimmter Anordnung des Codes auf.

Schließen wäre richtig wenn set db = dbengine.OpenDatabase(...) verwendet worden wäre.

.. um den Fehler nachzustellen. *wink.gif*

mfg
Josef

 

mfg
Josef

Hallo Josef,

du hast mich zwar auf eine Idee gebracht aber bekomme das nicht so ganz hin.

Da meine Vorgehensweise durch 2 Schaltflächen durchvollziehen ist und meine "Public Sub aktualisieren ... " in einem Modul geschrieben ist kann ich das obige wie genau nun Lösen?

Muss ich denn das mit Openrecordset machen?
Weil ich soll für die Transaktionen den Execute benutzen. Wie kann ich das miteinander kombinieren?

Bitte um Hilfe.

MfG
Daniel

 

.. db verweist auf die Standard-DB der Access-Anwendung und die darf man nicht schließen, weil man sie nicht geöffnet hat.

Das "Lästige" dabei: Access verzeiht so ein Schließen sogar ein wenig, weil es die DB einfach im Hintergrund wieder aufmacht, wenn sie neu über Currentdb angefordert wird. => Folge: dieser falsche Code fällt nur in bestimmter Anordnung des Codes auf.

Schließen wäre richtig wenn set db = dbengine.OpenDatabase(...) verwendet worden wäre.


.. um den Fehler nachzustellen. *wink.gif*

mfg
Josef

Ah danke für die Info ... Das ist echt bisschen verwirrend wenn man da kein Überblick hat ...
Aber versuche dir zu folgen.