Home > Artikel > Ausgabe 4/2011 > Validieren von Benutzereingaben

Validieren von Benutzereingaben

Achtung: Sie sind nicht angemeldet. Wenn Sie Abonnent sind und sich anmelden, lesen Sie den kompletten Artikel, laden das PDF herunter oder probieren die Beispieldatenbank aus (sofern vorhanden).

Für grundlegende Validierungsfunktion liefern Access-Tabellen und -Felder entsprechende Eigenschaften. Wer mehr will, lässt die Benutzereingabe in Formularen direkt bei der Eingabe prüfen. Wie dies funktioniert, erfahren Sie in diesem Artikel.

Beispiele

Die Beispiele dieses Artikels finden Sie in der Beispieldatenbank Access_Basics_2011_04.mdb.

Validierung

Die Validierung bei der Eingabe von Daten ist eine wichtige Funktion einer Formulars. Wenn Sie den Benutzer nach Lust und Laune Werte eingeben lassen, werden früher oder später nicht sinnvoll verwertbare Daten vorliegen – daher sollten Sie Ihren Anwendungen eine Validierung hinzufügen, die Werte nach der Eingabe prüft und gegebenenfalls auf Fehler hinweist (siehe Bild 1).

Beispiel für eine Validierungsmeldung

Bild 1: Beispiel für eine Validierungsmeldung

Validierung auf Tabellenebene

Der Artikel Tabellen entwerfen - Teil IV: Felder und ihre Eigenschaften hat bereits erläutert, wie Sie direkt im Tabellenentwurf festlegen, welche Werte für ein Feld zulässig sind und welche Meldung angezeigt werden soll, wenn der Benutzer eine ungültige Eingabe durchführt. Die dort vorgestellten Eigenschaften Gültigkeitsregel und Gültigkeitsmeldung gelten anwendungsweit. Das bedeutet, dass diese auch bei Eingaben in die Steuerelemente von Formularen, die an die entsprechenden Felder gebunden sind, funktionieren. Genau wie bei der Eingabe in die Tabellen selbst wird die Gültigkeitsregel gleich nach dem Abschließen der Eingabe und vor dem Übernehmen des Wertes durchgeführt.

Dasselbe gilt für die beiden gleichnamigen Eigenschaften, die Sie im Tabellenentwurf für die Tabellenebene festlegen können (siehe Tabellen entwerfen – Teil V: Eigenschaften von Tabellen). Hier verschiebt sich der Zeitpunkt, zu dem die Regeln geprüft werden, allerdings ein wenig nach hinten: Die Prüfung findet erst nach dem Abschließen der Eingabe des Datensatzes, aber noch vor dem Speichern des Datensatzes in der Tabelle statt. Auch noch einige weitere Eigenschaften von Tabellen und ihrer Felder dienen prinzipiell der Validierung der Benutzereingaben:

  • Der Datentyp lässt nur Eingaben nach bestimmten Vorgaben zu, beispielsweise Zahl, Datum/Zeit oder Ja/Nein.
  • Die Eigenschaften Eingabe erforderlich oder Leere Zeichenfolge eines Feldes bestimmen, ob ein Wert oder eine Zeichenfolge eingegeben werden muss.
  • Sogar die Eigenschaft Indiziert kann in die Validierung eingreifen, wenn Sie diese auf den Wert Ja (Ohne Duplikate) einstellen. Das Eingeben eines Wertes, der bereits in einem anderen Datensatz enthalten ist, würde dann das Speichern des Datensatzes verhindern

Sie können die Validierung jedoch auch direkt im Formular vornehmen, ohne Eigenschaften wie Gültigkeitsregel und Gültigkeitsmeldung zu verwenden. Manchmal muss man die durch diese Eigenschaften ausgelösten Effekte sogar beeinflussen, damit keine für den Benutzer unverständlichen Meldungen erscheinen.

Validierung auf Tabellen- oder Formularebene?

Der Vorteil der Validierungen, die durch die Feld- und Tabelleneigenschaften ausgelöst werden, ist die Einfachheit. Sie legen fest, wann der Wert eines Feldes gültig ist und welche Meldung bei der Eingabe ungültiger Werte angezeigt werden soll. Oder Sie lassen Access einfach entsprechende Meldungen ausgeben, wenn der Benutzer einen Wert in einem eindeutigen Feld doppelt eingibt oder einen Text in ein Zahlenfeld eintippt. Im Gegensatz zu selbstdefinierten Gültigkeitsmeldungen sind diese Fehlermeldungen für Otto Normalverbraucher jedoch oft nicht leicht zu verstehen.

