Eine Prozedur, die monatelang unauffällig ihren Dienst getan hat, bricht plötzlich mit einer kryptischen Meldung ab – und der Anwender steht vor einem Dialog, mit dem er nichts anfangen kann. Der Grund ist fast immer derselbe: Es gibt keine oder nur eine halbherzige Fehlerbehandlung. Dabei ist “On Error”<\/b> eines der mächtigsten Werkzeuge in VBA, wenn man weiß, wie man es einsetzt. Wir schauen uns die Muster an, die aus einer fragilen Lösung eine robuste machen: wie wir Fehler nicht nur abfangen, sondern strukturiert behandeln, Ressourcen zuverlässig freigeben, Fehler zwischen den Schichten einer Anwendung weiterreichen und sie in einer Tabelle protokollieren. Die Beispiele findest Du im Modul “mdlFehlerbehandlung”<\/b> der Beispieldatenbank. Wie das im Einzelnen gelingt, zeigt der vorliegende Beitrag.<\/b><\/p>\n
Was passiert ohne Fehlerbehandlung?<\/h2>\n
Schauen wir uns zuerst an, was VBA von sich aus tut, wenn ein Laufzeitfehler auftritt.<\/p>\n
Die Prozedur DateiOhneSchutz<\/b> aus folgendem Listing 1 öffnet eine Textdatei, die es gar nicht gibt:<\/p>\n Existiert die Datei nicht, bricht VBA mit dem Laufzeitfehler 53<\/b> ab und zeigt den Dialog aus Bild 1 – mit einer Meldung, die dem Anwender nichts sagt, und mit den Schaltflächen Beenden<\/b> und Debuggen<\/b>, die in einer ausgelieferten Anwendung beide nichts zu suchen haben.<\/p>\n Bild 1: Der Standarddialog von VBA beim Laufzeitfehler 53 – so etwas darf der Anwender nie zu sehen bekommen<\/span><\/b><\/p>\n Klicken wir auf Debuggen<\/b>, sehen wir die farbig hinterlegte fehlerhafte Anweisung (siehe Bild 2).<\/p>\n Bild 2: Anschließend wird die fehlerhafte Zeile farbig hinterlegt.<\/span><\/b><\/p>\n Zwei Dinge sind hier schiefgelaufen: Der Anwender bekommt keine verständliche Meldung, und die Prozedur bricht mitten im Ablauf ab. In anderen Prozeduren können dadurch bereits geöffnete Dateien, Recordsets oder andere Ressourcen unaufgeräumt zurückbleiben.<\/p>\n VBA kennt genau drei Varianten der On Error<\/b>-Anweisung, und sie bestimmen, was bei einem Laufzeitfehler geschieht:<\/p>\n Ein Punkt, der später noch wichtig wird: On Error<\/b> gilt immer nur innerhalb der Prozedur, in der es steht. Eine globale Fehlerbehandlung gibt es in VBA nicht – jede Prozedur muss sich selbst schützen.<\/p>\n Das bewährteste Muster sieht so aus: Am Anfang der Prozedur leiten wir auftretende Fehler auf eine Sprungmarke um, am Ende springen wir über den Fehlerblock hinweg. Bauen wir unser Beispiel entsprechend um – das Ergebnis heißt DateiMitSchutz<\/b> und steht in folgendem Listing:<\/p>\n Der Ablauf im Einzelnen: On Error GoTo ErrHandler<\/b> aktiviert die Fehlerbehandlung – ab hier springt VBA bei einem Laufzeitfehler zur Marke ErrHandler<\/b>.<\/p>\n Läuft alles glatt, erreichen wir ExitHere<\/b> und verlassen die Prozedur mit Exit Sub<\/b>. Tritt dagegen ein Fehler auf, landen wir im ErrHandler<\/b>, zeigen eine Meldung an und springen mit Resume ExitHere<\/b> zur Austrittsmarke.<\/p>\n Warum eigentlich Resume ExitHere<\/b> und nicht einfach GoTo ExitHere<\/b>? Der Unterschied sieht nach Geschmackssache aus, ist aber entscheidend: Resume<\/b> meldet VBA, dass der Fehler behandelt wurde. Erst danach kann überhaupt wieder ein Fehler abgefangen werden. Mit GoTo<\/b> bleibt die Prozedur dagegen im Fehlerzustand.<\/p>\n Das ist eine Behauptung – schauen wir sie uns an, statt sie zu glauben. Die Prozedur GoToStattResume<\/b> in macht den Unterschied im Direktbereich sichtbar:<\/p>\n Rufe die Prozedur im Direktbereich mit GoToStattResume<\/b> auf. Die Ausgabe zeigt in beiden Zeilen die 53<\/b> – der Fehler ist in ExitHere<\/b> also immer noch aktiv (siehe Bild 3).<\/p>\n Bild 3: Der Direktbereich zeigt es schwarz auf weiß: Nach GoTo steht Err.Number immer noch auf 53<\/span><\/b><\/p>\n Tauschst Du das GoTo ExitHere<\/b> gegen Resume ExitHere<\/b>, steht in der zweiten Zeile eine 0<\/b>: Der Fehler gilt als erledigt.<\/p>\n Und genau daran hängt die Praxisfolge – ein weiterer Fehler in der Aufräumlogik würde in der GoTo<\/b>-Variante nicht mehr abgefangen, sondern führte direkt zum Standarddialog.<\/p>\n Das Err<\/b>-Objekt ist immer verfügbar und beschreibt den zuletzt aufgetretenen Fehler. Wichtig sind drei Eigenschaften:<\/p>\n Dazu kommen zwei Methoden. Clear<\/b> setzt Number <\/b>auf 0 <\/b>und leert die übrigen Eigenschaften des Err<\/b>-Objekts. Beim Verlassen einer Prozedur und durch eine Resume<\/b>-Anweisung wird der Fehlerzustand ebenfalls zurückgesetzt. Wenn wir mehrere Operationen unter On Error Resume Next <\/b>prüfen, sollten wir Err.Clear <\/b>dagegen ausdrücklich zwischen den Operationen aufrufen.<\/p>\n Und Raise<\/b> löst einen Laufzeitfehler aus – damit erzeugen wir gleich gezielt eigene Fehler.<\/p>\n Aus dem Fehlerblock heraus haben wir drei Möglichkeiten, den Programmfluss fortzusetzen. Resume<\/b> führt die fehlerauslösende Zeile erneut aus – sinnvoll nur dann, wenn wir die Ursache im Fehlerblock tatsächlich beseitigt haben.<\/p>\n Resume Next<\/b> macht mit der Zeile danach weiter, wenn der Fehler tolerierbar ist. Und Resume Marke<\/b> springt zu einer bestimmten Marke, was die häufigste Variante ist: Genau so kommen wir geordnet zur Austrittsmarke.<\/p>\n Wie Resume gezielt eingesetzt werden kann, zeigt das folgende Listing. Die Prozedur OrdnerAnlegen<\/b> legt einen Ordner an, dessen übergeordneter Ordner womöglich noch fehlt – in dem Fall legen wir diesen an und versuchen es erneut:<\/p>\n Aufgerufen wird das etwa so:<\/p>\n Zwei Stolpersteine stecken hier drin: Erstens legt die Korrektur nur eine Ebene an – fehlen zwei, scheitert schon das MkDir<\/b> im Fehlerblock. Ein weiterer Fehler innerhalb eines bereits aktiven Fehlerhandlers kann von demselben Handler nicht erneut behandelt werden. Gibt es keinen übergeordneten aktiven Handler, erscheint der VBA-Standarddialog. Zweitens droht eine Endlosschleife, wenn die Korrektur das Problem gar nicht löst: Resume<\/b> wiederholt dann immer wieder dieselbe Zeile. Wie wir das mit einem Zähler entschärfen, sehen wir weiter unten.<\/p>\n On Error Resume Next<\/b> hat einen schlechten Ruf, und der ist meistens verdient: Wer es als Allzweckwaffe einsetzt, verschluckt Fehler stillschweigend und macht die Anwendung unberechenbar. Es gibt aber Situationen, in denen es genau das richtige Werkzeug ist – nämlich dann, wenn wir den Fehlerstatus einer einzelnen Operation bewusst abfragen wollen.<\/p>\n Ein typischer Fall: Wir wollen wissen, ob ein Eintrag in einer Collection<\/b> existiert. Eine Exists<\/b>-Methode gibt es dort nicht, also nutzen wir den Zugriffsfehler als Prüfmittel. Das erledigt die Funktion ExistiertInCollection<\/b>. Sie erwartet die zu prüfende Collection<\/b> und den Schlüssel und liefert True<\/b> oder False<\/b> zurück:<\/p>\n Das Muster dahinter ist immer dasselbe: On Error Resume Next<\/b> einschalten, die kritische Anweisung ausführen, Err.Number<\/b> prüfen und sofort danach mit On Error GoTo 0<\/b> zurücksetzen – oder, wenn die Prozedur eine eigene Fehlerbehandlung hat, mit On Error GoTo ErrHandler<\/b> wieder auf die reguläre Marke umleiten. Ausprobieren lässt sich das wie folgt:<\/p>\n Entscheidend ist die Disziplin: On Error Resume Next<\/b> sollte nie länger als zwei oder drei Zeilen aktiv sein. Alles andere ist ein Wartungsrisiko.<\/p>\n In vielen Prozeduren müssen wir am Ende Ressourcen freigeben – Recordsets schließen, Objektvariablen auf Nothing<\/b> setzen, Dateien schließen. Diese Arbeit darf der Fehlerblock nicht überspringen.<\/p>\n Deshalb bekommt die Prozedur eine gemeinsame Austrittsmarke, die sowohl der reguläre Ablauf als auch der Fehlerblock anspringt. Wie das aussieht, zeigt die Prozedur DatenExportieren<\/b> (siehe Listing 1). Sie liest die Tabelle tblKunden<\/b> aus und schreibt die Namen in eine Textdatei.<\/p>\n Listing 1: Beispiel für das Exit-Pattern<\/span><\/b><\/p>\n Der Aufruf sieht so aus:<\/p>\n Beachte die Prüfung If Not rst Is Nothing<\/b>: Der Fehler kann auch schon vor dem OpenRecordset<\/b> auftreten – dann wäre rst<\/b> noch Nothing<\/b>, und ausgerechnet das Aufräumen würde einen neuen Fehler auslösen. Ob die Datei tatsächlich geöffnet wurde, halten wir in der Variablen bolDateiOffen <\/b>fest. Eine von FreeFile <\/b>gelieferte Dateinummer allein beweist noch nicht, dass die anschließende Open<\/b>-Anweisung erfolgreich war.<\/p>\n Nicht jeder Fehler gehört dort behandelt, wo er auftritt. In einer sauber aufgebauten Anwendung gibt es Schichten: Datenzugriff, Geschäftslogik und Benutzeroberfläche. Eine Datenzugriffsfunktion soll dem Aufrufer melden, dass etwas schiefgelaufen ist – aber keine MsgBox<\/b> anzeigen. Dafür ist Err.Raise<\/b> da.<\/p>\n Die Funktion KundeNachID<\/b> liest zu einer Kundennummer den Namen aus tblKunden<\/b>. Findet sie keinen Datensatz, löst sie selbst einen Fehler aus; tritt ein anderer Fehler auf, räumt sie auf und reicht ihn nach oben weiter (siehe Listing 2).<\/p>\n Listing 2: Fehler weiterreichen mit Err.Raise<\/span><\/b><\/p>\n Hier geschehen zwei verschiedene Dinge. Findet die Abfrage keinen Kunden, erzeugen wir mit Err.Raise<\/b> einen eigenen Fehler.<\/p>\n Seine Nummer berechnen wir als vbObjectError + 1001<\/b> – die Konstante vbObjectError<\/b> ist der dafür vorgesehene Offset, und der Bereich von vbObjectError + 512<\/b> bis vbObjectError + 65535<\/b> steht uns für eigene Zwecke zur Verfügung. Tritt dagegen irgendein anderer Fehler auf, räumen wir im ErrHandler<\/b> auf und lösen ihn danach mit den Originaldaten erneut aus. Für den Aufrufer verhält sich der weitergereichte Fehler wie ein gewöhnlicher Laufzeitfehler. Da wir Nummer, Quelle und Beschreibung übernehmen, bleiben die ursprünglichen Fehlerinformationen erhalten.<\/p>\n Der Umweg über die drei Variablen lngNummer<\/b>, strQuelle<\/b> und strText<\/b> ist kein Zierrat. Wir würden die Werte gern direkt aus dem Err<\/b>-Objekt an Err.Raise<\/b> übergeben – aber zwischen Fehlerblock und Weiterreichen liegt das Aufräumen, und das kann das Err<\/b>-Objekt verändern. Deshalb sichern wir die drei Werte, bevor wir irgendetwas anderes tun. Auf der anderen Seite steht das Formular frmKundensuche<\/b>. Seine Ereignisprozedur btnSuchen_Click<\/b> aus unterscheidet, ob der Kunde schlicht nicht existiert oder ob etwas Unerwartetes passiert ist:<\/p>\n Damit haben wir eine saubere Trennung: Die Datenzugriffsfunktion meldet, was schiefgelaufen ist – das Formular entscheidet, was der Anwender davon zu sehen bekommt.<\/p>\n Das Err<\/b>-Objekt sagt uns, was schiefgelaufen ist – aber nicht, wo. Bei einer Prozedur mit zwanzig Zeilen kommen wir noch durch Nachdenken darauf; bei einer mit zweihundert wird daraus eine Suchaktion. Dabei gibt es dafür längst eine Funktion, die kaum jemand kennt, weil sie in IntelliSense nicht angeboten wird und in der täglichen VBA-Programmierung nur selten auftaucht: Erl<\/b>.<\/p>\n Erl<\/b> liefert die Nummer der Zeile, in der der Fehler aufgetreten ist. Der Haken daran ist ein Erbstück aus den BASIC-Zeiten: Das funktioniert nur, wenn der Code tatsächlich Zeilennummern trägt. Ohne Nummerierung liefert Erl<\/b> schlicht 0<\/b> – und deshalb halten viele die Funktion für nutzlos, obwohl sie das Gegenteil ist.<\/p>\n Schauen wir es uns an. Die Prozedur ZeileErmitteln<\/b> ist unser Dateibeispiel von weiter oben, diesmal mit nummerierten Zeilen:<\/p>\n Der Aufruf von ZeileErmitteln<\/b> im Direktbereich meldet Fehler 53 in Zeile 30<\/b> – und damit genau die Zeile mit dem Open<\/b>. Die Nummern schreiben wir an den Zeilenanfang, gefolgt von mindestens einem Leerzeichen. Sie müssen nur innerhalb einer Prozedur eindeutig sein, jede weitere Prozedur darf also wieder bei 10<\/b> beginnen.<\/p>\n Und Zehnerschritte haben sich eingebürgert, damit später noch Zeilen dazwischenpassen. Die On Error<\/b>-Zeile und die Sprungmarken bleiben üblicherweise ohne Nummer – dort kann ohnehin kein Laufzeitfehler auftreten.<\/p>\n Jetzt der Stolperstein, und der ist heimtückisch: Nummerieren wir nur einen Teil der Anweisungen, bekommen wir trotzdem eine Zahl – nur die falsche. Das folgende Listing führt das vor:<\/p>\n Diese Prozedur meldet Fehler 53 in Zeile 10<\/b> – obwohl der Fehler zwei Anweisungen später passiert ist. Der Grund ist einfach: Erl<\/b> kennt nur nummerierte Zeilen und meldet deshalb die letzte, die vor dem Fehler ausgeführt wurde.<\/p>\n Halbe Nummerierung ist damit schlechter als gar keine: Eine 0<\/b> erkennen wir als “keine Information”, eine falsche Zeilennummer schickt uns dagegen an die falsche Stelle.<\/p>\n Ein zweiter Punkt gehört dazu: Erl <\/b>steht nur während der Behandlung des aktuellen Fehlers zuverlässig zur Verfügung. Insbesondere nach einer Resume<\/b>-Anweisung oder nach dem Verlassen der Prozedur ist der Wert nicht mehr nutzbar.<\/p>\n Wir lesen den Wert deshalb gleich in der ersten Zeile des Fehlerblocks aus – wer erst aufräumt und dann Erl<\/b> abfragt, bekommt eine 0<\/b> zurück. Bleibt die Frage, wer all diese Nummern tippen soll. Von Hand ist das bei fünf Prozeduren noch machbar, bei fünfzig jedoch kaum noch praktikabel – und genau deshalb führt der Weg zu Erl<\/b> in der Praxis über ein Werkzeug, das die Nummerierung automatisch einfügt und vor der Weitergabe wieder entfernt. Dazu mehr im Ausblick.<\/p>\n In einer produktiven Anwendung reicht eine MsgBox<\/b> nicht aus. Fehler gehören protokolliert, mit Zeitstempel, Benutzer, Prozedurname, Modulname, Fehlerdaten – und jetzt auch mit der Zeilennummer aus Erl<\/b>. Dafür legen wir die Tabelle tblFehlerLog<\/b> mit den folgenden Feldern an:<\/p>\n Den Entwurf der Tabelle sehen wir in Bild 4.<\/p>\n Bild 4: Entwurf der Protokolltabelle<\/span><\/b><\/p>\n Die zugehörige Prozedur heißt FehlerProtokollieren<\/b> und ist bewusst schlank gehalten. Sie erwartet den Prozedur- und den Modulnamen, die Fehlernummer, die Beschreibung und die Zeilennummer und schreibt daraus einen Datensatz (siehe Listing 3).<\/p>\nPublic Sub <\/span>DateiOhneSchutz()\r\n Dim <\/span>intFile As Integer<\/span>\r\n intFile = FreeFile\r\n Open \"C:\\NichtVorhanden.txt\" _\r\n For Input As <\/span>#intFile\r\n Close #intFile\r\nEnd Sub<\/span><\/pre>\n![\"Der](\"..\/fileadmin\/_temp_\/2026_03\/pic_509_001.png\")
<\/p>\n![\"Anschließend](\"..\/fileadmin\/_temp_\/2026_03\/pic_509_002.png\")
<\/p>\nDie drei Formen von On Error<\/h2>\n
\n
Das Standard-Pattern: On Error GoTo<\/h2>\n
Public Sub <\/span>DateiMitSchutz()\r\n On Error GoTo<\/span> ErrHandler\r\n Dim <\/span>intFile As Integer<\/span>\r\n intFile = FreeFile\r\n Open \"C:\\NichtVorhanden.txt\" For Input As <\/span>#intFile\r\n ' ... Datei verarbeiten ...\r\n Close #intFile\r\nExitHere:\r\n Exit Sub<\/span>\r\nErrHandler:\r\n MsgBox<\/span> \"Fehler \" & Err.Number & \": \" _\r\n & Err.Description, vbCr<\/span>itical, \"DateiMitSchutz\"\r\n Resume ExitHere\r\nEnd Sub<\/span><\/pre>\nDen Fehlerzustand sichtbar machen<\/h2>\n
Public Sub <\/span>GoToStattResume()\r\n On Error GoTo<\/span> ErrHandler\r\n Err.Raise 53\r\nExitHere:\r\n Debug.Print<\/span> \"In ExitHere: Err.Number = \" & Err.Number\r\n Exit Sub<\/span>\r\nErrHandler:\r\n Debug.Print<\/span> \"Im Handler: Err.Number = \" & Err.Number\r\n GoTo ExitHere\r\nEnd Sub<\/span><\/pre>\n![\"Der](\"..\/fileadmin\/_temp_\/2026_03\/pic_509_003.png\")
<\/p>\nDas Err-Objekt im Detail<\/h2>\n
\n
Resume – drei Varianten<\/h2>\n
Public Sub <\/span>OrdnerAnlegen(strPfad As String<\/span>)\r\n On Error GoTo<\/span> ErrHandler\r\n MkDir strPfad\r\nExitHere:\r\n Exit Sub<\/span>\r\nErrHandler:\r\n If <\/span>Err.Number = 76 Then<\/span>\r\n 'Pfad nicht gefunden: \r\n 'übergeordneten Ordner anlegen\r\n MkDir Left<\/span>(strPfad, InStrRev<\/span>(strPfad, \"\\\") - 1)\r\n Resume\r\n Else<\/span>\r\n MsgBox<\/span> \"Fehler \" & Err.Number & \": \" _\r\n & Err.Description\r\n Resume ExitHere\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\nOrdnerAnlegen \"C:\\Temp\\Export\\Kunden\"<\/pre>\n
On Error Resume Next – gezielt und sparsam<\/h2>\n
Public Function <\/span>ExistiertInCollection(col As <\/span>Collection, _\r\n strKey As String<\/span>) As Boolean<\/span>\r\n Dim <\/span>varDummy As Variant<\/span>\r\n On Error Resume Next<\/span>\r\n varDummy = col(strKey)\r\n ExistiertInCollection = (Err.Number = 0)\r\n On Error GoTo<\/span> 0\r\nEnd Function<\/span><\/pre>\nDim <\/span>col As <\/span>New<\/span> Collection\r\ncol.Add \"Wert\", \"Schluessel\"\r\nDebug.Print<\/span> ExistiertInCollection(col, \"Schluessel\")\r\n'Liefert True<\/span>\r\nDebug.Print<\/span> ExistiertInCollection(col, \"Fehlt\") \r\n'Liefert False<\/span><\/pre>\nAufräumen bei Fehlern: das Exit-Pattern<\/h2>\n
Public Sub <\/span>DatenExportieren(strPfad As String<\/span>)\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>intFile As Integer<\/span>\r\n Dim <\/span>bolDateiOffen As Boolean<\/span>\r\n On Error GoTo<\/span> ErrHandler\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT KundenName FROM tblKunden\", dbOpenSnapshot)\r\n intFile = FreeFile\r\n Open strPfad For Output As <\/span>#intFile\r\n bolDateiOffen = True<\/span>\r\n Do Until rst.EOF\r\n Print #intFile, rst!KundenName\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\nExitHere:\r\n If <\/span>bolDateiOffen Then<\/span>\r\n Close #intFile\r\n bolDateiOffen = False<\/span>\r\n End If<\/span>\r\n If <\/span>Not<\/span> rst Is Nothing Then<\/span>\r\n rst.Close\r\n Set<\/span> rst = Nothing\r\n End If<\/span>\r\n Set<\/span> db = Nothing\r\n Exit Sub<\/span>\r\nErrHandler:\r\n MsgBox<\/span> \"Fehler in DatenExportieren:\" & vbCrLf<\/span> _\r\n & Err.Number & \" - \" & Err.Description, _\r\n vbCr<\/span>itical\r\n Resume ExitHere\r\nEnd Sub<\/span><\/pre>\nDatenExportieren \"C:\\Temp\\Kunden.txt\"<\/pre>\n
Fehler weiterreichen mit Err.Raise<\/h2>\n
Public Function <\/span>KundeNachID(lngID As Long<\/span>) As String<\/span>\r\n On Error GoTo<\/span> ErrHandler\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>lngNummer As Long<\/span>\r\n Dim <\/span>strQuelle As String<\/span>\r\n Dim <\/span>strText As String<\/span>\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT Firma FROM tblKunden WHERE KundeID = \" & lngID, dbOpenSnapshot)\r\n If <\/span>rst.EOF Then<\/span>\r\n Err.Raise vbObjectError + 1001, \"KundeNachID\", \"Kein Kunde mit der ID \" & lngID & \" gefunden.\"\r\n End If<\/span>\r\n KundeNachID = rst!Firma\r\nExitHere:\r\n If <\/span>Not<\/span> rst Is Nothing Then<\/span>\r\n rst.Close\r\n Set<\/span> rst = Nothing\r\n End If<\/span>\r\n Set<\/span> db = Nothing\r\n Exit Function<\/span>\r\nErrHandler:\r\n ' Fehlerdaten sichern, bevor wir aufräumen\r\n lngNummer = Err.Number\r\n strQuelle = Err.Source\r\n strText = Err.Description\r\n If <\/span>Not<\/span> rst Is Nothing Then<\/span>\r\n rst.Close\r\n Set<\/span> rst = Nothing\r\n End If<\/span>\r\n Set<\/span> db = Nothing\r\n Err.Raise lngNummer, strQuelle, strText\r\nEnd Function<\/span><\/pre>\nPublic Sub <\/span>Test_KundeNachID()\r\n On Error GoTo<\/span> ErrHandler\r\n Dim <\/span>strFirma As String<\/span>\r\n strFirma = KundeNachID(1)\r\n MsgBox<\/span> \"Firma: \" & strFirma\r\nExitHere:\r\n Exit Sub<\/span>\r\nErrHandler:\r\n If <\/span>Err.Number = vbObjectError + 1001 Then<\/span>\r\n MsgBox<\/span> \"Nicht gefunden.\"\r\n Resume ExitHere\r\n Else<\/span>\r\n MsgBox<\/span> \"Unerwarteter Fehler: \" & Err.Description, vbCr<\/span>itical\r\n Resume ExitHere\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\nDie fehlerhafte Zeile finden: Erl<\/h2>\n
Public Sub <\/span>ZeileErmitteln()\r\n On Error GoTo<\/span> ErrHandler\r\n10 Dim intFile As Integer<\/span>\r\n20 intFile = FreeFile\r\n30 Open \"C:\\NichtVorhanden.txt\" For Input As <\/span>#intFile\r\n40 Close #intFile\r\nExitHere:\r\n Exit Sub<\/span>\r\nErrHandler:\r\n Debug.Print<\/span> \"Fehler \" & Err.Number & \" in Zeile \" & Erl\r\n Resume ExitHere\r\nEnd Sub<\/span><\/pre>\nPublic Sub <\/span>TeilweiseNummeriert()\r\n On Error GoTo<\/span> ErrHandler\r\n10 Dim intFile As Integer<\/span>\r\n intFile = FreeFile\r\n Open \"C:\\NichtVorhanden.txt\" For Input As <\/span>#intFile\r\nExitHere:\r\n Exit Sub<\/span>\r\nErrHandler:\r\n Debug.Print<\/span> \"Fehler \" & Err.Number & \" in Zeile \" & Erl\r\n Resume ExitHere\r\nEnd Sub<\/span><\/pre>\nFehler in eine Tabelle protokollieren<\/h2>\n
\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2026_03\/pic_509_004.png\")
<\/p>\nPublic Sub <\/span>FehlerProtokollieren(strProzedur As String<\/span>, strModul