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\u00fcr alle Anwendungsf\u00e4lle gibt, wollen wir in diesem Beitrag einmal unterschiedliche Ans\u00e4tze betrachten und diskutieren. Diese haben eines gemein: Die Anwendung mit diesem Datenmodell soll die M\u00f6glichkeit\u00a0bieten, sowohl Bestellungen zu erfassen als auch Rechnungen und Lieferscheinen zu erstellen. Wie welche Daten gespeichert werden und welche M\u00f6glichkeiten es gibt, schauen wir uns nun an.<\/p>\n
Zum Artikel …<\/a><\/p>\n 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\u00f6st. 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\u00f6ser zu identifizieren ist auch alles andere als trivial \u2013 aber wir haben ihn gleich im Titel pr\u00e4sentiert: Wenn die H\u00f6he eines Unterformulars gleich 0 wird, entl\u00e4dt Access das Formular. Welche Schritte zum Nachvollziehen n\u00f6tig sind, welche Folgen dies haben kann und wie sich das Problem beheben l\u00e4sst, erl\u00e4utern wir in diesem Beitrag.<\/p>\n Zum Artikel …<\/a><\/p>\n Wenn man Daten in die Tabellen einer 1:n-Beziehung eingeben m\u00f6chte, 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\u00dfnahmen trifft, kann der Benutzer Daten in das Unterformular eingeben, ohne dass das Hauptformular einen Datensatz anzeigt. Damit erzeugt er Datens\u00e4tze in der Detailtabelle, die mit keinem Datensatz der Mastertabelle verkn\u00fcpft sind. Das ist aus mehreren Gr\u00fcnden schlecht \u2013 diese schauen wir uns an und zeigen, wie wir das Problem beheben k\u00f6nnen.<\/p>\n Zum Artikel …<\/a><\/p>\n 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\u00e4lt, die validiert werden m\u00fcssen, bevor der dortige Datensatz gespeichert werden kann. Wir schauen uns an einem einfachen Beispiel an, wie sich eine Validierung auf die L\u00f6sung aus dem oben genannten Beitrag auswirkt.<\/p>\n Zum Artikel …<\/a><\/p>\n Standardwerte f\u00fcr Felder legt in der Regel der Entwickler beim Definieren des Datenmodells in der Entwurfsansicht der Tabellen fest. W\u00e4hrend man in bestimmten Ma\u00dfen dynamische Werte nutzen kann wie beispielsweise mit der Datum()-Funktion\u00a0f\u00fcr Datumsfelder, ist man ansonsten recht unflexibel. Leider lassen sich dort nur einige eingebaute Funktionen nutzen, wir k\u00f6nnen keine benutzerdefinierten VBA-Funktionen einsetzen. Aber welche benutzerdefinierten Standardwerte wollen wir \u00fcberhaupt nutzen \u2013 und wo wollen wir diese festlegen? Die Einsatzzwecke sind vielf\u00e4ltig und prinzipiell k\u00f6nnen wir jedes Feld mit einem benutzerdefinierten Standardwert nutzen. Wichtig ist der Gedanke dahinter: Sinnvoll gew\u00e4hlte Standardwerte sparen dem Benutzer wertvolle Zeit bei der Dateneingabe. Wenn wir zum Beispiel eine Datenbank planen, die \u00fcberwiegend weibliche Kontakte verwaltet, ist es sinnvoll, als Anrede \u00bbFrau\u00ab vorzugeben. Oder wir haben eine Autowerkstatt, die haupts\u00e4chlich Fahrzeuge einer bestimmten Marke repariert \u2013 dann macht es Sinn, diese vorzubelegen. Wir k\u00f6nnen auch dynamisch den zuletzt verwendeten Eintrag als Standardwert angeben oder auch den meistgenutzen. Wie wir dies realisieren, zeigen wir im vorliegenden Beitrag.<\/p>\n Zum Artikel …<\/a><\/p>\n Im Beitrag\u00a0\u00bbRechnungsverwaltung: Kundenadressen ausgliedern\u00ab (www.access-im-unternehmen.de\/1470) verwalten wir zu jedem Kunden mehrere Adressen, die dem Kunden \u00fcber ein Fremdschl\u00fcsselfeld in der Adresstabelle zugewiesen sind. F\u00fcr jeden Kunden legen wir in dieser Tabelle eine Standardadresse fest. Damit ist einiger Pflegeaufwand verbunden, denn wir m\u00fcssen sicherstellen, dass immer genau eine Adresse je Kunde als Standardadresse markiert ist. In diesem Beitrag schauen wir uns an, wie wir sicherstellen k\u00f6nnen, dass die Daten immer konsistent sind und wir nicht pl\u00f6tzlich mehrere Standardadressen je Kunde vorfinden \u2013 oder gar keine. <\/p>\n Zum Artikel …<\/a><\/p>\n Normalerweise verwenden wir die Select Case-Bedingung\u00a0so, dass wir im Kopf denen einen Teil des Vergleichsausdrucks platzieren und in den einzelnen Case-Zweigen die Vergleichswerte. Genau genommen ist das der gro\u00dfe 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\u00f6nnen aber auch die Select Case-Bedingung prima f\u00fcr Zeichenketten nutzen.<\/p>\nBug: Unterformular entl\u00e4dt bei Bereichsh\u00f6he gleich 0<\/h3>\n
Dateneingabe in Haupt- und Unterformular<\/h3>\n
Unterformular erst nach Validierung aktivieren<\/h3>\n
Benutzerdefinierte Standardwerte<\/h3>\n
1:n-Beziehung mit Standardzuordnung verwalten<\/h3>\n
Select Case-Bedingung f\u00fcr Texte optimieren<\/h3>\n