{"id":55000312,"date":"2016-02-01T00:00:00","date_gmt":"2020-01-24T15:59:33","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=312"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Alles_plausibel","status":"publish","type":"post","link":"https:\/\/access-basics.de\/index.php\/Alles_plausibel.html","title":{"rendered":"Alles plausibel"},"content":{"rendered":"

Fehleingaben in Datenbanken sind, nach eigener Erfahrung, ein Quell ständiger Reibereien in Unternehmen. Oft sind die Daten redundant, mangelhaft formatiert oder lückenhaft. Nachforschungen, wer nun dies oder jenes falsch gemacht habe, führen selten zu effizienterer Arbeitsatmosphäre. Dabei könnten doch Plausibilitätsprüfungen schon bei der Eingabe in Formulare einen großen Teil dieses Missstands beheben. Wir zeigen Ihnen einige Beispiele.<\/p>\n

Beispieldatenbank<\/h2>\n

Die Beispiele dieses Artikels finden Sie in der Datenbank 1602_Plausibel.accdb<\/b><\/p>\n

Plausible Kunden<\/h2>\n

Anhand der schon in der Ausgabe 11\/2015 vorgestellten Beispieldatenbank mit ihrem Kunden- und Bestellformular demonstrieren wir Ihnen die möglichen Fallstricke und zeigen Lösungsmöglichkeiten auf. Das Formular frmKunden<\/b> wurde dafür mit zusätzlichem VBA-Code aufgerüstet, der die Plausibilitätsprüfung der Eingabefelder garantieren soll.<\/p>\n

Ein immer wiederkehrender Vorgang ist die Neuanlage von Adressen, die bereits in der Datenbank vorhanden sind. Oft wird dies zu spät bemerkt, etwa dann, wenn an anderer Stelle auf die Adressen Bezug genommen und eine Verknüpfung mit anderen Daten hergestellt werden soll. Welche Adresse ist dann die richtige Besser, Sie bauen da eine Prüfung ein, ob etwa die Kombination von Nachname und Vorname schon existiert, um dem Anwender gegebenenfalls eine Meldung zu präsentieren, wie in Bild 1. Er hat dann die Möglichkeit, die Eingabe dennoch fortzusetzen – Namen sind ja tatsächlich nicht immer eindeutig -, oder er navigiert zur bereits vorliegenden Adresse, weil er diese übersah.<\/p>\n

\"Das<\/a><\/p>\n

Bild 1: Das Kundenformular der Beispieldatenbank implementiert diverse Plausibilitätsprüfungen<\/p>\n

Was hin und wieder ebenfalls passiert, ist die Eingabe überflüssiger Leerzeichen. So wird versehentlich ein Leerzeichen an den Anfang des Nachnamens gesetzt was zu „Aber, Jutta“ und “ Abel, Jutta“ führt. In einer sortierten Adressliste bemerkte man die Doppelung gar nicht, weil der String mit dem Leerzeichen die Adresse ganz nach vor setzte. Bauen Sie eine Eliminierung überflüssiger Leerzeichen ein, so ist derartigem Unbill vorgesorgt.<\/p>\n

Schlecht macht sich auch, wenn eine Auslieferung an den falschen Adressaten gerät, weil Ort und Postleitzahl nicht zueinander passen. Verknüpfen Sie beide miteinander über eine interne Postleitzahlentabelle, so können Sie auf Falschangaben reagieren und Korrekturen vorschlagen lassen.<\/p>\n

Und schließlich sind E-Mail-Adressen heutzutage genauso wichtig, wie die örtlichen Angaben. E-Mails, die den Adressaten nicht erreichen, haben Verzögerungen im Workflow zur Folge. Fehler infolge inkorrekter E-Mail-Eingaben können Sie wenigstens minimieren, indem die Eingabe einer Validitätsprüfung unterzogen wird.<\/p>\n

Formularnavigation<\/h2>\n

Bevor wir zum eigentlichen Thema kommen, beschreiben wir noch eine Erweiterung der Navigationsmöglichkeiten des Formulars. Da es keine Navigationsleiste anzeigt, muss zu einem Kunden über das Kombinationsfeld Gehe zu<\/b> gesprungen werden. In der bisherigen Form enthält diese Combobox eine Liste aller eingegebenen Kunden. Dabei fehlt die Möglichkeit, einen Kunden zu löschen oder neu anzulegen. Zwar könnten Sie zu diesem Zweck zusätzliche Schaltflächen Löschen und Neu in das Formular einfügen, doch auch das Kombinationsfeld macht’s möglich!<\/p>\n

Die Steuerelementdaten bestanden bislang ungefähr aus dem SQL-Ausdruck<\/p>\n

SELECT Nachname & \", \" & Vorname\r\nFROM tblKunden ORDER BY Nachname<\/pre>\n
Was wir möchten, sind die zwei zusätzlichen Einträge Neuer Kunde<\/b> und Kunde löschen<\/b> ganz oben in der Liste, so, wie dies Bild 2 zeigt. Da diese in der Tabelle tblKunden<\/b> nicht existieren, müssen sie künstlich eingebaut werden. Dazu eignet sich in erster Linie eine Union-Abfrage<\/b>. Für die Combobox<\/b> sieht der SQL-Ausdruck nun so aus:<\/p>\n
\"Die<\/a><\/p>\n
Bild 2: Die Combobox mit ihren zwei zusätzlichen Einträgen zum Neuanlegen und Löschen von Kunden<\/p>\n
(SELECT -1 AS ID, \"(Kunden löschen)\"\r\n          AS Vollname FROM tblKunden)\r\nUNION\r\n(SELECT 0 AS ID, \" (Neuer Kunde)\"\r\n          AS Vollname FROM tblKunden)\r\nUNION\r\n(SELECT tblKunden.ID, [Nachname] & \", \" & [Vorname]\r\n          AS Vollname FROM tblKunden)\r\nORDER BY Vollname;<\/pre>\n
Erstaunlich, aber wahr: Nicht nur zwei, sondern auch mehrere SELECT<\/b>-Abfragen können über die UNION<\/b>-Klausel miteinander kombiniert werden! Die eigentliche Abfrage steht ganz unten, wobei die Kombination aus Nach- und Vorname über den Feld-Alias<\/b> Vollname<\/b> ausgegeben wird. Damit die Einzelabfragen zusammengefasst werden können, müssen sie die gleiche Zahl von Feldern und die gleichen Feldnamen ausgeben. Das erste SELECT-Statement<\/b> setzt nun einfach den Wert -1<\/b> als ID<\/b> und den Vollnamen<\/b> auf (Kunden löschen)<\/b>. Als Tabelle im FROM<\/b>-Teil wird ebenfalls tblKunden<\/b> spezifiziert. Das ist aber völlig ohne Belang! Sie könnten hier genauso gut eine andere Tabelle einsetzen, weil auf deren Datensätze ja ohnehin nicht Bezug genommen wird. Nur ohne Tabelle geht es leider nicht. Von der Performance her ist es günstiger, die gleiche Tabelle zu verwenden, auf die im unteren Teil tatsächlich zugegriffen wird.<\/p>\n
Der Inhalt der zweiten Klammer ist identisch aufgebaut. Hier steht die ID<\/b> 0<\/b> für den Eintrag  (Neuer Kunde)<\/b>. Davor steht, wohlgemerkt, ein Leerzeichen! Das führt dazu, dass dieser Eintrag infolge der abschließenden aufsteigenden Sortierung über alle Datensätze in der ORDER BY<\/b>-Klausel ganz oben steht.<\/p>\n
Die Ereignisprozedur für das Kombinationsfeld cbFind<\/b> ist nun natürlich entsprechend anzupassen. Im Ereignis Nach Aktualisierung<\/b> kommt es zur Ausführung der Prozedur in Listing 1. Je nach Wert (cbFind.Value<\/b>) des Kombinationsfelds verzweigt der Select-Case<\/b>-Block in unterschiedliche Aktionen. Wurde etwa Neuer Kunde<\/b> ausgewählt, so ist der Wert von cbFind<\/b> 0<\/b>, was die DoCmd<\/b>-Anweisung GotoRecord<\/b> mit dem Parameter für einen neuen Datensatz auslöst. ähnlich bei -1<\/b> für Kunde löschen<\/b>, was den aktuellen Datensatz über die RunCommand<\/b>-Anweisung löschen würde. Konjunktiv deshalb, weil davor noch eine Sicherheitsabfrage über eine Messagebox<\/b> gestellt ist, die den Anwender auf den folgenden prekären Vorgang hinweist. Für alle anderen Werte von cbFind<\/b> kommt es zum unteren Else<\/b>-Teil des Blocks, der das Formular-Recordset<\/b> auf die gewünschte ID<\/b> einstellt und damit den Sprung zum entsprechenden Kunden im Formular erwirkt.<\/p>\n
Private Sub <\/span>cbFind_AfterUpdate()\r\n     On Error Resume Next<\/span>\r\n     Select Case Me!cbFind.Value\r\n     Case <\/span>0\r\n         DoCmd.GoToRecord acDataForm, Me.Name, acNewRec\r\n     Case <\/span>-1\r\n         If MsgBox<\/span>(\"Diesen Kunden wirklich löschen\", _\r\n             vbYesNo Or vbExclamation, \"Bestätigen:\") = vbYes Then\r\n                RunCommand acCmdDeleteRecord\r\n                Me!cbFind.Requery\r\n         End If<\/span>\r\n     Case Else<\/span>\r\n         Me.Recordset.FindFirst \"ID=\" & Me!cbFind.Value\r\n     End Select<\/span>\r\nEnd Sub<\/span><\/pre>\n
Listing 1: Das aktualisierte Kombinationsfeld cbFind lässt durch den Select Case-Zweig unterschiedliche Aktionen folgen<\/p>\n
Unerwünschte Leerzeichen<\/h2>\n
Der einfachste Teil der Plausibilitätsprüfungen ist das Entfernen vor- und nachstehender Leerzeichen. Wird im Eingabefeld für den Nachnamen<\/b> ein Name eingeben und ein versehentliches Leerzeichen vorangestellt, so entfernt die Ereignisprozedur Nach Aktualisierung<\/b> des Felds dieses über die Trim-Funktion sogleich:<\/p>\n
Private Sub <\/span>txtNachname_AfterUpdate()\r\n     Me!txtNachname.Value = _\r\n            Trim<\/span>(Me!txtNachname.Value)\r\nEnd Sub<\/span><\/pre>\n
Dies geschieht also unmittelbar nach dem Verlassen des Textfelds. Der Anwender hat gar keine Möglichkeit, ein Leerzeichen hineinzuschummeln.<\/p>\n
Auf gleiche Weise wird mit dem Vorname-Feld verfahren.<\/p>\n
Stimmige E-Mail-Adresse<\/h2>\n
Wird das Eingabefeld für die E-Mail-Adresse verlassen, so löst dies seine AfterUpdate<\/b>-Prozedur aus, wie in Listing 2. Hier kann die Adresse auf Validität getestet werden. Die Adresse wird zunächst der Variablen sMail<\/b> zugewiesen. Die Nz<\/b>-Funktion stellt dabei sicher, dass es bei geleertem Feld nicht zu einer Fehlermeldung kommt, weil dann der Feldwert nicht ein String, sondern Null<\/b> wäre. In diesem Fall ist die Länge des String in sMail<\/b> gleich 0<\/b>, was zum Verlassen der Prozedur führt.<\/p>\n
Private Sub <\/span>txtEmail_AfterUpdate()\r\n     Dim <\/span>sMail As String<\/span>\r\n     \r\n     sMail = Nz(Me!txtEmail.Value)\r\n     If <\/span>Len<\/span>(sMail) = 0 Then<\/span> Exit Sub<\/span>\r\n     If <\/span>IsEmailValid(sMail) Then<\/span> Exit Sub<\/span>\r\n     MsgBox<\/span> \"Die angegebene E-Mail-Adresse ist nicht korrekt!\", _\r\n                                                          vbExclamation\r\n     Me!txtEmail.SetFocus\r\nEnd Sub<\/span><\/pre>\n
Listing 2: überprüfung der E-Mail-Adresse auf Gültigkeit<\/p>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t
\n\n\t\t\n\t\t