Office: (Office 2010) OutputToPDF

Hallo Josef,

da ist nichts unsauber seitens Access.

In deiner Routine Create_PDF gibt es keinerlei Fehlerbehandlung, dabei passieren eine Menge Sachen drin, die schiefgehen können.

Wenn die Fehlerbehandlung fehlt, geht der Code normal weiter zur nächsten Zeile. Das ist nicht der Fehler von Access sondern deins, und zwar ein ziemlich gefährlicher.

Du mußt eine korrekte Fehlerbehandlung einbauen (mit On Error Goto... usw.) und dort den Fehler 2501 abfangen, damit in dem Fall keine Meldung ausgegeben wird.

Ein bißchen Erklärung: Die NoData prozedur im Bericht läuft OK,der Bericht wird dann geschlossen. Daraufhin stolpert OutputTo, weil die Ausgabe eben abgebrochen wurde, und der Fehler 2501 kommt eben daher. OutputTo kann nicht wissen, warum es nix zum Ausgeben gibt.

 

Hallo!

Vorab: Mein Einwurf bezüglich DoCmd.Output hat nichts mit der Prozedur "Create_PDF" zu tun.

Das stimmt nicht.
Wenn eine Fehlerbehandlung fehlt, wird der Codeablauf abgebrochen, wenn ein Laufzeitfehler ausgelöst wird.
DoCmd.Output ignoriert/überspringt allerdings den in Report_NoData ausgelösten Fehler.

Hast du mein geschildertes Szenario probiert?

Code:

Aufruf-Varianten:
1. DoCmd.OpenReport "ReportName", acViewPreview
=> Fehlermeldung kommt ... passt, entspricht meiner Erwartung
2. DoCmd.OutputTo acOutputReport, "TestReport", acFormatPDF, ...
=> Es kommt keine Fehlermeldung. Der Code-Ablauf wird ohne Möglichkeit den Fehler abzufangen abgebrochen. ... entspricht nicht meiner Erwartung.

Der Abbruch bei OutputTo kommt nur, wenn man Cancel innerhalb Report_NoData auf True setzt. Dann kommt es sowohl bei DoCmd.OpenReport als auch bei DoCmd.OutputTo zur einem Laufzeitfehler. Bei Cancel=True entspricht das Verhalten meinen Erwartungen.

/edit:
Ursprünglich war ich der Meinung, dass der Code weiterläuft, da ich in der Test-Prozedur keinen weiteren Ausgabe-Code hatte.
Mittlerweile stellte ich fest, dass zwar der Code-Ablauf abgebrochen wird, allerdings kein Fehler zum Abfangen zur Verfügung steht.

mfg
Josef

 

Hallo zusammen,

ich habe eine Fehlerbehandlung eingefügt und die Reports werden nun komplett erzeugt.

Code:

 

Hallo!

Noch ein Tipp zur Fehlerbehandlung:
Da du Create_PDF kaum an oberster Stelle aufrufen wirst, würde ich keine versteckte Fehlerumgehung einbauen.
Bei deinem aktuellen Code wird nämlich bei einem nicht erwarteten Fehler (else-Zweig im select case) eine Messagebox angezeigt und dann im aufrufenden Code ganz normal weitergemacht, als wäre nichts passiert.

Ich würde das eher so gestalten:
Code:

Damit hast du die beiden erwarteten Fehler behandelt und alle anderen werden wieder ausgelöst um eine oder mehrere Stufen weiter oben behandelt zu werden.

Und nun noch ein Hinweis zum Code-Aufbau *Smilie

Code:

Irgendwie sind das 2 Themen, die wenig gemeinsam haben.
=> durch den Einsatz von getrennten Prozeduren (eine Prozedur für jeden Aufgabenbereich) würde der Code vermutlich übersichtlicher - aber vor allem besser wartbar und nach Aufgaben getrennt testbar.

Nur als Beispiel (kein vollständiges Refactoring):
Code:

mfg
Josef

 

\@Josef P.:

Ich hätte das genauer schreiben sollen. Ich ging natürlich davon aus, dass Cancel in NoData auf True gesetzt wird, das ist für mich völlig logisch. Deshalb hatte ich geschrieben, der Bericht wird geschlossen und nichts mehr ausgegeben. Und in dem Fall bekommt man eben den Fehler 2501, den man abfangen kann und auch soll.

 

Hallo!

Das wäre nicht notwendig gewesen, wenn du den Beitrag #15 genau gelesen hättest. *wink.gif*

Ich schrieb in Beitrag #15:

Für mich ist das ein sehr unsauberes Verhalten.

Falsch an diesem Beitrag ist übrigens: "ganz normal weiter". Der Code bricht nämlich ab, es kommt aber kein Laufzeitfehler durch.

Anm.: Der Fehler muss nicht unbedingt als Reaktion auf NoData ausgelöst werden. Er könnte auch an beliebiger andere Stelle ausgelöst werden.
Dass OutputTo bei einem Fehler abbricht, ohne eine Chance zu geben, den Fehler abzufangen, finde ich nicht nett.

mfg
Josef