{"id":55000678,"date":"2009-08-01T00:00:00","date_gmt":"2020-05-22T22:16:59","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=678"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Validieren_mit_Klasse","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Validieren_mit_Klasse\/","title":{"rendered":"Validieren mit Klasse"},"content":{"rendered":"

\"\"<\/p>\n

Das Validieren von Daten in Formularen ist normalerweise eine langweilige Arbeit, die man gewöhnlich an das Ende der Formularentwicklung packt. Die Anzahl der möglichen Fälle, die durch eine Validierung abgefangen werden sollen, ist überschaubar und die nötigen Codezeilen sehen sich meist sehr ähnlich: Prüfen, Fokus auf das Feld setzen, Aktualisierung abbrechen, Meldung ausgeben. Mit ein paar einfachen Klassen lässt sich diese Arbeit ein wenig spannender gestalten und am Ende sparen Sie sogar noch Code und somit Zeit.<\/b><\/p>\n

Welche Fälle treten bei der Validierung der Steuerelemente von Formularen auf Der einfachste ist wohl der, bei dem ein Feld unabhängig von allen anderen nur bestimmte Werte annehmen kann.<\/p>\n

Teilweise werden die dazu notwendigen Regeln möglicherweise schon im Tabellenentwurf festgelegt, teilweise müssen Sie sich selbst darum kümmern.<\/p>\n

Gleiches gilt für Felder, deren Wertebereich durch ein oder mehrere weitere Felder eingeschränkt wird – zum Beispiel sollte ein Feld namens Startdatum <\/b>keinen Wert aufnehmen, der im Kalender hinter dem Wert des Feldes Enddatum <\/b>liegt.<\/p>\n

Hier fällt die Prüfung schon ein wenig umfangreicher aus: Es reicht ja nicht, einfach nur den Inhalt der beiden Felder zu vergleichen; gleichzeitig ist auch noch zu prüfen, ob das jeweils andere Feld überhaupt einen Wert aufweist.<\/p>\n

Überhaupt stellt sich die Frage, wann der richtige Zeitpunkt für die Validierung ist: Direkt nach der Eingabe eines Wertes in ein Feld oder doch erst beim Klicken auf die OK<\/b>– oder Speichern<\/b>-Schaltfläche<\/p>\n

Ersteres würde die Prüfung in das Vor Aktualisierung<\/b>-Ereignis des Steuerelements verlegen, Letzteres betrifft die Ereignisprozedur gleichen Namens des Formulars selbst.<\/p>\n

Ein Beispiel für die Validierung eines Textfelds, das nicht Null sein darf, sieht etwa wie folgt aus:<\/p>\n

Private Sub txt_BeforeUpdate(Cancel As Integer)\r\n    If IsNull(Me!txt) Then\r\n        MsgBox "Bitte geben Sie einen Wert ein."\r\n        Cancel = True\r\n    End If\r\n    End Sub<\/pre>\n
Dieses Ereignis wird gleich beim Verlassen des geänderten Feldes ausgelöst. Die Alternative zum Validieren des Feldes vor dem Speichern des kompletten Datensatzes sieht fast genau so aus – mit dem feinen Unterschied, dass das Ereignis nicht zu einem Steuerelement gehört, sondern durch das Formular selbst ausgelöst wird:<\/p>\n
Private Sub Form_BeforeUpdate(Cancel As Integer)\r\n    If IsNull(Me!txt) Then\r\n        MsgBox "Bitte geben Sie einen Wert ein."\r\n        Me!txt.SetFocus\r\n        Cancel = True\r\n    End If\r\n    End Sub<\/pre>\n
Deshalb ist hier auch noch eine zusätzliche Zeile nötig, die den Fokus beim Fehlschlagen der Validierung auf das Feld mit den ungültigen Daten setzt.<\/p>\n
Validierungsregeln auf Tabellenebene<\/b><\/p>\n
Neben den manuell hinzugefügten Validierungsmechanismen wie aus dem obigen Beispiel gibt es einige Validierungen, die Access automatisch durchführt.<\/p>\n
Diese hängen meist vom Datentyp ab: So können Sie für ein Datumsfeld nur gültige Datumsangaben speichern und ein Zahlenfeld kann nur Zahlen, aber keine Buchstaben aufnehmen. Diese und ähnliche Verfehlungen würden einen Fehler auf Formularebene auslösen.<\/p>\n
Beim Einfügen einer Zeichenkette in ein Zahlenfeld würde beispielsweise die Fehlermeldung Sie haben einen Wert eingegeben, der für dieses Feld nicht gültig ist<\/b> auftreten.<\/p>\n
Mit der BeforeUpdate<\/b>-Ereignisprozedur kommen Sie dieser Meldung nicht bei: Das Ereignis feuert erst nach dem Erscheinen der Fehlermeldung. Die einzige Möglichkeit, diese Meldung zu verhindern, ist das Formularereignis Bei Fehler<\/b>, für das Sie beispielsweise die folgende Routine anlegen können:<\/p>\n
Private Sub Form_Error(DataErr As Integer, _\r\n    Response As Integer)\r\n    MsgBox "Formularfehler " & DataErr\r\n    Response = acDataErrContinue\r\n    End Sub<\/pre>\n
DataErr <\/b>liefert die gleiche Fehlernummer, wie Err.Number <\/b>bei einer herkömmlichen Fehlerbehandlung. Der Rückgabewert acDataErrContinue <\/b>für den Parameter Response <\/b>sorgt dafür, dass Access seine Meldung nicht mehr anzeigt.<\/p>\n
Prinzipiell entspricht die Wirkung unserer weiter oben vorgestellten Routine, die durch das Ereignis Vor Aktualisierung <\/b>ausgelöst wird: Es erscheint eine Meldung, der Inhalt bleibt stehen und das Feld kann nicht verlassen werden.<\/p>\n
Welche Steuerelemente werden validiert<\/p>\n
Die wichtigsten Kandidaten für eine Validierung sind Textfelder. Hier finden Sie sicher Kandidaten, für die Sie eine Validierung festlegen müssen, allein weil ihr Datentyp wie Datum\/Zeit <\/b>oder Zahl <\/b>eine Validierung nötig macht.<\/p>\n
Daneben gibt es natürlich noch einige Validierungen, die für die Einhaltung der Geschäftsregeln nötig sind: Ist Datum A kleiner als Datum B Hat Zeichenkette XYZ die richtige Anzahl Zeichen Hier dreht es sich meist um Daten, die über Textfelder eingegeben werden. Daneben sind noch Kombinationsfelder, Listenfelder, Kontrollkästchen, Optionsgruppen und Umschaltflächen interessant – andere Steuerelemente bleiben im Kontext dieses Beitrags außen vor.<\/p>\n
Validierung ganz einfach<\/b><\/p>\n
Die Lösung dieses Beitrags liefert ein paar Objekte, die Sie einfach in eine Datenbank einlesen müssen, die Sie mit einer Validierungsfunktion versehen möchten. Das geht ganz schnell:<\/p>\n