Wenn alles klickbar ist, aber nichts nachvollziehbar

Makros in Access sind schnell gebaut.
Ein Klick hier, ein Ereignis da – fertig.

Für kleine Anwendungen reicht das.
Aber bei mehr als zwei Formularen wird’s unübersichtlich.
Kein Debug. Keine Fehlerbehandlung. Kein Versionsvergleich.

Dann fängt’s an zu nerven. Und zu schaden.

Warum Makros problematisch werden

  • Kein Debugging möglich
  • Keine saubere Fehlerbehandlung
  • Kaum wiederverwendbar
  • Schwer dokumentierbar
  • Mühsam bei Migration
  • Nicht git-freundlich

Ich nenn das: Klick-Code ohne Kontrolle.

Was ich stattdessen nutze: Sauberes VBA

  • Ereignisse direkt im Code
  • Zentrale Logikfunktionen
  • Fehlerbehandlung mit Logging
  • Aufruf mit Parametern
  • Klarer Aufbau, testbar, versionssicher

Beispiel: Vorher – Makro beim Button

Makro btnSpeichern_Click macht:

  • Datensatz speichern
  • Nachricht anzeigen
  • Formular schließen

Makrodefinition:

Befehl:Datensatz speichern  
Befehl:Meldung anzeigen "Gespeichert"  
Befehl:Formular schließen

Du kannst das nicht debuggen. Nicht parametrisieren. Nicht testen.

Besser: VBA statt Makro

Private Sub btnSpeichern_Click()
    On Error GoTo Fehler
    
    If Me.Dirty Then Me.Dirty = False
    
    MsgBox "Datensatz gespeichert.", vbInformation
    DoCmd.Close acForm, Me.Name
    Exit Sub

Fehler:
    MsgBox "Fehler: " & Err.Description, vbCritical
    ' Optional: Logging
End Sub

Klar, nachvollziehbar, erweiterbar.

Zentrale Logik: Beispiel Kundenspeicherung

Public Function KundeSpeichern(Kundenname As String, PLZ As String) As Boolean
    On Error GoTo Fehler

    Dim db As DAO.Database
    Set db = CurrentDb
    db.Execute "INSERT INTO Kunden (Name, PLZ) VALUES ('" & Kundenname & "', '" & PLZ & "')", dbFailOnError

    KundeSpeichern = True
    Exit Function

Fehler:
    Call FehlerLoggen("KundeSpeichern", Err.Number, Err.Description)
    KundeSpeichern = False
End Function

Und der Aufruf im Formular:

Private Sub btnKundeSpeichern_Click()
    If KundeSpeichern(Me.txtName, Me.txtPLZ) Then
        MsgBox "Erfolgreich gespeichert."
    Else
        MsgBox "Fehler beim Speichern.", vbCritical
    End If
End Sub

So trennst Du UI und Logik. Und das ist entscheidend.

Tabelle: Makro vs. VBA

KriteriumMakroVBA
Fehlerbehandlungkeinemit On Error möglich
Wiederverwendbarkeitgeringhoch
Debuggingnicht möglichvollumfänglich
Versionskontrolleschlechtgut mit Textdateien
Sicherheitbei AutoExec kritischmit digitalem Zertifikat absicherbar
Komplexität handhabbarnur sehr eingeschränktdurch Struktur und Kapselung möglich

Mein Migrationsplan von Makro zu VBA

  1. Alle AutoExec- und Formularmakros identifizieren
  2. Makros in VBA umwandeln (Rechtsklick > Zu VBA konvertieren)
  3. Code strukturieren: Modul für Logik, Modul für Datenzugriff
  4. Gemeinsame Routinen in Standardmodule verschieben
  5. Fehlerbehandlung und Logging ergänzen
  6. Makros löschen oder deaktivieren

Makros in neuen Projekten? Verwende ich nicht mehr.

Mein Setup für robuste Access-Anwendungen

BereichUmsetzung
Benutzerinteraktionausschließlich über VBA
Datenzugriffgekapselt in DAO-Funktionen
Loggingzentral in Tabelle Fehlerlog
Wiederverwendungüber Funktionsbibliotheken (bas_*.)
Fehlerhandlingmit On Error, klaren Codes
Dokumentationim Code, automatisiert auslesbar

Makros sind gut für’s erste Ergebnis.

Aber für den zweiten Klick brauchst Du sauberes VBA.

Dann weißt Du, was passiert – und warum.
Und Du hast endlich Kontrolle über Dein Access-Projekt.

Categories:

Tags:

No responses yet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert