<\/p>\n
André Minhorst, Duisburg<\/b><\/p>\n
Die Konsistenz einer Datenbank lässt sich nur durch eine entsprechende Validierung beim Anlegen und ändern von Daten erhalten. Dazu stellt Access einiges an eingebauter Funktionalität zur Verfügung: zum Beispiel die Gültigkeitsregeln und Gültigkeitsmeldungen von Tabellenfeldern, Tabellen und Formularfeldern, mit denen sich eine Menge Fehleingaben ausschließen lässt. Wer aber den Benutzern seiner Anwendung in jeder Situation zur Seite stehen möchte, kommt um einige Handarbeit nicht herum. Wie Sie Ihre Datenbankanwendung mit einer professionellen Validierung versehen, erfahren Sie in diesem Beitrag.<\/b><\/p>\n
Der freien Enzyklopädie unter http:\/\/www.wikipedia.de ist folgender Kernsatz zu entnehmen: „In der Softwaretechnik bezeichnet Validierung oder Plausibilisierung (auch Sanity Check genannt) die Kontrolle eines konkreten Wertes darauf, ob er zu einem bestimmten Datentyp gehört oder in einem vorgegebenen Wertebereich oder einer Wertemenge liegt.“<\/p>\n
Weiterhin findet man dort noch eine „Goldene Regel“. Diese lautet „Never trust the user“ (deutsch: Traue dem Benutzer niemals). Beides zusammen definiert den einen Teil des hier behandelten Themas: überprüfen Sie jede Eingabe der Benutzer, selbst wenn diese noch so trivial erscheint. Aber es gibt noch einen Punkt, dem dieser Beitrag besondere Beachtung schenkt: Wenn der Benutzer die „Goldenen Regel“ durch Fehleingaben rechtfertigt, dann gehen Sie auch noch einen Schritt weiter und weisen ihn in angemessener Weise darauf hin: mit einer aussagekräftigen Meldung. <\/p>\n
Dem einleitenden Kapitel des vorliegenden Beitrags bleibt nur noch die Aufgabe, ein wenig Appetit auf die folgenden Kapitel zu machen: Sie erfahren, wie Sie Gültigkeitsprüfungen auf Tabellenebene festlegen können, welche Möglichkeiten es dazu in Formularen gibt und welche Vor- und Nachteile die unterschiedlichen Varianten mit sich bringen.<\/p>\n
Die einfachste und grundlegendste Validierung lässt sich über den Entwurf einer Tabelle festlegen.<\/p>\n
Dazu gibt es verschiedene Möglichkeiten:<\/p>\n
Mit der Auswahl eines Datentyps für ein Feld haben Sie schon eine Vorauswahl für die einzugebenden Daten getroffen. Mit Text- und Memofeldern sind Sie noch am flexibelsten, da hier alle möglichen Zeichenketten unterkommen, aber mit Datums- oder den unterschiedlichen Zahlenformaten schränken Sie den Kreis der einzugebenden Daten schon stark ein.<\/p>\n
Wenn Sie nun beispielsweise den Datentyp „Datum\/Zeit“ für ein Tabellenfeld festlegen und eine Zeichenkette in dieses Feld eingeben, erscheint folgende Meldung: „Sie haben einen Wert eingegeben, der für dieses Feld nicht zulässig ist.“ Das ist im Rahmen, wenn der Benutzer aus Versehen einen falschen Wert eingegeben hat und weiß, wie das Datum aufgebaut sein muss. Vielleicht haben Sie es aber auch mit einem DAU zu tun und dieser lässt sich die denkbar wildeste Variante von Datumsformat einfallen und ist sich sicher, das er definitiv nicht schuld an diesem Eingabefehler sein kann. In dem Fall wäre ein Hinweis auf das korrekte Format der einzugebenden Daten sicher wertvoll.<\/p>\n
In Tabellen lässt sich bei einer nicht dem Datentyp entsprechenden Eingabe keine andere Eingabe herausholen, in Formularen aber – und hier findet die Bearbeitung der Daten normalerweise statt – lässt sich eine alternative Fehlermeldung präsentieren. Dazu jedoch später mehr.<\/p>\n
Mit diesen beiden Eigenschaften lassen sich ebenfalls grundlegende Validierungsregeln festlegen. Wenn die Eigenschaft Eingabe erforderlich den Wert Ja hat, muss der Benutzer für dieses Feld auf jeden Fall einen Wert eingeben.<\/p>\n
Bei diesem Wert kann es sich, wenn die Eigenschaft Leere Zeichenfolge ebenfalls den Wert Ja hat, auch um eine leere Zeichenfolge handeln – ansonsten sonst muss man mindestens ein Zeichen mit Ausnahme des Leerzeichens dort eintragen.<\/p>\n
Hat die Eigenschaft Eingabe erforderlich den Wert Nein, muss der Benutzer keinen Wert für dieses Feld eingeben – der Wert des Feldes bleibt dann Null, soweit kein anderer Standardwert vorgegeben ist. Auch hier wirkt sich der Wert der Eigenschaft Leere Zeichenfolge wieder aus: Steht der auf Ja, können Sie hier Leerzeichen eingeben, sonst ist das nicht möglich.<\/p>\n
Flexibler als die beiden vorher genannten Möglichkeiten zum Validieren sind die Gültigkeitsregeln. Für die Festlegung der Vergleichsmuster können Sie beliebige Ausdrücke bestehend aus einem Vergleichoperator und einem Vergleichswert mit entsprechenden Verknüpfungsoperatoren zusammensetzen.<\/p>\n
Zur Festlegung einer Gültigkeitsregel wählen Sie einfach das Feld aus, dessen Inhalt einem bestimmten Muster entsprechen soll, und verwenden die Eigenschaft Gültigkeitsregel zum Festlegen des Musters (siehe Bild 1). Im Beispiel soll der Inhalt des Feldes einfach nicht Null sein. Das ließe sich auch mit der Eigenschaft Eingabe erforderlich erreichen, allerdings hat diese Variante einen entscheidenden Nachteil, der später zur Sprache kommen wird.<\/p>\n
Die Eigenschaft Gültigkeitsmeldung gibt an, welche Meldung Access anzeigen soll, wenn die Gültigkeitsregel beim Speichern eines Datensatzes nicht erfüllt ist.<\/p>\n
![](\"..\/fileadmin\/_temp_\/{9E61AA36-A616-44F0-B606-5A8DAA310614}\/pic001.png\")
<\/p>\n
<\/b><\/p>\n
Bild 1: Festlegen einer Validierung per Tabellenentwurf<\/span><\/b><\/p>\n Das Verhalten können Sie ganz einfach testen, indem Sie einen neuen Datensatz für die Tabelle anlegen und diesen speichern, ohne einen Wert für das Feld Vorname eingegeben zu haben. Es erscheint ein Meldungsfenster mit der eingestellten Nachricht (siehe Bild 2).<\/p>\n Für die Eigenschaft Gültigkeitsregel lassen sich beliebige Ausdrücke eingeben. Wenn Sie wie im vorliegenden Fall ein Textfeld verwenden, könnten Sie beispielsweise nach Ausdrücken eines bestimmten Formats verlangen, indem Sie den Like-Operator und einen Vergleichswert mit Platzhaltern wie Sternchen (*) und Fragezeichen () verwenden. Der folgende Ausdruck würde beispielsweise beliebige Namen akzeptieren, die mit A beginnen:<\/p>\n Sie könnten auch einen Bereich für ein einzugebendes Datum damit festlegen. Der folgende Ausdruck würde beispielsweise alle Datumsangaben akzeptieren, die im Jahr 2005 liegen:<\/p>\n <\/b><\/p>\n Bild 2: Gültigkeitsmeldung bei inkorrekter Eingabe<\/span><\/b><\/p>\n <\/b><\/p>\n Bild 3: Validierung auf Datensatzebene<\/span><\/b><\/p>\n Neben einzelnen Feldern können Sie auch komplette Datensätze einer Validierung per Gültigkeitsregel unterziehen. Damit lassen sich etwa voneinander abhängige Feldinhalte prüfen.<\/p>\n Um eine Gültigkeitsprüfung auf Datensatzebene durchzuführen, zeigen Sie zunächst das Eigenschaftsfenster der Tabelle in der Entwurfsansicht an. Dort finden Sie ebenfalls die beiden Eigenschaften Gültigkeitsregel und Gültigkeitsmeldung. Eine sinnvolle Anwendung ist beispielsweise die Prüfung eines Benutzernamens und eines Kennworts aus einer Benutzertabelle auf Gleichheit. Um allzu risikobereite Benutzer zur Auswahl eines „richtigen“ Kennworts zu veranlassen, vergleichen Sie einfach die Inhalte der Felder Benutzername und Kennwort miteinander und geben bei Gleichheit eine entsprechende Meldung aus (siehe Bild 3).<\/p>\n Wichtig ist hier, dass die Gültigkeitsregel nicht bereits beim Verlassen eines der betroffenen Felder herangezogen wird, sondern erst beim Speichern des Datensatzes.<\/p>\n Wenn der Benutzer eine Eingabe vornimmt, die nicht dem gültigen Datentyp entspricht, die Regeln Eingabe erforderlich und Leere Zeichenfolge übergeht oder die Gültigkeitsregel nicht berücksichtigt, erscheint direkt beim Verlassen des betreffenden Feldes der Tabelle eine entsprechende Meldung.<\/p>\n Wenn Sie ein Formular verwenden, das über die Datenherkunft an eine Tabelle mit solchen Validierungen gebunden ist, werden Datentyp, Gültigkeits- und sonstige Regeln genau so durchgesetzt wie beim direkten Bearbeiten der Tabelle wie in den obigen Beispielen. Bild 4 zeigt ein Beispiel: Die übereinstimmung von Benutzername und Kennwort erkennt Access sofort und zeigt die entsprechende Gültigkeitsmeldung an.<\/p>\n Aus der Verwendung der Validierung auf Tabellenebene ergeben sich Vor- und Nachteile, die nachfolgend aufgeführt sind.<\/p>\n <\/p>\n <\/b><\/p>\n Bild 4: Die Validierung per Gültigkeitsregel auf Tabellenebene greift auch in Formularen.<\/span><\/b><\/p>\n Der größte Vorteil dieser Validierungsmethode ist die globale Gültigkeit – egal, ob Sie die Daten per Formular, VBA oder Aktionsabfrage bearbeiten, die Gültigkeitsregeln greifen. Damit sichern Sie in jedem Fall die Konsistenz der in der Datenbank enthaltenen Daten.<\/p>\n <\/b><\/p>\n Bild 5: Mit dieser Fehlermeldung können nur wenige Benutzer etwas anfangen.<\/span><\/b><\/p>\n Die Gültigkeitsprüfung funktioniert zwar auch per VBA, allerdings fällt die Gültigkeitsmeldung in manchen Fällen flach. Folgende Anweisung beispielsweise ruft nur eine allgemein gehaltene Fehlermeldung hervor (siehe Bild 5):<\/p>\n Formulare bieten einige weitere Möglichkeiten zur Validierung von Daten. Damit lassen sich einerseits die Validierungstechniken auf Tabellenebene ergänzen, aber auch komplett ersetzen.<\/p>\n Die Geister scheiden sich bei der Frage, ob man den Inhalt der Steuerelemente direkt nach der Eingabe in ein Steuerelement prüfen sollte oder damit bis zum Speichern des Datensatzes wartet. Genau genommen lässt sich hier keine allgemeine Empfehlung geben.<\/p>\n Ausschlaggebend für die Wahl der richtigen Validierungsstrategie ist die Berücksichtigung der Benutzerfreundlichkeit und der Performance. Die Performance könnte sich beispielsweise bemerkbar machen, wenn Sie zum Prüfen eines Wertes immer wieder auf ein über das Netzwerk verbundenes Datenbankbackend zugreifen müssten. Dabei kommt es natürlich auch auf die Art des Frontends an: Wenn Sie beispielsweise eine .asp-Seite im Intranet als Frontend verwenden und den Inhalt der Felder einzeln prüfen, ist die Netzlast schon relativ hoch. In dem Fall sollte man schon beim Abschicken der kompletten Seite validieren und dann gegebenenfalls den Benutzer zur Nachbesserung auffordern. Dabei lassen sich viele Inhalte natürlich schon per Skript (zum Beispiel JavaScript) direkt bei der Eingabe prüfen, aber manchmal sind Eingaben eben mit dem bestehenden Datenbankinhalt abzugleichen, was definitiv den Kontakt zum Server erfordert.<\/p>\n Da die meisten Leser aber vermutlich mit Access als Frontend (wenn überhaupt mit aufgeteilter Datenbank) arbeiten, sollen die dortigen Möglichkeiten nun etwas genauer beleuchtet werden.<\/p>\n Eines direkt vorweg: Egal, ob Sie die Validierung bei der Eingabe einzelner Felder oder erst beim Speichern des Datensatzes durchführen: Sie müssen ohnehin jedes relevante Feld prüfen und kommen in keinem der beiden Fälle mit wesentlich weniger Aufwand klar. Unter Umständen ist die Validierung sogar an beiden Stellen erforderlich.<\/p>\n Das Validieren bei der Eingabe erfolgt am flexibelsten per VBA-Code. Dazu verwenden Sie die Ereigniseigenschaft Vor Aktualisierung des jeweiligen Steuerelements. Dieses Ereignis wird ausgelöst, wenn die änderung an einem Steuerelement schon abgeschlossen ist, aber bevor der neue Wert übernommen wird.<\/p>\n <\/b><\/p>\n Bild 6: Anlegen einer Ereignisprozedur<\/span><\/b><\/p>\n Zum Validieren ist dieser Zeitpunkt genau richtig. Sie können prüfen, ob der eingegebene Wert korrekt ist, den alten Wert wieder einstellen, eine Meldung anzeigen und den Fokus auf das Steuerelement mit dem unzulässigen Wert setzen.<\/p>\n Und so sieht das Ganze im Detail aus:<\/p>\n Im VBA-Editor ergänzen Sie den automatisch angelegten Prozedurrumpf wie in Quellcode 1.<\/p>\n Die Prozedur prüft zunächst, ob der Inhalt des Textfeldes Vorname den Wert Null hat. Falls ja, erscheint ein Meldungsfenster mit Bitte um Eingabe eines Vornamens. Nach dem Schließen des Meldungsfensters setzt die Prozedur den Wert des Textfeldes zurück, indem sie den Aktualisierungsvorgang durch Setzen von Cancel = True beendet.<\/p>\n Die Anweisung Exit Sub sorgt schließlich dafür, dass die Prozedur abbricht – eventuelle weitere Validierungen sind nicht mehr relevant, wenn schon die erste ein negatives Ergebnis bringt.<\/p>\n Das Validieren von Feldinhalten mit der Vor Aktualisierung-Ereignisprozedur hat einen entscheidenden Nachteil: Wenn der Benutzer dieses Feld gar nicht verändert, aktiviert er auch die Validierung nicht. Daher ist eine zusätzliche beim Speichern des Datensatzes durchgeführte Validierung unbedingt erforderlich. <\/p>\n Quellcode 1<\/b><\/p>\n Quellcode 2<\/b><\/p>\n Die zweite Möglichkeit, auf Formularebene zu validieren, findet beim Speichern des Datensatzes statt. Auch hier kommt die Ereigniseigenschaft Vor Aktualisierung zum Zuge – diesmal handelt es sich allerdings um die entsprechende Eigenschaft des Formulars selbst.<\/p>\n Sie wird zum Beispiel ausgelöst, wenn der Benutzer zum nächsten Datensatz wechselt, den Menüeintrag Datensätze\/Datensatz speichern ausführt oder einfach auf den Datensatzmarkierer klickt.<\/p>\n Die ausgelöste Prozedur sieht prinzipiell wie die aus Quellcode 1 aus, enthält aber gegebenenfalls die Validierung der Inhalte mehrerer Steuerelemente. Außerdem kann man nicht davon ausgehen, dass ein Feld mit ungültigem Inhalt noch den Fokus hat.<\/p>\n Um zu prüfen, ob die Felder Vorname und Nachname nicht leer sind und das Feld AngelegtAm ein gültiges Datum enthält, können Sie beispielsweise die Prozedur aus Quellcode 2 verwenden.<\/p>\n Die Prozedur hat einen Nachteil: Sie zeigt für jeden ungültigen Wert eine eigene Meldung an. Je nachdem, wie geschickt sich der Benutzer anstellt, kann das für ihn eine recht nervige Angelegenheit werden. Sie sollten also für Felder, die oft ungültige Daten erhalten, zusätzliche Hilfestellung geben. Dazu können Sie<\/p>\n Wie Sie in Quellcode 2 sehen, ist der Code zur Validierung eines Steuerelementinhalts immer gleich aufgebaut. Er besteht aus einer Bedingung und einigen Anweisungen, die bei Nicht-Erfüllen der Bedingung ausgeführt werden:<\/p>\n Quellcode 3<\/b><\/p>\n Quellcode 4<\/b><\/p>\n Bei Formularen mit vielen Steuerelementen kann das schnell in eine Paste & Copy-Orgie mit anschließendem Anpassen ausarten, was schnell zu Flüchtigkeitsfehlern führt.<\/p>\n Einfacher gestalten Sie die Erstellung solcher Validierungsprozeduren, indem Sie die wesentliche Funkionalität zu eigenen Funktionen zusammenfassen und in den Vor Aktualisierung-Ereignissen die jeweilige Funktion mit den entsprechenden Parametern aufrufen.<\/p>\n Für unser Beispiel aus Quellcode 2 könnte das so aussehen: Zuerst legen Sie eine Funktion an, die alle gemeinsamen Anweisungen der betroffenen Prozeduren enthält. Ersetzen Sie die individuellen Elemente durch Variable, die Sie gleichzeitig im Prozedurkopf als Parameter eintragen.<\/p>\n Ersetzen Sie dann die in den ursprünglichen Funktionen enthaltenen Anweisungen durch einen Aufruf der neuen Funktion und übergeben Sie die individuellen Bestandteile als Parameter.<\/p>\n Genaugenommen handelt es sich bei dieser Vorgehensweise um eine Refactoring-Maßnahme. Im Beitrag Refactoring in Ausgabe 6\/2004 von Access im Unternehmen lesen Sie mehr da-rüber. <\/p>\n Den Aufbau der aufzurufenden Funktion können Sie Quellcode 3 entnehmen. Die Funktion erwartet den Feldnamen sowie die Meldung und den Titel des eventuell anzuzeigenden Meldungsfensters als Parameter.<\/p>\n Die Funktion gibt den Wert True zurück, wenn alles in Ordnung ist, anderenfalls gibt sie die Meldung mit den übergebenen Daten aus, setzt den Fokus auf das Feld mit dem ungültigen Wert und den Rückgabewert auf False.<\/p>\n Nun benötigen Sie aber nicht nur eine Funktion, die auf Nullwerte testet, sondern auch noch eine, die Datumswerte überprüft. Das erledigt die Funktion aus Quellcode 4. Sie ist genauso aufgebaut wie die Funktion zum Prüfen auf Nullwerte, kontrolliert aber, ob das zu prüfende Feld ein gültiges Datum enthält.<\/p>\n Quellcode 5<\/b><\/p>\n Quellcode 7<\/b><\/p>\n Die beiden neuen Funktionen helfen nun nicht viel weiter, wenn sie nicht aufgerufen werden. Also passen Sie die Prozedur mit der ursprünglichen Validierung aus Quellcode 2 noch an. Dazu ersetzen Sie die Blöcke zur Validierung der einzelnen Steuerelementinhalte durch die Aufrufe der neuen Validierungsfunktionen (siehe Quellcode 5). Für weitere zu prüfende Steuerelemente müssen Sie nur noch je eine Zeile hinzufügen. Außerdem werden Sie früher oder später neue Validierungsfunktionen hinzufügen, die beispielsweise prüfen, ob<\/p>\n <\/b><\/p>\n Bild 7: Anwendung der Validierungsklasse<\/span><\/b><\/p>\n Unter Umständen kommt hier eine ganze Reihe Funktionen zusammen. Da es keinen Sinn macht, die komplette Sammlung in das Klassenmodul jedes einzelnen Formulars zu kopieren, legen wir ein spezielles Klassenmodul mit den Validierungsfunktionen zusammen.<\/p>\n Das Klassenmodul enthält den Code aus Quellcode 6. Die Validierungsfunktionen sind öffentlich, damit sie von allen Formularen aus erreicht werden können. Damit die Funktionen Zugriff auf die jeweiligen Steuerelemente haben, erwarten sie zusätzlich zum Namen des Steuerelements noch einen Objektverweis auf das Formular, in dem das Steuerelement enthalten ist.<\/p>\n Um die Klasse zu verwenden, müssen Sie diese lediglich deklarieren und instanzieren. Bild 7 zeigt, wie es funktioniert und welchen Vorteil die Verwendung einer Klasse noch mit sich bringt: Die einzelnen Validierungsfunktionen lassen sich dank Intellisense komfortabel auswählen.<\/p>\n Auch für Steuerelemente in Formularen stehen die beiden Eigenschaften Gültigkeitsregel und Gültigkeitsmeldung zur Verfügung. Sie können diese Eigenschaften genau wie im Tabellenentwurf festlegen, aber die Wirksamkeit ist dann natürlich auf das Formular beschränkt. Damit ist es aber auch möglich, die Eingabe in nicht gebundene Steuerelemente zu validieren. Es gibt allerdings keine formularweite Gültigkeitsregel und -meldung, sodass Sie damit keine Zusammenhänge zwischen den Steuerelementinhalten prüfen können.<\/p>\n Natürlich können Sie Gültigkeitsregeln auf Tabellenebene und auf Formularebene gleichzeitig verwenden. Die Regeln werden dann in folgender Reihenfolge berücksichtigt:<\/p>\n Eine gleichzeitige Einbeziehung mehrerer Ebenen in die Validierung führt allerdings zu einer Erschwerung der Wartung.<\/p>\n Validierung ist auf verschiedenen Ebenen möglich. Die Validierung auf Tabellenebene hat den Vorteil, dass sie selbst bei direkter Bearbeitung der Tabellen greif. Da die Datenbearbeitung aber immer per Formular erfolgen sollte, verschafft diese Art der Validierung lediglich ein wenig mehr Sicherheit als andere.<\/p>\n Die Validierung auf Formularebene hat den Vorteil, dass Sie jedes Feld in jedem Formular individuell behandeln können, dass die Ausgabe der Gültigkeitsmeldungen per benutzerdefiniertem Meldungsfenster erfolgt und dass die Anwendungslogik somit wesentlich enger zusammenrückt.<\/p>\n Mit der vorgestellten Validierungsklasse können Sie die Validierung jedes Feldes mit einem Einzeiler erledigen.<\/p>\n","protected":false},"excerpt":{"rendered":" Die Konsistenz einer Datenbank lässt sich nur durch eine entsprechende Validierung beim Anlegen und Ändern von Daten erhalten. Dazu stellt Access einiges an eingebauter Funktionalität zur Verfügung: zum Beispiel die Gültigkeitsregeln und Gültigkeitsmeldungen von Tabellenfeldern, Tabellen und Formularfeldern, mit denen sich eine Menge Fehleingaben ausschließen lässt. Wer aber den Benutzern seiner Anwendung in jeder Situation zur Seite stehen möchte, kommt um einige Handarbeit nicht herum. Wie Sie Ihre Datenbankanwendung mit einer professionellen Validierung versehen, erfahren Sie in diesem Beitrag.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[66022005,662005,44000023,44000021],"tags":[],"class_list":["post-55000267","post","type-post","status-publish","format-standard","hentry","category-66022005","category-662005","category-Mit_Formularen_arbeiten","category-Tabellen_und_Datenmodellierung"],"yoast_head":"\nLike ''a*''<\/pre>\n
>= #1\/1\/2005# And <=#31\/12\/2005#<\/pre>\n
![](\"..\/fileadmin\/_temp_\/{9E61AA36-A616-44F0-B606-5A8DAA310614}\/pic002.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{9E61AA36-A616-44F0-B606-5A8DAA310614}\/pic003.png\")
<\/p>\nGültigkeitsregeln auf Datensatzebene<\/h2>\n
Validierung auf Tabellenebene in Formularen behandeln<\/h2>\n
Vor- und Nachteile<\/h2>\n
![](\"..\/fileadmin\/_temp_\/{9E61AA36-A616-44F0-B606-5A8DAA310614}\/pic004.png\")
<\/p>\nVorteile<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{9E61AA36-A616-44F0-B606-5A8DAA310614}\/pic005.png\")
<\/p>\nNachteile<\/h3>\n
DoCmd.RunSQL \"INSERT INTO tblBenutzer(Benutzername, Kennwort) VALUES(''minhorst'', ''minhorst'')<\/pre>\nValidieren bei der Eingabe oder beim Speichern<\/h2>\n
Validieren bei Eingabe<\/h3>\n
![](\"..\/fileadmin\/_temp_\/{9E61AA36-A616-44F0-B606-5A8DAA310614}\/pic006.png\")
<\/p>\nHinweis<\/h3>\n
Private Sub Vorname_BeforeUpdate(Cancel As Integer)\r\n If IsNull(Me!Vorname) Then\r\n Cancel = True\r\n MsgBox \"Bitte geben Sie einen Vornamen ein.\"\r\n Exit Sub\r\n End If\r\nEnd Sub<\/pre>\n
Private Sub Form_BeforeUpdate(Cancel As Integer)\r\n If IsNull(Me!Vorname) Then\r\n Cancel = True\r\n MsgBox \"Bitte geben Sie einen Vornamen ein.\"\r\n Me!Vorname.SetFocus\r\n Exit Sub\r\n End If\r\n If IsNull(Me!Nachname) Then\r\n Cancel = True\r\n MsgBox \"Bitte geben Sie einen Nachnamen ein.\"\r\n Me!Nachname.SetFocus\r\n Exit Sub\r\n End If\r\n If IsNull(Me!AngelegtAm) Then\r\n Cancel = True\r\n MsgBox \"Bitte geben Sie ein gültiges Datum ein.\"\r\n Me!AngelegtAm.SetFocus\r\n Exit Sub\r\n End If\r\nEnd Sub<\/pre>\n
Validieren beim Speichern des Datensatzes<\/h3>\n
Globale Validier-Funktion<\/h2>\n
Private Function ValidiereNichtNull(strFeldname As String, strMeldung As String, _ strTitel As String)\r\n ValidiereNichtNull = True\r\n If IsNull(Me(strFeldname)) Then\r\n ValidiereNichtNull = False\r\n MsgBox strMeldung, vbExclamation + vbOKOnly, strTitel\r\n Me(strFeldname).SetFocus\r\n End If\r\nEnd Function<\/pre>\n
Private Function ValidiereDatum(strFeldname As String, strMeldung As String, _ strTitel As String)\r\n ValidiereDatum = True\r\n If Not IsDate(Me(strFeldname)) Then\r\n ValidiereDatum = False\r\n MsgBox strMeldung, vbExclamation + vbOKOnly, strTitel\r\n Me(strFeldname).SetFocus\r\n End If\r\nEnd Function<\/pre>\n
Hinweis<\/h3>\n
Private Sub Form_BeforeUpdate(Cancel As Integer)\r\n Cancel = True\r\n If Not ValidiereNichtNull(\"Vorname\", \"Bitte geben Sie einen Vornamen ein.\", _ \"Fehlende Daten\") Then Exit Sub\r\n If Not ValidiereNichtNull(\"Nachname\", \"Bitte geben Sie einen Nachnamen ein.\", _ \"Fehlende Daten\") Then Exit Sub\r\n If Not ValidiereDatum(\"AngelegtAm\", \"Bitte geben Sie ein gültiges Datum ein.\", _ \"Ungültiger Wert\") Then Exit Sub\r\n Cancel = False\r\nEnd Sub<\/pre>\n
Option Compare Database\r\nPublic Function ValidiereNichtNull(frm As Form, strFeld As String, _ strMeldung As String, strTitel As String)\r\n ValidiereNichtNull = True\r\n If IsNull(frm.Controls(strFeld)) Then\r\n ValidiereNichtNull = False\r\n MsgBox strMeldung, vbExclamation + vbOKOnly, strTitel\r\n frm.Controls(strFeld).SetFocus\r\n End If\r\nEnd Function\r\nPublic Function ValidiereDatum(frm As Form, strFeld As String, strMeldung As String, _ strTitel As String)\r\n ValidiereDatum = True\r\n If Not IsDate(frm.Controls(strFeld)) Then\r\n ValidiereDatum = False\r\n MsgBox strMeldung, vbExclamation + vbOKOnly, strTitel\r\n frm.Controls(strFeld).SetFocus\r\n End If\r\nEnd Function<\/pre>\n
![](\"..\/fileadmin\/_temp_\/{9E61AA36-A616-44F0-B606-5A8DAA310614}\/pic007.png\")
<\/p>\nGültigkeitsregeln in Formularen<\/h2>\n