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.

Weiterlesen

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.

Weiterlesen

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.

Weiterlesen

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.

Weiterlesen

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.

Weiterlesen

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.

Weiterlesen

Schneller, weiter, höher mit LAA für Access 32-Bit

Es gibt einen Grund, warum man Access in der 64-Bit-Version gegenüber der 32-Bit-Version bevorzugen könnte, und das ist der virtuelle Arbeitsspeicher. Dieser beträgt bei der 64-Bit-Version satte vier Gigabyte, während die 32-Bit-Version nur zwei Gigabyte bietet. Dies wirkt sich vor allem dann aus, wenn viele Formulare oder Recordsets geöffnet sind – dann knallt es irgendwann einfach. Das lässt sich allerdings ändern, allerdings mit einem nicht ganz einfachen Eingriff: Es gibt in der MSAccess.exe genau ein Bit, das man ändern muss, damit auch die 32-Bit-Version über vier Gigabyte Arbeitsspeicher verfügt. Das ist erstens ohne Hilfsmittel nicht zu machen und zweitens wird diese Änderung wieder rückgängig gemacht, wenn ein Update eine neue Version der MSAccess.exe mitbringt. Also haben wir neben den Grundlagen zu diesem Problem, die wir in diesem Beitrag beschreiben, auch noch ein Tool mitgebracht, mit dem Sie die Performance von Access 32-Bit verbessern können.

Weiterlesen

Access-Speicher überwachen mit VMMap

Trotz eigentlich ausreichenden Arbeitsspeichers und sonstiger Systemresourcen kann es vorkommen, dass Access in die Knie geht. Das macht sich durch verschiedene Fehlermeldungen bemerkbar. Aber wo liegen eigentlich die Grenzen von Access in der 32-Bit- und der 64-Bit-Version und wie findet man heraus, wieviele Formulare oder Recordsets Access vertragen kann? Das schauen wir uns in diesem Beitrag einmal genauer an. Dabei nutzen wir ein Tool namens VMMap von Microsoft, mit dem wir uns den Speicherbedarf von Anwendungen wie Access genau ansehen können.

Weiterlesen

Dekompilieren leicht gemacht

Manchmal treten in Access-Datenbanken nicht erklärbare Fehler auf. Die Datenbank stürzt immer an der gleichen Stelle ab, scheinbar ohne dass es eine Ursache dafür gibt. Oder man hat einen Haltepunkt gesetzt und wieder entfernt und der Code wird aber immer noch an der Stelle des Haltepunkts angehalten. Solche und andere Fehler können wir mit der Komprimieren und Reparieren-Funktion nicht beheben, auch wenn der Name dies suggeriert. Es ist vielmehr noch ein kleiner zusätzlicher Schritt notwendig, nämlich das Dekompilieren des Codes. Dazu gibt es eine Befehlszeilenoption mit dem Namen /decompile. Dieser Beitrag zeigt, wie Sie eine Datenbank, die Probleme macht, gegebenenfalls selbst retten können.

Weiterlesen

Memofelder mit sehr langen Texten

In Feldern, deren Felddatentyp früher Memofeld hieß und heute „langer Text“ genannt wird, kann man bis zu einem Gigabyte an Daten speichern. Allerdings gibt es verschiedene Einschränkung bezüglich der Datenmenge. So kann man je nach der Speichermethode nur sehr viel weniger Zeichen eingeben. Und erst recht kann man nicht den kompletten Inhalt eines Memofeldes in einem Textfeld anzeigen, wenn dieses mehr als eine bestimmte Menge Zeichen enthält. In diesem Artikel schauen wir uns einmal an, welche Einschränkungen es gibt, wie man diese gegebenenfalls umgehen kann und welchen Nutzen Memofelder überhaupt haben, wenn man mehr als den anzeigbaren Text eingibt.

Weiterlesen