In vielen Fällen müssen Sie also ohnehin die eingebauten Meldungen abfangen und durch eigene Meldungen ersetzen (wie dies geschieht, erfahren Sie weiter unten). Dies erledigen Sie durch entsprechende Ereignisprozeduren im Formular. Wenn Sie gleichzeitig Gültigkeitsregeln auf Tabellen- oder Feldebene verwenden, bedeutet dies, dass Sie die Prüfung der Daten auf mehrere Bereiche der Datenbank aufteilen. Dies ist aus Gründen der Wartbarkeit der Anwendung nicht empfehlenswert. Sie sollten also entweder nur einfache Validierungen mit den Möglichkeiten des Tabellenentwurfs verwenden oder aber gleich die komplette Eingabeprüfung in die Formulare integrieren.

Wenn Sie die Validierung direkt im Formulare programmieren möchten, benötigen Sie eine oder mehrere Ereignisprozeduren, die vor oder nach der Eingabe der Daten durch den Benutzer ausgelöst werden. Grundsätzlich unterscheiden wir aber auch noch nach Eingaben auf Feld- und Datensatzebene. Wenn ein Benutzer beispielsweise einen Text in ein Datumsfeld eingibt, sollten Sie diesen direkt auf die fehlerhafte Eingabe hinweisen. Der Benutzer ist dann gedanklich noch in der Nähe des entsprechenden Feldes und kann eine Korrektur gleich vornehmen. Die andere Variante ist die Prüfung der Eingabe erst vor dem Speichern des Datensatzes. Dort müssten Sie dann alle Daten auf Richtigkeit und Vollständigkeit prüfen und den Benutzer gegebenenfalls durch eine Meldung auf eventuell fehlende Daten hinweisen.

Optimalerweise kombiniert man beide Varianten. Fehleingaben, die an Ort und Stelle erkannt werden, sollten auch gleich gemeldet werden. Andere Fehleingaben kann man schlicht nicht direkt erkennen – auf ein leeres Feld etwa sollten Sie den Benutzer erst hinweisen, wenn dieser versucht, den Datensatz zu speichern. Schließlich gibt es auch noch abhängige Kriterien bei der Validierung: Wenn beispielsweise ein Feld das Eintrittsdatum und ein anderes das Austrittsdatum markiert, darf das Eintrittsdatum nicht hinter dem Austrittsdatum liegen.

Solche Zustände können Sie erst prüfen, wenn der Benutzer beide Eingaben vorgenommen hat. Dies ist in der Regel erst beim Speichern des kompletten Datensatzes der Fall, wie Sie später sehen werden. All diese Validierungen führen Sie vor dem Speichern des Datensatzes durch. Bei Prüfungen auf Feld- beziehungsweise Steuerelementebene erledigen Sie dies in einer Prozedur, die durch das Ereignis Vor Aktualisierung des entsprechenden Steuerelements durchgeführt wird. Validierungen auf Datensatzebene hingegen finden in der Ereignisprozedur Vor Aktualisierung des Formulars selbst statt.

Es gibt noch Sonderfälle wie etwa das Auftreten leerer Feldwerte, wenn die Feldeigenschaft Eingabe erforderlich den Wert Ja hat, wenn der Benutzer einen doppelten Wert in ein eindeutiges Feld eingibt et cetera. Die dadurch ausgelösten Fehler fangen Sie in der Ereignisprozedur Bei Fehler des Formulars ab – mehr dazu ebenfalls weiter unten.

Beispieltabelle und -formular

Für die folgenden Beispiele haben wir eine Tabelle namens tblBeispieleValidierung mit den folgenden Feldern vorbereitet (siehe Bild 2):

Das Feld EindeutigerText der Beispieltabelle hat einen eindeutigen Index.

Bild 2: Das Feld EindeutigerText der Beispieltabelle hat einen eindeutigen Index.

  • EinfacherText: Einfaches Textfeld, dessen Werte wir nach bestimmten Kriterien validieren werden
  • EindeutigerText: Textfeld, dessen Eigenschaft Indiziert den Wert Ja (Ohne Duplikate) enthält
  • Zahlenfeld: Feld zur Eingabe von Zahlenwerten
  • DatumsfeldStart und DatumsfeldEnde: Felder zur Demonstrierung der Validierung von Datumsbereichen
  • NichtNull: Textfeld, dessen Eigenschaft Eingabe erforderlich den Wert Ja enthält

Das Formular frmBeispieleValidierung enthält diese Tabelle als Datenherkunft. Damit das Formular alle in der Tabelle enthaltenen Felder anzeigt, haben wir diese in der Entwurfsansicht aus der Feldliste in den Detailbereich des Formulars gezogen.

Validierungsprozedur anlegen

