Ziel: Fehler verstehen, reproduzieren, sauber beheben

Access schmeißt Dir gerne mal ein „Laufzeitfehler 13“ um die Ohren.
Oder: „Datensatz kann nicht gespeichert werden“.
Wenn Du wissen willst, was wirklich los ist – musst Du debuggen.
Nicht raten.

Variante 1: Fehlerprozedur zentral nutzen

Public Sub Fehlerbehandlung(prozedur As String, fehlerNr As Long, beschreibung As String)
    MsgBox "Fehler in " & prozedur & vbCrLf & _
           "Fehlernummer: " & fehlerNr & vbCrLf & _
           "Beschreibung: " & beschreibung, vbCritical
End Sub

Dann in jedem Modul:

Sub Beispiel()
On Error GoTo Fehler

' … dein Code …

Exit Sub
Fehler:
    Call Fehlerbehandlung("Beispiel", Err.Number, Err.Description)
End Sub

So erkennst Du, wo es knallt.

Variante 2: Debug.Print für Zwischenstände

Debug.Print "Aktueller Wert:", Me.ArtikelID, Me.Preis

Das landet im Direktfenster (Strg+G) – ohne MessageBox.

Hilft bei Schleifen, Bedingungen, SQL-Ausdrücken.

Variante 3: SQL-Strings prüfen vor Ausführung

Dim sql As String
sql = "SELECT * FROM tblKunde WHERE Name = '" & Me.txtName & "'"
Debug.Print sql

Ergebnis im Direktfenster copy-pasten und im Abfrageeditor ausführen.
So findest Du Tippfehler, fehlende Hochkommas oder ungültige Datumsformate.

Variante 4: On Error Resume Next – nur gezielt

On Error Resume Next
Kill "C:\Temp\datei.csv"
If Err.Number <> 0 Then
    Debug.Print "Löschen fehlgeschlagen:", Err.Description
    Err.Clear
End If

Nie als Standard einsetzen. Nur da, wo Du Fehler erwartest.

Variante 5: Abfragen mit Parametern testen

Kein DLookup("*", "tblKunde", "ID=" & Me.ID)
Sondern:

Dim rs As DAO.Recordset
Set rs = CurrentDb.OpenRecordset("SELECT * FROM tblKunde WHERE ID=" & Me.ID)

Dann Zeile für Zeile prüfen, was drin ist.

Variante 6: Events im Formular checken

Formulare reagieren auf:

• BeforeUpdate
• AfterUpdate
• OnCurrent
• OnDirty

Wenn Du nicht sicher bist, wann was läuft:

Private Sub Form_Current()
    Debug.Print "Form_Current: " & Now()
End Sub

Oder bei Kombifeld:

Private Sub cboKunde_AfterUpdate()
    Debug.Print "Kunde geändert: " & Me.cboKunde
End Sub

Variante 7: Application.Echo zur Fehleranalyse

Application.Echo False
' Aktionen
Application.Echo True

Verhindert Flackern und stört Debuggen weniger.
Achtung: Immer True am Ende – sonst bleibt Access „blind“.

Variante 8: Datenbankfenster und Systemobjekte anzeigen

• Systemtabellen einblenden → Optionen → Navigationsbereich
• z. B. MSysObjects, MSysRelationships

Hilft beim Prüfen: wurde Tabelle wirklich gelöscht, verknüpft, aktualisiert?

Variante 9: Breakpoints und „Schrittweise ausführen“

• Haltepunkt setzen mit F9
• Mit F8 Schritt für Schritt durch Code
• Werte mit Maus anzeigen
• Watch-Fenster nutzen für komplexe Bedingungen

Funktioniert zuverlässig – solange kein OnError das Ganze unterdrückt.

Variante 10: Protokolltabelle für Fehler anlegen

Public Sub LogFehler(modul As String, meldung As String)
    CurrentDb.Execute "INSERT INTO tblFehlerLog (Zeitpunkt, Modul, Meldung) VALUES (Now(), '" & modul & "', '" & Replace(meldung, "'", "''") & "')"
End Sub

In der Fehlerbehandlung:

LogFehler "frmKundenSpeichern", Err.Number & ": " & Err.Description

Hilft Dir bei produktiven Systemen mit mehreren Usern.

Best Practices

• kein Code ohne On Error
• nie Resume Next als globale Lösung
• jede SQL-Zeile vor dem Ausführen loggen oder anzeigen
• keine MessageBox in Schleifen
• Direktfenster regelmäßig aufräumen
• immer mit festen Prozedurnamen arbeiten („ModulX“)
• für wiederkehrende Fehler (z. B. „Datensatz gesperrt“) gezielte Prüfung einbauen

Fazit für Entwickler

Fehler sind nicht schlimm – solange Du weißt, wo sie herkommen.
Access ist alt, aber mit Debug.Print, On Error und etwas Struktur kannst Du alles nachvollziehen.