a97: Fehler richtig abfangen

Hallo!
Ich möchte eine Abfrage nach Excel exportieren mittels DoCmd.OutputTo acQuery,… usw.
Bricht man das Speichern ab, kommt eine Fehlermeldung.
Die wollte ich mittels On Error GoTo err abfangen. Und err: msgbox „Aktion wurde abgebrochen“, abfangen.
nun erscheint diese Meldung auch wenn die Abfrage korrekt gespeichert wird.

Wie kann geht es nun richtig?

Vielen Dank im Voraus.
Georg

Mahlzeit,

Die wollte ich mittels On Error GoTo err abfangen. Und err:
msgbox „Aktion wurde abgebrochen“, abfangen.
nun erscheint diese Meldung auch wenn die Abfrage korrekt
gespeichert wird.
Wie kann geht es nun richtig?

Wie sollen wir es wissen, wenn du den Code nicht postest?

Eine Vermutung: Das On Error Goto XXX setzt eine Marke XXX voraus. Unmittelbar davor endet deine normale Verarbeitung, aber das passiert nicht von alleine, sondern du mußt das explizit tun, z.B. durch ein Exit Function o.ä.

Gruß

Sancho
P.S: Wenn du Code posten solltest, dann benutze den PRE-Tag!

a97: Fehler richtig abfangen 2. Versuch.
Sorry, wenn es zu ungenau war.
Ich möchte also das Ergebnis einer Abfrage im Excel-Format speichern.

Private Sub btn\_excel\_Click()
On Error GoTo Err
 DoCmd.OutputTo acQuery, "Abfrage\_Auswahl", "MicrosoftExcel(\*.xls)", "", False, ""

Err:
MsgBox "Aktion wurde abgebrochen"
 Exit Sub
End Sub

Aufgrund der Aktion DoCmd.OutputTo…usw. (siehe oben) öffnet sich ein Formular (Access Standard) zum Speichern der Abfrage.
Wenn ich nun auf Abbrechen klicke, weil ich doch nicht speichern möchte, erhalte ich ohne Fehlerbehandlung eine Fehlermeldung, diese dachte ich wie oben beschrieben abzufangen. Das klappt auch.
NUR: auch wenn ich beim Speichern OK klicke, erscheint trotzdem meine MsgBox. Obwohl das ja kein Fehler sein dürfte, oder?

Vielleicht bin ich auch einfach nur zu blöd, oder es gibt dafür eine Erklärung.

Es kann etwas dauern bis ich mich bedanke oder mich auf Nachfragen melden kann.
Bekomme Freitag (Morgen) DSL und bin dann über das Wochenende weg.

Schon jetzt besten Dank für jede Hilfe.

Gruß
Georg

Die Prozedur wird so lange durchlaufen bis ein „exit sub“ oder ein „end sub“ die Prozedur beendet. Wenn du jetzt dein Program im Kopf mal durchlaufen läßt, wirst du feststellen, dass auch nach erfolgreicher Durchführung des Export, dein Programm weiterläuft bis es es auf das „Exit sub“ trifft. Die Sprungmarke Err: (im übrigen sehr unglücklich benannt, da Err ein reservieres Wort bzw. Objekt ist) ist eben nur eine Sprungmarke und keine Anweisung. Sie wird schlicht überlesen und nur im Fehlerfall angesprungen um von dort das Programm weiterzuführen.

Mit der Information und ein wenig nachdenken, sollte es einfach sein das Programm zu korrigieren. (Tipp: Man muss das Programm beenden bevor die Sprungmarke Err: erreicht wird)

HTH
Quaser

Sorry, wenn es zu ungenau war.
Ich möchte also das Ergebnis einer Abfrage im Excel-Format
speichern.

Private Sub btn_excel_Click()
On Error GoTo Err
DoCmd.OutputTo acQuery, „Abfrage_Auswahl“,
„MicrosoftExcel(*.xls)“, „“, False, „“

Err:
MsgBox „Aktion wurde abgebrochen“
Exit Sub
End Sub

Mahlzeit,

wie schon gesagt, es fehlt das Exit-Statement:

Private Sub btn\_excel\_Click()
On Error GoTo Err
 DoCmd.OutputTo acQuery, "Abfrage\_Auswahl", "MicrosoftExcel(\*.xls)", "", False, ""

 **Exit Sub**