Wenn die Validierung gleich nach dem Eingeben eines Wertes in ein Feld ausgelöst werden soll, hinterlegen Sie für die Ereigniseigenschaft Vor Aktualisierung eine entsprechende Prozedur. Um diese anzulegen, gehen Sie wie folgt vor:

  • Öffnen Sie das Formular in der Entwurfsansicht.
  • Markieren Sie das Steuerelement, für das Sie die Ereignisprozedur anlegen möchten.
  • Wählen Sie für die Eigenschaft Vor Aktualisierung des Steuerelements den Eintrag [Ereignisprozedur] aus und klicken Sie auf die Schaltfläche mit den drei Punkten (siehe Bild 3).
  • Anlegen der Ereignisprozedur, die nach der Eingabe ausgelöst werden soll

    Bild 3: Anlegen der Ereignisprozedur, die nach der Eingabe ausgelöst werden soll

  • Der VBA-Editor zeigt nun den leeren Prozedurrumpf an (siehe Bild 4).
  • Die frisch angelegte Ereignisprozedur

    Bild 4: Die frisch angelegte Ereignisprozedur

Für die folgenden Experimente fügen Sie nun zunächst eine einzige Anweisung hinzu, die dafür sorgt, dass beim Auslösen des Ereignisses ein Meldungsfenster erscheint:

Private Sub EinfachesTextfeld_BeforeUpdate(Cancel ?

                                         As Integer)

     MsgBox “Geändert!”

End Sub

Wechseln Sie dann in die Formularansicht des Formulars, geben Sie einen Text in das Feld ein und betätigen Sie die Eingabetaste. Wie erwartet erscheint das Meldungsfeld. Sinn dieser Übung ist es nun, herauszufinden, zu welchen Gelegenheiten das Ereignis ausgelöst wird. Dies geschieht beispielsweise zu folgenden Anlässen, aber jeweils nur nach Eingabe mindestens eines Zeichens:

  • Verlassen des Textfeldes mit der Tabulator- oder der Eingabetaste oder auch durch einen Mausklick in ein anderes Feld
  • Speichern des Datensatzes
  • Schließen des Formulars

Übrigens ist entscheidend, ob Sie überhaupt ein Zeichen eingeben, nicht, ob der Inhalt geändert wurde. Wenn Sie ein Zeichen hinzufügen und dieses gleich wieder löschen, hat das Feld zwar nachher den gleichen Wert – das Ereignis Vor Aktualisierung wird aber trotzdem ausgelöst.

Validierung programmieren

Nun fügen wir die Zeilen Code hinzu, die den Inhalt des Steuerelements prüfen. Zunächst formulieren wir den Code allgemein und fügen anschließend die gewünschte Bedingung hinzu.

Die folgende Prozedur prüft die Bedingung . Ist diese wahr, führt sie drei Anweisungen durch. Die erste zeigt die Meldung an, die zweite stellt den Parameter Cancel auf den Wert True ein und die dritte beendet die aktuelle Prozedur:

Private Sub EinfachesTextfeld_BeforeUpdate(Cancel ?

                                         As Integer)

     If Then

         MsgBox

         Cancel = True

         Exit Sub

     End If

End Sub

Eine wichtige Rolle spielt der Parameter Cancel. Wenn Sie diesem den Wert True übergeben, wird das Übernehmen des Wertes des aktuellen Steuerelements unterbrochen. Die Einfügemarke verbleibt dann im aktuellen Steuerelement – auch wenn Sie den Fokus auf ein anderes Steuerelement verschoben haben. Die dritte Anweisung beendet die Validierungsprozedur. Warum das? Es kann sein, dass Sie mehrere Validierungsregeln für ein einziges Steuerelement festlegen. In diesem Fall sollte der Benutzer nicht gleich mehrere Meldungen hintereinander angezeigt bekommen, sondern nur die jeweils erste.

Validierungsregeln und -meldungen

Nun schauen wir uns einige Beispiele für Validierungsbedingungen an.

  • IsNull(Me!EinfachesTextfeld): Prüft, ob das Feld den Wert Null hat
  • IsNumeric(Me!EinfachesTextfeld): Prüft, ob das Feld einen numerischen Wert enthält.
  • Me!EinfachesTextfeld = “abc”: Prüft, ob das Feld den Wert abc enthält.
  • Me!EinfachesTextfeld LIKE “A*”: Prüft, ob das Feld mit A beginnt.
  • Len(Me!EinfachesTextfeld) = 5: Prüft die Länge der im Feld enthaltenen Zeichenkette.
  • IsDate(Me!EinfachesTextfeld): Prüft, ob das Feld ein gültiges Datum enthält.
  • Me!DatumsfeldStart > “1.1.2011”: Prüft, ob ein Datum größer als ein anderes Datum ist.

Mehrere Validierungen

