{"id":55001382,"date":"2022-10-01T00:00:00","date_gmt":"2022-10-03T14:37:05","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=1382"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Rechnungsverwaltung_Bestellformular","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Rechnungsverwaltung_Bestellformular\/","title":{"rendered":"Rechnungsverwaltung: Bestellformular"},"content":{"rendered":"

Nachdem wir das Datenmodell für unsere Rechnungsverwaltung angelegt sowie die Tabellen mit Beispieldaten gefüllt haben, kommt als Nächstes die Benutzeroberfläche zum Verwalten der Kunden-, Produkt- und Bestelldaten an die Reihe. Die dazu notwendigen Formulare stellen wir in mehreren Teilen dieser Beitragsreihe vor. Die Basis ist das Formular zum Anzeigen der Bestellungen, mit dem wir den Kunden auswählen, die Bestelldaten eingeben und die Bestellpositionen hinzufügen können. Die Programmierung dieses Formulars zeigen wir im vorliegenden Beitrag – inklusive Validierung und mehr.<\/b><\/p>\n

Leichter programmieren mit Testdaten<\/h2>\n

Das Schöne ist, dass wir im Beitrag Rechnungsverwaltung: Beispieldaten <\/b>(www.access-im-unternehmen.de\/1381<\/b>) bereits einige Beispieldatensätze angelegt haben, sodass wir beim Programmieren der Formulare nicht immer noch mühselig von Hand Testdaten eingeben müssen. Dabei sollten wir aber nicht vergessen, dass der Kunde die Anwendung gegebenenfalls ohne Daten erhält. In diesem Fall müssen wir die Formulare auch noch mit leeren Tabellen testen, um zu prüfen, ob das initiale Anlegen von Daten ebenfalls funktioniert und ob die Formulare komplett ohne Daten genauso gut funktionieren.<\/p>\n

Reihenfolge beim Anlegen der Formulare<\/h2>\n

Wenn Sie keine Testdaten zur Verfügung hätten, würden Sie die Formulare logischerweise in einer Reihenfolge erstellen, in der auch die Daten eingegeben werden. Wir würden also zuerst ein Formular zur Eingabe von Anreden, Einheiten und Mehrwertsteuersätzen benötigen, dann für Kunden und Produkte und schließlich für Bestellungen und Bestelldetails (wobei letztere in einem Formular plus Unterformular untergebracht werden).<\/p>\n

Mit Testdaten können wir das Erstellen der Formulare allerdings in beliebiger Reihenfolge gestalten. Also beginnen wir doch gleich mal mit dem aufwendigsten Formular – dem zur Eingabe der Bestellungen.<\/p>\n

Formulare zur Eingabe von Bestellungen<\/h2>\n

Zur Eingabe von Bestellungen benötigen wir eigentlich nur ein einfaches Formular, aber zu Bestellungen gehören ja auch noch Bestellpositionen. Und da diese über eine 1:n-Beziehung mit den Bestellungen verknüpft sind, bietet sich die Verwendung eines Unterformulars an.<\/p>\n

Wir erstellen zuerst das Hauptformular und öffnen es in der Entwurfsansicht. Dieses nennen wir frmBestellungDetails <\/b>und weisen ihm für die Eigenschaft Datensatzquelle <\/b>die Tabelle tblBestellungen <\/b>zu. Danach wechseln wir zur Feldliste und ziehen alle Felder außer ID <\/b>in den Detailbereich des Formularentwurfs (siehe Bild 1). Warum nicht das Feld ID<\/b>? Weil dieses ein rein für die Herstellung von Beziehungen verwendetes Feld ist und der Benutzer dieses ohnehin nicht ändern kann und soll. Die Beschriftungen müssen wir noch ein wenig anpassen, sodass beispielsweise aus KundeID <\/b>die Beschriftung Kunde <\/b>wird oder aus BestelltAm <\/b>die Beschriftung Bestellt am<\/b>. Außerdem fehlen überall noch Doppelpunkte.<\/p>\n

\"Das<\/p>\n

Bild 1: Das Formular frmBestellungDetails in der Entwurfsansicht<\/span><\/b><\/p>\n

Diese Änderungen hätten wir auch schon zu einem früheren Zeitpunkt vorbereiten können, nämlich im Tabellenentwurf. Dort hätten wir diese Bezeichnungen für die Eigenschaft Beschriftung der jeweiligen Felder eintragen können. Da wir nicht wissen, ob wir noch weitere Formulare oder Berichte auf Basis dieser Felder erstellen, nehmen wir diese Änderungen noch schnell vor. Dazu öffnen wir die Tabelle tblBestellungen <\/b>nochmals in der Entwurfsansicht und stellen dort für die verschiedenen Felder die gewünschten Beschriftungen in der gleichnamigen Eigenschaft ein (siehe Bild 2).<\/p>\n

\"Voreinstellung<\/p>\n

Bild 2: Voreinstellung für die Beschriftung von Feldern, auch in Formularen oder Berichten<\/span><\/b><\/p>\n

Doppelpunkte zu Beschriftungen hinzufügen<\/h2>\n

Und auch den Doppelpunkt hinter der Beschriftung müssen wir nicht von Hand anlegen. Wir können dies für das aktuelle Formular auch so einstellen, dass jedes Feld automatisch einen Doppelpunkt erhält. Dazu müssen Sie jedoch bereits vor dem Hinzufügen der Felder der Datensatzquelle eine bestimmte Eigenschaft einstellen.<\/p>\n

Klicken Sie dazu in der Entwurfsansicht des Formulars im Ribbon auf Formularentwurf|Steuerelemente|Textfeld<\/b>, aber fügen Sie kein Textfeld zum Formular hinzu. Das Eigenschaftsfeld zeigt nun einige Eigenschaften an, die nach dem Hinzufügen von Textfeldern nicht mehr erscheinen – zum Beispiel Mit Doppelpunkt<\/b>. Diese Eigenschaft stellen Sie, falls dies noch nicht der Fall ist, auf Ja <\/b>ein (siehe Bild 3).<\/p>\n

\"Aktivieren<\/p>\n

Bild 3: Aktivieren des Doppelpunkts für Beschriftungsfelder<\/span><\/b><\/p>\n

Anschließend betätigen Sie die Esc<\/b>-Taste, um die Auswahl des Textfeldes abzubrechen. Das Feld KundeID haben wir in der Tabelle als Nachschlagefeld ausgelegt. Das heißt, dieses Feld wird beim Ziehen aus der Feldliste in den Formularentwurf als Kombinationsfeld erstellt. Da wir die Änderung zum Anzeigen des Doppelpunkts soeben nur für Textfelder eingestellt haben, müssen wir dies auch noch für Kombinationsfelder erledigen.<\/p>\n

Anschließend ziehen wir erneut die gewünschten Felder aus der Feldliste in den Detailbereich des Formularentwurfs. Das Ergebnis sieht schon viel besser aus – die Beschriftungen aus dem Tabellenentwurf wurden übernommen und auch die Doppelpunkte wurden hinzugefügt (siehe Bild 4).<\/p>\n

\"Bezeichnungsfelder<\/p>\n

Bild 4: Bezeichnungsfelder mit Doppelpunkten<\/span><\/b><\/p>\n

Damit sind die Arbeiten am Hauptformular vorerst erledigt. Sie können nun bereits in die Datenblattansicht wechseln und sehen dort die Testdaten zum Durchblättern. Hier erkennen Sie auch, dass wir die Breite des Kombinationsfeldes KundeID <\/b>noch vergrößert haben (siehe Bild 5).<\/p>\n

\"Steuerelemente<\/p>\n

Bild 5: Steuerelemente mit angepasster Breite<\/span><\/b><\/p>\n

Unterformular für Bestellpositionen<\/h2>\n

Damit kommen wir zum Unterformular, das die Bestellpositionen zur jeweiligen Bestellung anzeigen soll. Dieses legen wir unter dem Namen sfmBestellungDetails <\/b>an. Als Datensatzquelle fügen wir die Tabelle tblBestellpositionen <\/b>zu. Diese passen wir zuvor ähnlich wie die Tabelle tblBestellungen <\/b>noch an, indem wir passende Beschriftungen für die Felder ProduktID <\/b>(Produkt<\/b>), Mehrwertsteuersatz <\/b>(MwSt.-Satz<\/b>) und EinheitID <\/b>(Einheit<\/b>) einstellen.<\/p>\n

Danach ziehen wir alle Felder außer ID <\/b>und BestellungID <\/b>in den Detailbereich des Formulars. ID benötigen wir nicht, weil es das Primärschlüsselfeld der Tabelle ist und BestellungID <\/b>dient nur dem Herstellen einer Beziehung zum jeweils im Hauptformular angezeigten Datensatz.<\/p>\n

Außerdem stellen wir die Eigenschaft Standardansicht <\/b>des Formulars auf Datenblatt <\/b>ein. Die Bestellpositionen sollen im Unterformular tabellarisch dargestellt werden. Danach schließen wir das als Unterformular zu verwendende Formular.<\/p>\n

Unterformular zum Hauptformular hinzufügen<\/h2>\n

Nun öffnen wir wieder das Formular frmBestellungDetails <\/b>in der Entwurfsansicht und fügen das Unterformular sfmBestellungDetails<\/b> zum Hauptformular hinzu, indem wir es aus dem Navigationsbereich in den Detailbereich des Hauptformulars ziehen – und es unter den dort bereits befindlichen Steuerelementen fallenlassen.<\/p>\n

Dort platzieren wir es wie in Bild 6 und ändern seine Beschriftung auf Bestellpositionen<\/b>. Für die bessere Bedienbarkeit nehmen wir noch weitere Änderungen vor. So stellen wir die Eigenschaften Horizontaler Anker <\/b>und Vertikaler Anker <\/b>des Unterformular-Steuerelements jeweils auf Beide <\/b>ein.<\/p>\n

\"Haupt-<\/p>\n

Bild 6: Haupt- und Unterformular<\/span><\/b><\/p>\n

Dies ändert automatisch die entsprechenden Eigenschaften des Bezeichnungsfeldes des Unterformular-Steuerelemente, die wir wieder auf Oben <\/b>beziehungsweise Links <\/b>zurückstellen.<\/p>\n

Wie soll das Unterformular nun wissen, dass es nicht alle Bestellpositionen anzeigen soll, sondern nur die Bestellpositionen, die zum aktuell im Hauptformular angezeigten Datensatz gehören? Die notwendige Einstellung haben wir indirekt bereits getroffen, indem wir eine Beziehung zwischen den Feldern BestellungID <\/b>der Tabelle tblBestellpositionen <\/b>und ID <\/b>der Tabelle tblBestellungen <\/b>definiert haben. Access erkennt diese Beziehung beim Hinzufügen eines Unterformulars und trägt die relevanten Daten direkt in die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>des Unterformular-Steuerelements ein. Das Ergebnis sieht wie in Bild 7 aus.<\/p>\n

\"Herstellen<\/p>\n

Bild 7: Herstellen der Beziehung der Daten aus Haupt- und Unterformular<\/span><\/b><\/p>\n

Ausprobieren des Bestellungen-Formulars<\/h2>\n

Nun wechseln wir in die Formularansicht des Formulars frmBestellungDetails<\/b> und finden das Ergebnis aus Bild 8 vor.<\/p>\n

\"Haupt-<\/p>\n

Bild 8: Haupt- und Unterformular in der Formularansicht<\/span><\/b><\/p>\n

Wenn wir durch die Datensätze des Hauptformulars navigieren, zeigt das Unterformular auch jeweils die passenden Datensätze an.<\/p>\n

Damit können wir nun auch einen der weiter oben erwähnten Tests durchführen, der das Anlegen einer neuen Bestellung betrifft. Dazu wechseln wir im Hauptformular zu einem neuen, leeren Datensatz. Dieser zeigt sowohl im Hauptformular als auch im Unterformular noch keine Daten an. Wenn wir nun den herkömmlichen Weg gehen und zuerst die Daten der Bestellung im Hauptformular anlegen und dann über das Unterformular Bestellpositionen hinzufügen, läuft alles wie erwartet.<\/p>\n

Aber es kann ja auch sein, dass der Kunde anruft und direkt sagt, er möchte Produkt X und Produkt Y erhalten und der neue Mitarbeiter trägt erst einmal die entsprechenden Bestellpositionen ein, ohne die übrigen Bestelldaten hinzuzufügen.<\/p>\n

Dann geschieht Folgendes: Da im Hauptformular noch kein Datensatz angelegt wurde, trägt Access in die neuen Datensätze im Unterformular mit den Bestellpositionen den Wert in das Fremdschlüsselfeld BestellungID <\/b>ein, der auch gerade im damit verknüpften Feld ID <\/b>im Hauptformular enthalten ist – und dieser lautet Null<\/b> (siehe Bild 9).<\/p>\n

\"Anlegen<\/p>\n

Bild 9: Anlegen von Daten im Unterformular ohne Datensatz im Hauptformular<\/span><\/b><\/p>\n

Wir haben also ein paar Bestellpositionen ohne Zuweisung zu einer Bestellung (siehe Bild 10).<\/p>\n

\"Bestellpositionen<\/p>\n

Bild 10: Bestellpositionen ohne BestellungID<\/span><\/b><\/p>\n

Noch schlimmer wird es, wenn der Mitarbeiter nun nach der Eingabe der Bestellpositionen die übrigen Daten der Bestellung nachträgt. Das sieht zu Beginn noch so aus, als würde es funktionieren (siehe Bild 11).<\/p>\n

\"Eingabe<\/p>\n

Bild 11: Eingabe der Bestelldaten nach den Bestellpositionen …<\/span><\/b><\/p>\n

Wenn der Benutzer dann allerdings zu einem anderen Datensatz wechselt und dann zum vorherigen Datensatz zurückkehrt, ist das Unterformular mit den Bestellpositionen plötzlich leer (siehe Bild 12).<\/p>\n

\"...<\/p>\n

Bild 12: … führt nach dem Datensatzwechsel zum Verschwinden der vermeintlich verknüpften Daten im Unterformular <\/span><\/b><\/p>\n

Was tun? Wir müssen irgendwie dafür sorgen, dass der Benutzer nur Daten in das Unterformular eingeben kann, wenn der Datensatz im Hauptformular bereits angelegt wurde.<\/p>\n

Daten erst ins Hauptformular eingeben<\/h2>\n

Um sicherzustellen, dass zuerst Daten ins Hauptformular und dann erst ins Unterformular eingegeben werden, wollen wir den Benutzer auf irgendeine Weise davon abhalten, die Daten umgekehrt einzugeben.<\/p>\n

Die erste Idee wäre, das Unterformular einfach zu sperren, wenn der Benutzer gerade einen neuen Datensatz anlegt und versucht, in das Unterformular zu springen, bevor es einen Primärschüsselwert im Hauptformular gibt.<\/p>\n

Das können wir mit einer Ereignisprozedur erledigen, die durch das Ereignis Beim Anzeigen <\/b>des Hauptformulars ausgelöst wird. Diese prüft mit der Eigenschaft NewRecord<\/b>, ob das Formular gerade einen neuen, leeren Datensatz enthält und stellt in diesem Fall die Eigenschaft Enabled <\/b>des Unterformular-Steuerelements auf den Wert False <\/b>ein, anderenfalls auf den Wert True<\/b>:<\/p>\n

Private Sub <\/span>Form_Current()\r\n     If <\/span>Me.NewRecord Then<\/span>\r\n         Me!sfmBestellungDetails.Enabled = False<\/span>\r\n     Else<\/span>\r\n         Me!sfmBestellungDetails.Enabled = True<\/span>\r\n     End If<\/span>\r\nEnd Sub<\/span><\/pre>\n
Dies können wir auch wesentlich kürzer schreiben:<\/p>\n
Private Sub <\/span>Form_Current()\r\n     Me!sfmBestellungDetails.Enabled = Not<\/span> Me.NewRecord\r\nEnd Sub<\/span><\/pre>\n
Was aber, wenn der Benutzer dann zum Beispiel den Kunden auswählt, was ja faktisch dazu führt, dass das Autowertfeld ID <\/b>der Tabelle tblBestellungen <\/b>einen Wert erhält und wir nun Bestellpositionen zum Unterformular hinzufügen könnten? Dann wäre das Unterformular immer noch gesperrt, weil die obigen Prozedur nur feuert, wenn ein Datensatz angezeigt wird. Aber auch das Ändern eines neuen Datensatzes löst ein Ereignis aus, nämlich Bei Geändert<\/b>. Für dieses Ereignis hinterlegen wir die folgende Prozedur, die das Unterformular aktiviert:<\/p>\n
Private Sub <\/span>Form_Dirty(Cancel As Integer<\/span>)\r\n     Me!sfmBestellungDetails.Enabled = True<\/span>\r\nEnd Sub<\/span><\/pre>\n
Somit kann der Benutzer nun auch Daten in das Unterformular eingeben.<\/p>\n
Benutzer sind allerdings einfallsreich und die nächste Schwachstelle, die sie finden könnten, ist Folgende: Wenn man nämlich den Datensatz im Hauptformular „dirty“ macht und dann die Esc<\/b>-Taste betätigt, werden die Änderungen wieder zurückgekommen und wir haben wieder einen unbefleckten Bestelldatensatz ohne ID<\/b>. Das Anlegen von Bestellpositionen im Unterformular ist allerdings aktuell möglich und würde zu den oben beschriebenen Problemen führen.<\/p>\n
<\/p>\n
Um dies zu verhindern, greifen wir das nächste spannende Ereignis ab, nämlich Bei Rückgängig<\/b>. Dieses wird ausgelöst, wenn der Benutzer beispielsweise mit der Esc<\/b>-Taste die bereits vorgenommen Änderungen verwirft. Hier deaktivieren wir einfach wieder das Unterformular, sofern sich im Hauptformular wieder ein neuer, leerer Datensatz befindet:<\/p>\n
Private Sub <\/span>Form_Undo(Cancel As Integer<\/span>)\r\n     Me!sfmBestellungDetails.Enabled = Not<\/span> Me.NewRecord\r\nEnd Sub<\/span><\/pre>\n
Damit kann der Benutzer nun zumindest keine nicht verknüpften Bestellpositionen mehr anlegen.<\/p>\n
Bezeichnungen der Steuerelemente anpassen<\/h2>\n
Bevor wir gleich mit weiteren VBA-Prozeduren fortfahren, in denen wir unter anderem auf die Inhalte von Steuerelementen zugreifen wollen, legen wir für diese zunächst sinnvolle Namen mit Präfix fest. Das heißt, Textfelder erhalten das Präfix txt<\/b>, Kombinationsfelder das Präfix cbo <\/b>und so weiter.<\/p>\n
Dies sollten Sie zumindest für solche Steuerelemente durchführen, auf die Sie per VBA zugreifen. Auf diese Weise unterscheiden Sie die Steuerelemente von den gleichnamigen, an das Formular gebundenen Felder der Datensatzquelle.<\/p>\n
In Bild 13 sehen Sie, wie wir den Namen für das Kombinationsfeld eingestellt haben, das an das Feld KundeID <\/b>gebunden ist.<\/p>\n
\"Einstellen<\/p>\n
Bild 13: Einstellen von Präfixen für die Steuerelementnamen<\/span><\/b><\/p>\n
Validierung<\/h2>\n
Wir wollen sicherstellen, dass wichtige Felder gefüllt werden. Also fügen wir eine Prozedur hinzu, die vor dem Speichern eines Datensatzes prüft, ob alle notwendigen Daten angegeben wurden. Im Falle des Hauptformulars handelt es sich um die Felder Bestellnummer<\/b>, KundeID <\/b>und BestelltAm<\/b>.<\/p>\n
Als Ereignis wählen wir hierfür das Ereignis Vor Aktualisierung <\/b>des Hauptformulars aus. Dieses wird immer ausgelöst, wenn der Benutzer Änderungen an einem vorhandenen oder neuen Datensatz vorgenommen hat und die Änderungen speichert, indem er den Datensatz wechselt, das Formular schließt oder auch den Datensatz gezielt beispielsweise mit der Tastenkombination Strg + S <\/b>speichert.<\/p>\n
Es gibt noch ein ähnliches Ereignis namens Nach Aktualisierung<\/b>, das direkt nach Vor Aktualisierung <\/b>ausgelöst wird – aber in diesem sind die Änderungen bereits gespeichert. Die durch das Ereignis Vor Aktualisierung <\/b>ausgelöste Ereignisprozedur hat außerdem den praktischen Vorteil, dass es einen Parameter namens Cancel <\/b>mitbringt, den man auf True <\/b>einstellen und so mit das Speichern des Datensatzes abbrechen kann.<\/p>\n
Also fügen wir für das Ereignis Vor Aktualisierung <\/b>die Prozedur aus Listing 1 hinzu. Diese prüft zunächst, ob das Steuerelement txtBestellnummer <\/b>leer ist. Falls ja, gibt es eine Meldung aus, setzt den Fokus auf dieses Steuerelement, stellt den Parameter Cancel <\/b>auf True <\/b>ein und bricht die Prozedur ab (siehe Bild 14).<\/p>\n
\"Anzeige<\/p>\n
Bild 14: Anzeige einer Validierungsmeldung<\/span><\/b><\/p>\n
Das Gleiche erledigen die beiden folgenden If…Then<\/b>-Blöcke für die Steuerelemente cboKundeID <\/b>und txtBestelltAm<\/b>. Erst wenn alle drei Felder gefüllt sind, kann der Datensatz gespeichert werden.<\/p>\n
Validierung für einzelne Steuerelemente<\/h2>\n
Zumindest für die Datumsfelder benötigen wir noch individuelle Validierungen, die direkt nach der Eingabe in diese Steuerelemente ausgelöst werden müssen. Wenn der Benutzer hier ein ungültiges Datum eingibt (zum Beispiel 30.2.2022<\/b>) oder einen Wert, der aus anderen Gründen nicht als Datum erkannt werden kann, erscheint ohne weiteres Zutun die Meldung aus Bild 15.<\/p>\n
\"Eingebaute<\/p>\n
Bild 15: Eingebaute Meldung bei Eingabe von Text in ein Datumsfeld<\/span><\/b><\/p>\n
Diese Meldung wollen wir unbedingt durch eine eigene Meldung ersetzen. Normalerweise sollte man annehmen, dass wir dies mit der Prozedur erledigen können, die wir für die Ereigniseigenschaft Vor Aktualisierung <\/b>des jeweiligen Textfeldes anlegen. Dieses Ereignis gibt es für das Formular selbst und auch für verschiedene Steuerelemente. Für das Textfeld txtBestelltAm <\/b>hinterlegen wir beispielsweise die Ereignisprozedur aus Listing 2. Diese funktioniert aber nicht – wir erhalten immer noch die Meldung aus der Abbildung.<\/p>\n
Private Sub <\/span>txtBestelltAm_BeforeUpdate(Cancel As Integer<\/span>)\r\n     If <\/span>Not<\/span> IsDate(Me!txtBestellnummer) Then<\/span>\r\n         MsgBox<\/span> \"Bitte geben Sie ein gültiges Bestelldatum ein.\", vbOKOnly + vbExclamation, \"Bestelldatum ist ungültig\"\r\n         Me!txtBestelltAm.SetFocus\r\n         Cancel = True<\/span>\r\n         Exit Sub<\/span>\r\n     End If<\/span>\r\nEnd Sub<\/span><\/pre>\n
Listing 2: Validierung eines Datumsfeldes<\/span><\/b><\/p>\n
Das Grund ist, dass Verletzungen von Restriktionen wie Eingabe ungültiger Werte für Datentypen einen Formularfehler auslösen, bevor das Ereignis Vor Aktualisierung <\/b>des Formulars ausgelöst wird. Also müssen wir ein anderes Ereignis für diese Validierung nutzen.<\/p>\n
Validieren mit Formularfehler<\/h2>\n
Es gibt mit Bei Fehler <\/b>ein Ereignis, dass genau bei solchen Fehlern ausgelöst wird. Die dadurch ausgelöste Prozedur hat zwei Parameter – DataErr <\/b>und Response<\/b>.<\/p>\n
Mit DataErr <\/b>wird die üblicherweise mit Err.Number <\/b>ermittelte Fehlernummer übergeben, welche den Fehler ausgelöst hat. Für den Fall der Eingabe eines falschen Datums lautet diese Nummer 2113<\/b>. Diese prüfen wir in der Prozedur aus Listing 3.<\/p>\n
Private Sub <\/span>Form_Error(DataErr As Integer<\/span>, Response As Integer<\/span>)\r\n     If <\/span>DataErr = 2113 Then<\/span>\r\n         Select Case Screen.ActiveControl.Name\r\n             Case <\/span>\"txtBestelltAm\"\r\n                 MsgBox<\/span> \"Bitte geben Sie ein gültiges Bestelldatum ein.\", vbOKOnly + vbExclamation, _\r\n                     \"Bestelldatum ist ungültig\"\r\n                 Response = acDataErrContinue\r\n             Exit Sub<\/span>\r\n         End Select<\/span>\r\n     End If<\/span>\r\nEnd Sub<\/span><\/pre>\n
Listing 3: Validierungen, die durch einen Formularfehler ausgelöst werden<\/span><\/b><\/p>\n
Hier prüfen wir außerdem noch mit Screen.ActiveControl.Name<\/b>, welches Steuerelement zur Zeit des Auslösens des Fehlers aktiv war. Handelt es sich um das Textfeld txtBestelltAm<\/b>, behandeln wir dies im Case<\/b>-Fall des folgenden Select Case<\/b>-Konstrukts.<\/p>\n
Hier geben wir wieder eine entsprechende Meldung aus und stellen außerdem den zweiten Parameter, der ein Rückgabeparameter ist, auf den Wert acDataErrContinue <\/b>ein. Das bedeutet, dass die eigentlich von Access zu diesem Zeitpunkt abgesetzte Fehlermeldung unterbunden werden soll. So erhalten wir schließlich unsere eigene Meldung, wenn der Benutzer ein ungültiges Datum eingibt.<\/p>\n
Validierung für eindeutige Felder<\/h2>\n
Das Feld Bestellnummer <\/b>ist mit einem eindeutigen Index versehen. Daher wird auch hier ein Fehler gemeldet, wenn der Benutzer für dieses Feld einen bereits in der Tabelle vorhandenen Wert eingibt. Dieser Fehler tritt allerdings erst beim Versuch auf, den Datensatz zu speichern. Wir können den Benutzer auch direkt bei der Eingabe darauf hinweisen, falls der Wert bereits vorhanden ist.<\/p>\n
Dazu nutzen wir wiederum das Ereignis Vor Aktualisierung<\/b>, diesmal für das Textfeld txtBestellnummer<\/b> (siehe Listing 4).<\/p>\n
Private Sub <\/span>txtBestellnummer_BeforeUpdate(Cancel As Integer<\/span>)\r\n     If <\/span>Not<\/span> IsNull(DLookup(\"ID\", \"tblBestellungen\", \"Bestellnummer = ''\" & Me!Bestellnummer & \"''\")) Then<\/span>\r\n         MsgBox<\/span> \"Die Bestellnummer ''\" & Me!Bestellnummer & \"'' ist bereits vergeben.\", vbOKOnly + vbExclamation, _\r\n             \"Doppelte Bestellnummer\"\r\n         Cancel = True<\/span>\r\n         Exit Sub<\/span>\r\n     End If<\/span>\r\nEnd Sub<\/span><\/pre>\n
Listing 4: Prüfung auf doppelte Bestellnummer<\/span><\/b><\/p>\n
Die If…Then<\/b>-Bedingung nutzt eine DLookup<\/b>-Anweisung, um zu prüfen, ob es bereits einen Datensatz in der Tabelle tblBestellungen <\/b>gibt, dessen Feld Bestellnummer <\/b>den in das Textfeld eingegebenen Wert enthält. Ist das der Fall, erscheint die Meldung aus Bild 16. Nach der Bestätigung wird die Eingabe mit Cancel = True <\/b>abgebrochen und die Prozedur verlassen.<\/p>\n
\"Meldung<\/p>\n
Bild 16: Meldung bei Eingabe einer bereits vorhandenen Bestellnummer<\/span><\/b><\/p>\n
Zahlungsziel<\/h2>\n
Für das Nachvollziehen der Rechnungseingänge macht es Sinn, das Feld Zahlungsziel <\/b>zu pflegen, das natürlich auch auf der Rechnung landen soll. Das Feld RechnungAm soll erst gefüllt werden, wenn die Rechnung tatsächlich geschrieben und versendet wurde. Dann kann man auch das Feld Zahlungsziel <\/b>füllen. <\/p>\n
Dazu benötigen wir natürlich noch den Zeitraum, der zwischen Rechnungserstellung und dem gewünschten Zahlungsziel liegt. Da diese Anzahl der Tage variabel sein soll, wollen wir sie nicht fest verdrahten, sondern diese in einer Tabelle mit Optionen speichern. Dazu kommen wir jedoch erst, wenn wir in einem späteren Beitrag die Erstellung des Rechnungsberichts beschreiben – dort zeigen wir dann auch, wie die Rechnungserstellung beispielsweise vom Formular frmBestellungDetails <\/b>angestoßen werden kann.<\/p>\n
Anlegen einer Bestellposition<\/h2>\n
Nachdem wir die Felder der Tabelle tblBestellungen<\/b>, die der Benutzer im Hauptformular füllen soll, beschrieben haben, können wir uns um das Unterformular und die dort anzuzeigenden Daten kümmern.<\/p>\n
Im Optimalfall benötigt der Kunde genau ein Exemplar eines Produkts. Dann braucht der Benutzer nur das Produkt aus dem Kombinationsfeld cboProduktID <\/b>auszuwählen. Sie sehen schon – auch in diesem Unterformular wollen wir die Namen der Steuerelemente mit einem Präfix versehen.<\/p>\n
Die übrigen Felder könnten dann direkt mit den entsprechenden Werten gefüllt werden:<\/p>\n