Err:
 MsgBox "Aktion wurde abgebrochen"
 Exit Sub
End Sub

Vielleicht bin ich auch einfach nur zu blöd, oder es gibt
dafür eine Erklärung.

*g* oder das ist die Erklärung…
Nein nein, es ist alles in bester Ordnung :smile:

Gruß

Sancho

Hallo, Georg!

Ich möchte eine Abfrage nach Excel exportieren mittels
DoCmd.OutputTo acQuery,… usw.
Bricht man das Speichern ab, kommt eine Fehlermeldung.
Die wollte ich mittels On Error GoTo err abfangen. Und err:
msgbox „Aktion wurde abgebrochen“, abfangen.
nun erscheint diese Meldung auch wenn die Abfrage korrekt
gespeichert wird.

Ich bin immer noch auf der komischen Meinung, dass JEDE noch so billige Prozedur und Funktion eine Fehlerbehandlung aufweisen sollte, selbst wenn sie semantisch keinen Fehler produzieren kann. Irgendwas kann immer passieren, und wenn es komische Einflüsse von außerhalb sind. (Außer, man weiß genau, was man tut, und man fängt den Fehler irgendwo anders, meist bei der aufrufenden Prozedur ab. Aber hast Du eine Ahnung, wie schön es ist, den Fehler zu suchen, wenn ungefähr hundert Prozeduren ohne Fehlerbehandlung sequentiell sich selbst aufrufen, in der untersten ein Fehler auftritt und in der obersten erst der Fehler abgefangen wird?).

Außerdem habe ich seinerzeit von meinem Pauker eingetrichtert bekommen, dass GOTO (außer bei On Error Goto…) und EXITs schlechter Programmierstil und Zeichen mangelnder Gedanken über das gewünschte Verhalten sind. Jedes Exit und Goto lässt sich mit einer einfachen If-Anweisung genau so abbilden.

Genug der theoretischen Ergüsse: Hier ein Sniplet, welches Du einfach in jede Prozedur einfügen kannst, bevor es losgeht mit dem Programmieren:

'===============================================================================
' Beschreibung: (der Prozedur)
' Angelegt: 17.09.2004 / (Angelegt durch)
' Änderung: 17.09.2004 / (Geändert durch, Änderungshistorie)
'===============================================================================
On Error Goto Err\_test

Err\_test:
 select case err
 case 0
 case else
 msgbox "Fehlercode:"&chr$(9)&err &chr$(13) \_
 &"Fehler:"&chr$(9)&chr$(9)&error$ &chr$(13) \_
 &"Modul:"&chr$(9)&chr$(9)&me.name &chr$(13) \_
 &"Funktion:"&chr$(9)&chr$(9)&"test", \_
 vbinformation,
 resume Err\_test
 end select

Wie schon vorher richtig beschrieben, läuft in Deinem Code der Err-Part auch noch durch. Das umgehst Du entweder mit dem Igitt-Exit oder über obiges Konstrukt.

Die Case-Anweisung ist übrigens dazu gedacht, bestimmte vorhersehbare Fehler aufzufangen und zu behandeln. Der Case-Else-Teil stellt die Notlösung dar, welches das Programm ab Absturz hindert, aber den Entwickler Rückschlüsse auf den Fehlerort gibt, den es zu beheben gilt.

Willst Du beispielsweise aus einer Excel-Zelle den Text einer String-Variablen zuweisen, dort steht aber eine Formel mit Fehler (z. B. #DIV0!) drin, was für Dein Programm aber nichts anderes heißt wie „Nimm einen leeren Text an“, dann baust Du in die Case-Anweisung ein zusätzliches

 case 
 strText = "" ' Default-Wert übernehmen
 Resume Next ' und weiter, als wär nichts gewesen
 case ...

ein.

Gruß, Manfred

Danke!!
Vielen Dank an alle für die vielen Hinweise.

Auweiha!
Solch ein Fehler sollte eigentlich nicht passieren.
Kommt aber vor wenn man auf die Schnelle 3 Dinge gleichzeitig versucht.
Und ich dachte noch Exit Sub hab ich doch…allerdings an der falschen Stelle; peinlich!

Vielen Dank nochmals und schönes Wochenende an alle!
Gruß
Georg