Wenn es mehrere Regeln für die Eingabe eines Feldwertes gibt, sollten Sie diese auch in mehrere Prüfungen aufteilen. Sie können dem Benutzer so deutlich mitteilen, warum der Wert nicht gültig ist. In der Prüfung auf Datensatzebene, die wir uns gleich anschauen, benötigen Sie ohnehin Validierungen für mehrere Steuerelemente, die Sie nacheinander durchführen werden.

Validierung beim Speichern des Datensatzes

Einige Validierungen nehmen Sie am besten erst vor, wenn der Benutzer den Datensatz speichert. Dabei handelt es sich vor allem um solche Validierungen, bei denen die Werte zweier oder mehrerer Felder voneinander abhängen. Das Paradebeispiel sind Datumsangaben wie etwa in den beiden Feldern DatumsfeldStart und DatumsfeldEnde der Beispieltabelle. Das Startdatum darf natürlich nicht hinter dem Enddatum liegen.

Als erstes benötigen Sie wieder eine Ereignisprozedur, die wiederum durch das Ereignis Vor Aktualisierung ausgelöst wird. Allerdings gehört die entsprechende Ereigniseigenschaft diesmal zum Formular selbst und nicht zu einem der enthaltenen Steuerelemente. Das Ereignis Vor Aktualisierung des Formulars wird zum Beispiel durch folgende Aktionen ausgelöst – aber jeweils nur, wenn der Datensatz geändert wurde, was durch das Bearbeiten-Symbol im Datensatzmarkierer angezeigt wird (siehe Bild 5):

Das Ereignis Vor Aktualisierung wird nur ausgelöst, wenn der Datensatz wie hier zuvor geändert wurde.

Bild 5: Das Ereignis Vor Aktualisierung wird nur ausgelöst, wenn der Datensatz wie hier zuvor geändert wurde.

  • Schließen des Formulars
  • Wechseln des Datensatzes
  • Speichern des Datensatzes etwa durch die Tastenkombination Strg + S

Die Ereignisprozedur, die vor dem Aktualisieren des Formulars ausgelöst wird, enthält eine Anweisung mehr als die für die einzelnen Steuerelemente. Das Validieren auf Steuerelementebene löst das entsprechende Ereignis aus und belässt dem Fokus auf dem betroffenen Steuerelement, wenn der Parameter Cancel auf True eingestellt wurde.

Wenn die Validierung hingegen durch das Ereignis Vor Aktualisierung des Formulars ausgelöst wurde, weiß dieses nicht, welches Steuerelement gegebenenfalls die Validierungsprüfung nicht bestanden hat. Sie müssen also von Hand den Fokus auf das betroffene Feld setzen, damit der Benutzer gleich mit der Korrektur des ungültigen Wertes fortfahren kann.Beim Vergleich der beiden Datumsfelder sieht die Ereignisprozedur also etwa so aus:

Private Sub Form_BeforeUpdate(Cancel As Integer)

     If Me!DatumsfeldEnde < Me!DatumsfeldStart Then

         MsgBox “Das Startdatum muss vor dem ?

                                   Enddatum liegen.”

         Cancel = True

         Me!DatumsfeldStart.SetFocus

         Exit Sub

     End If

End Sub

Eingreifen in Validierungen auf Tabellen- oder Feldebene

Wenn Sie Gültigkeitsregeln festgelegt haben oder andere Restriktionen wie etwa der Datentyp, eine eindeutige Indizierung oder ein Pflichtfeld greifen, kommen Ihre selbst programmierten Validierungsprüfungen gegebenenfalls gar nicht zum Zuge. Wenn das Feld als Datum deklariert ist und der Benutzer einen ungültigen Wert wie einen Text eingibt, erscheint zunächst die Meldung aus Bild 6.

Dieser Fehler tritt beispielsweise dann auf, wenn Sie einen Text in ein Datumsfeld eingeben.

Bild 6: Dieser Fehler tritt beispielsweise dann auf, wenn Sie einen Text in ein Datumsfeld eingeben.

Ähnliche Meldungen erhalten Sie, wenn der Benutzer Text in Zahlenfelder eingibt, wenn beim Speichern eines Datensatzes ein Pflichtfeld leerbleibt oder wenn ein eindeutiges Feld einen Wert enthält, der bereits einmal im gleichen Feld vorhanden ist.

Versuchen wir also, diese eingebaute Fehlermeldung zu umgehen. Dazu legen Sie die folgende Ereignisprozedur für das Feld DatumsfeldStart an:

Private Sub DatumsfeldStart_BeforeUpdate(Cancel ?

                                         As Integer)

     If Not IsDate(Me!DatumsfeldStart) Then

Sie haben das Ende des frei verfügbaren Teil dieses Artikels erreicht!

Wenn Sie mehr lesen und auf viele weitere Artikel zugreifen möchten, melden Sie sich als Abonnent unter Login an. Falls nicht, bestellen Sie doch einfach ein Jahresabonnement!