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
Kriterium | Makro | VBA |
---|---|---|
Fehlerbehandlung | keine | mit On Error möglich |
Wiederverwendbarkeit | gering | hoch |
Debugging | nicht möglich | vollumfänglich |
Versionskontrolle | schlecht | gut mit Textdateien |
Sicherheit | bei AutoExec kritisch | mit digitalem Zertifikat absicherbar |
Komplexität handhabbar | nur sehr eingeschränkt | durch Struktur und Kapselung möglich |
Mein Migrationsplan von Makro zu VBA
- Alle AutoExec- und Formularmakros identifizieren
- Makros in VBA umwandeln (Rechtsklick > Zu VBA konvertieren)
- Code strukturieren: Modul für Logik, Modul für Datenzugriff
- Gemeinsame Routinen in Standardmodule verschieben
- Fehlerbehandlung und Logging ergänzen
- Makros löschen oder deaktivieren
Makros in neuen Projekten? Verwende ich nicht mehr.
Mein Setup für robuste Access-Anwendungen
Bereich | Umsetzung |
---|---|
Benutzerinteraktion | ausschließlich über VBA |
Datenzugriff | gekapselt in DAO-Funktionen |
Logging | zentral in Tabelle Fehlerlog |
Wiederverwendung | über Funktionsbibliotheken (bas_*. ) |
Fehlerhandling | mit On Error , klaren Codes |
Dokumentation | im 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.
No responses yet