Datenmodelle für die Rechnungsverwaltung
Beim Schreiben von Anwendungen, mit denen Rechnungen erstellt werden sollen, stellt sich immer wieder die Frage nach dem korrekten Datenmodell. Davon ausgehend, dass es nicht das perfekte Datenmodell für alle Anwendungsfälle gibt, wollen wir in diesem Beitrag einmal unterschiedliche Ansätze betrachten und diskutieren. Diese haben eines gemein: Die Anwendung mit diesem Datenmodell soll die Möglichkeit bieten, sowohl Bestellungen zu erfassen als auch Rechnungen und Lieferscheinen zu erstellen. Wie welche Daten gespeichert werden und welche Möglichkeiten es gibt, schauen wir uns nun an.
Bug: Unterformular entlädt bei Bereichshöhe gleich 0
Es gibt den einen oder anderen Bug in Microsoft Access, der nicht als solcher identifiziert werden kann, weil man einfach nicht herausfindet, wie man ein Fehlverhalten reproduzierbar auslöst. Im vorliegenden Fall ist es einem unserer findigen Kollegen gelungen, einen Bug zu erkennen, der bisher nach unserer Recherche noch nicht dokumentiert wurde. Es handelt sich um einen Bug, der je nach Konstellation mal gar keine Auswirkungen hat und mal schwere Folgen mit sich bringen kann. Den Auslöser zu identifizieren ist auch alles andere als trivial – aber wir haben ihn gleich im Titel präsentiert: Wenn die Höhe eines Unterformulars gleich 0 wird, entlädt Access das Formular. Welche Schritte zum Nachvollziehen nötig sind, welche Folgen dies haben kann und wie sich das Problem beheben lässt, erläutern wir in diesem Beitrag.
Dateneingabe in Haupt- und Unterformular
Wenn man Daten in die Tabellen einer 1:n-Beziehung eingeben möchte, nutzt man in der Regel ein Haupt- und ein Unterformular. Das Hauptformular nimmt die Daten der Mastertabelle auf, das Unterformular die Daten der Detailtabelle. Wenn man nun keine weiteren Vorsichtsmaßnahmen trifft, kann der Benutzer Daten in das Unterformular eingeben, ohne dass das Hauptformular einen Datensatz anzeigt. Damit erzeugt er Datensätze in der Detailtabelle, die mit keinem Datensatz der Mastertabelle verknüpft sind. Das ist aus mehreren Gründen schlecht – diese schauen wir uns an und zeigen, wie wir das Problem beheben können.
Unterformular erst nach Validierung aktivieren
Im Beitrag Dateneingabe in Haupt- und Unterformular (www.access-im-unternehmen.de/1463) haben wir gezeigt, wir man bei der Eingabe neuer Daten verhindert, dass der Benutzer Daten in das Unterformular eingibt, bevor ein Datensatz im Hauptformular angelegt wurde. Das kann man noch vertiefen, wenn das Hauptformular Felder enthält, die validiert werden müssen, bevor der dortige Datensatz gespeichert werden kann. Wir schauen uns an einem einfachen Beispiel an, wie sich eine Validierung auf die Lösung aus dem oben genannten Beitrag auswirkt.
Benutzerdefinierte Standardwerte
Standardwerte für Felder legt in der Regel der Entwickler beim Definieren des Datenmodells in der Entwurfsansicht der Tabellen fest. Während man in bestimmten Maßen dynamische Werte nutzen kann wie beispielsweise mit der Datum()-Funktion für Datumsfelder, ist man ansonsten recht unflexibel. Leider lassen sich dort nur einige eingebaute Funktionen nutzen, wir können keine benutzerdefinierten VBA-Funktionen einsetzen. Aber welche benutzerdefinierten Standardwerte wollen wir überhaupt nutzen – und wo wollen wir diese festlegen? Die Einsatzzwecke sind vielfältig und prinzipiell können wir jedes Feld mit einem benutzerdefinierten Standardwert nutzen. Wichtig ist der Gedanke dahinter: Sinnvoll gewählte Standardwerte sparen dem Benutzer wertvolle Zeit bei der Dateneingabe. Wenn wir zum Beispiel eine Datenbank planen, die überwiegend weibliche Kontakte verwaltet, ist es sinnvoll, als Anrede »Frau« vorzugeben. Oder wir haben eine Autowerkstatt, die hauptsächlich Fahrzeuge einer bestimmten Marke repariert – dann macht es Sinn, diese vorzubelegen. Wir können auch dynamisch den zuletzt verwendeten Eintrag als Standardwert angeben oder auch den meistgenutzen. Wie wir dies realisieren, zeigen wir im vorliegenden Beitrag.
1:n-Beziehung mit Standardzuordnung verwalten
Im Beitrag »Rechnungsverwaltung: Kundenadressen ausgliedern« (www.access-im-unternehmen.de/1470) verwalten wir zu jedem Kunden mehrere Adressen, die dem Kunden über ein Fremdschlüsselfeld in der Adresstabelle zugewiesen sind. Für jeden Kunden legen wir in dieser Tabelle eine Standardadresse fest. Damit ist einiger Pflegeaufwand verbunden, denn wir müssen sicherstellen, dass immer genau eine Adresse je Kunde als Standardadresse markiert ist. In diesem Beitrag schauen wir uns an, wie wir sicherstellen können, dass die Daten immer konsistent sind und wir nicht plötzlich mehrere Standardadressen je Kunde vorfinden – oder gar keine.
Select Case-Bedingung für Texte optimieren
Normalerweise verwenden wir die Select Case-Bedingung so, dass wir im Kopf denen einen Teil des Vergleichsausdrucks platzieren und in den einzelnen Case-Zweigen die Vergleichswerte. Genau genommen ist das der große Unterschied zur If…Then-Bedingung, die immer den kompletten Ausdruck in einem Zweig darstellt. Die If…Then-Bedingung scheint daher bei der Auswertung von Zeichenketten Vorteile zu haben. Wir können aber auch die Select Case-Bedingung prima für Zeichenketten nutzen.
Standardzuordnung per Datenmakro
Während wir den Beitrag »1:n-Beziehung mit Standardzuordnung verwalten« (www.access-im-unternehmen.de/1469) schrieben, haben wir uns gefragt, ob man die Einhaltung der Konstistenz bei 1:n-Beziehungen mit Standardzuordnung nicht auch auf andere Weise sicherstellen kann als per VBA-Code. Zumal wir diesen auch noch in allen Formularen erneut programmieren müssten, welche die Daten aus dieser 1:n-Beziehung darstellen. Uns fielen zwei Lösungsansätze ein: Der erste sind die mit Access 2010 eingeführten Datenmakros, also eine Art Trigger für Access-Datenbanken. Die zweite sind die echten Trigger, und zwar die vom SQL Serve. In diesem Beitrag schauen wir uns nun die Variante mit den Datenmakros an. Kann man unser Vorhaben damit abbilden? Und wenn ja, wie?