Ereignisse verstehen

Access ist ereignisgesteuert. Dein Code läuft nicht von oben nach unten durch, sondern wartet auf etwas: der Nutzer klickt einen Button, wechselt den Datensatz, schließt ein Formular. Genau in diesem Moment ruft Access die passende Ereignisprozedur auf — und dein Code springt an.

Wer versteht, welche Ereignisse es gibt und in welcher Reihenfolge sie feuern, schreibt Formulare, die sich genau richtig verhalten: Prüfungen im richtigen Moment, Vorbelegungen zur richtigen Zeit, saubere Abbrüche bei falschen Eingaben.

Was ist ein Ereignis?

Ein Ereignis ist eine Aktion, die Access erkennt: ein Klick, ein Tastendruck, das Öffnen eines Formulars, das Verlassen eines Feldes. Jedes Formular, jeder Bericht und jedes Steuerelement hat eine Liste möglicher Ereignisse.

Zu jedem Ereignis kannst du eine Ereignisprozedur hinterlegen — eine Sub, die genau dann läuft. Du findest die Ereignisse im Eigenschaftenblatt des Steuerelements unter dem Reiter Ereignis.

Eine Ereignisprozedur anlegen

Klick im Eigenschaftenblatt neben das gewünschte Ereignis (z. B. Beim Klicken), wähle [Ereignisprozedur] und dann den Button mit den drei Punkten .... Access öffnet den VBE und legt das Gerüst an:

Private Sub cmdSpeichern_Click()
    MsgBox "Button wurde geklickt!"
End Sub

Der Name folgt einem festen Muster: Steuerelementname_Ereignis. Access verknüpft die Prozedur automatisch über diesen Namen — du darfst ihn nicht frei umbenennen.

Merke: Ereignisprozeduren sind immer Private. Sie gehören zum Klassenmodul des Formulars und werden nicht von außen aufgerufen, sondern von Access selbst.

Wichtige Formular-Ereignisse

Diese vier brauchst du ständig:

Beim Laden nutzt du für Vorbereitungen — Standardwerte setzen, Comboboxen füllen, Überschriften anpassen:

Private Sub Form_Load()
    Me.txtDatum = Date
    Me.Caption = "Auftrag erfassen — " & Format(Date, "dd.mm.yyyy")
End Sub

Beim Aktuellwerden läuft bei jedem Datensatzwechsel. Ideal, um abhängige Anzeigen zu aktualisieren:

Private Sub Form_Current()
    ' Statusfeld je nach Datensatz einfärben
    If Me.Bezahlt = True Then
        Me.txtStatus.BackColor = vbGreen
    Else
        Me.txtStatus.BackColor = vbRed
    End If
End Sub

Eingaben prüfen mit Vor Aktualisierung und Cancel

Das mächtigste Ereignis für Datenqualität ist Beim Vor Aktualisierung (BeforeUpdate). Es feuert, bevor Access speichert, und liefert dir den Parameter Cancel. Setzt du Cancel = True, bricht Access das Speichern ab — der Datensatz bleibt im Bearbeitungsmodus.

Private Sub Form_BeforeUpdate(Cancel As Integer)
    If Nz(Me.Kundenname, "") = "" Then
        MsgBox "Bitte einen Kundennamen eingeben.", vbExclamation
        Cancel = True          ' Speichern abbrechen
        Me.Kundenname.SetFocus ' zurück ins Feld
    End If
End Sub

Solange die Prüfung nicht erfüllt ist, kommt der Nutzer nicht aus dem Datensatz heraus. Genau so erzwingst du Pflichtfelder mit eigener Logik.

Steuerelement-Ereignisse

Nicht nur Formulare, auch einzelne Felder und Buttons haben Ereignisse:

AfterUpdate ist der Klassiker für abhängige Berechnungen: Sobald der Nutzer die Menge ändert, aktualisierst du den Gesamtpreis.

Private Sub txtMenge_AfterUpdate()
    Me.txtGesamt = Nz(Me.txtMenge, 0) * Nz(Me.txtEinzelpreis, 0)
End Sub

Tipp: Für Prüfungen an einem einzelnen Feld nimm lieber dessen BeforeUpdate (auch dort gibt es Cancel) statt LostFocus. LostFocus feuert auch, wenn sich gar nichts geändert hat, und lässt sich schlecht abbrechen.

Die Reihenfolge der Ereignisse

Ereignisse feuern nicht wild, sondern in fester Reihenfolge. Beim Öffnen eines Formulars ist die Kette:

Open  →  Load  →  Resize  →  Activate  →  Current

Beim Wechsel in ein Feld, Ändern des Werts und Verlassen:

GotFocus (Feld)  →  ...tippen...  →  BeforeUpdate (Feld)  →  AfterUpdate (Feld)  →  LostFocus (Feld)

Und beim Speichern des Datensatzes kommt zuerst das Feld-, dann das Formular-Ereignis:

BeforeUpdate (Feld)  →  BeforeUpdate (Formular)  →  AfterUpdate (Formular)

Diese Ordnung erklärt viele Stolperfallen: Form_Current läuft schon beim Laden, noch bevor der Nutzer irgendetwas getan hat. Rechne also immer damit, dass es beim allerersten Datensatz feuert.

Ereignis per VBA verdrahten

Manchmal willst du eine Prozedur haben, ohne sie über das Eigenschaftenblatt anzulegen. Damit Access sie aufruft, muss die Ereignis-Eigenschaft exakt den Wert [Event Procedure] tragen. Das kannst du auch aus Code setzen:

Private Sub Form_Load()
    ' Klick-Ereignis eines Buttons programmatisch aktivieren
    Me.cmdDrucken.OnClick = "[Event Procedure]"
End Sub

Fehlt dieser Eintrag, existiert deine Private Sub cmdDrucken_Click() zwar im Modul, wird aber nie ausgelöst — ein häufiger Grund für „mein Code läuft nicht".

Zusammengefasst

• Access ist ereignisgesteuert: Code läuft, wenn ein Ereignis feuert.
• Ereignisprozeduren heißen Steuerelement_Ereignis und sind immer Private.
• Form_Load für Vorbereitung, Form_Current bei jedem Datensatzwechsel.
• BeforeUpdate mit Cancel = True bricht das Speichern ab — dein Werkzeug für Pflichtfelder.
• Ereignisse feuern in fester Reihenfolge; die Eigenschaft muss [Event Procedure] sein, sonst läuft nichts.