Zusammenfassung
Erfahren Sie, wie Sie Variablen sitzungsübergreifend in Datenbank-Properties speichern können.
Techniken
SMTP, VBA
Voraussetzungen
Access 2000 und höher
Beispieldatenbank
DBProperties.mdb
Sascha Trowitzsch, Berlin
Komplexere Anwendungen benötigen in der Regel bestimmte Einstellungen, die ihr Verhalten oder manche Vorgabewerte bestimmen. In der Regel findet man im Menü einen Eintrag Optionen, der ein Dialogfenster für diese Einstellungen hervorbringt. Gespeichert werden diese Werte normalerweise in der Registry, wobei eine Installationsprozedur hier meist bereits Vorgabewerte setzt. Auch umfangreiche Access-Datenbanken brauchen häufig solche Voreinstellungen. Dieser Beitrag zeigt, wie Sie diese Werte in benutzerdefinierten Datenbankeigenschaften speichern.
Ein Beispiel für eine Einstellung, die man über Anwendungssitzungen hinweg speichern könnte, ist die Position von Fenstern.
Wird ein Fenster erneut geöffnet, dann soll es die gleiche Position und Größe auf dem Bildschirm haben, wie beim letzten Schließen. Komfortabel wäre auch, wenn beim Starten der Datenbank automatisch das zuletzt geöffnete Formular sichtbar würde – möglichst noch mit dem Datensatz, in dem man sich zuletzt befunden hat. Im Beitrag Steuerelemente mit Gedächtnis (Shortlink 394) können Sie lesen, wie sich diese Einstellungen entweder in einer speziellen Tabelle oder in der Registry ablegen lassen.
Andere Wege wären INI-Dateien (Textdateien) oder auch persistente disconnected ADO-Recordsets: Immerhin lassen sich auch ADO-Recordsets als Dateien abspeichern.
Die letzten zwei genannten Möglichkeiten setzen die Existenz separater Dateien voraus, die Registry-Methode funktioniert nur innerhalb des Windows-Kontos des jeweiligen Benutzers. Die Tabellenlösung ist nicht schlecht, benötigt aber einiges an Code und eine Tabelle, die besser vor den Augen des Anwenders versteckt sein sollte.
Es gibt aber noch eine fünfte und einfache Lösung, die sich die benutzerdefinierten Eigenschaften des Database-Objekts zu Nutze macht. In der Beispieldatenbank finden Sie Anwendungsbeispiele dazu.
Eine geöffnete Access-Datenbank im MDB-Format besitzt immer ein von der Bibliothek DAO abgeleitetes Database-Objekt.
Das ist selbst dann so, wenn kein Verweis auf die DAO-Bibliothek gesetzt ist. Das standardmäßig vorhandene Application-Objekt hat die Eigenschaften CurrentDb und DBEngine. Dabei ist DBEngine(0)(0) das eigentliche Database-Objekt, während CurrentDb eine kopierte Instanz desselben darstellt.
Und wie fast alle Objekte der DAO-Bibliothek hat auch das Database-Objekt eine Auflistung namens Properties.
Dahinter verbergen sich verschiedene Eigenschaften der Datenbank wie etwa Name (der Pfad zur MDB), Version (die JET-Version, unter der die Datenbank erstellt wurde) oder StartUpForm (das Formular, das beim öffnen der Datenbank angezeigt wird, falls angegeben).
Access stellt diese Eigenschaften selbst ein, um dann beim öffnen der MDB zu wissen, wie es mit der Datenbank verfahren soll.
Diese Eigenschaften sind eingebaut und können theoretisch weder per VBA gesetzt, noch gelöscht werden.
Zumindest äußert sich die Online-Hilfe von Access so – eine Fehlinformation, wie Sie später sehen werden.
Die einzelnen Versionen von Access enthalten außerdem unterschiedliche, aber abwärtskompatible Eigenschaften. (In der Betaversion Access 2007 sind etwa die Eigenschaften des neuen Navigationsbereichs hinzugekommen.)
Neben den eingebauten Properties lassen sich aber beliebige selbst definierte Eigenschaften erzeugen und dann Werte in ihnen speichern.
Property auslesen
Sie lesen eine Database-Eigenschaft per VBA entweder über den Namen der Eigenschaft oder über ihre Ordinalnummer aus:
Debug.Print CurrentDb.Properties("Name")
Debug.Print CurrentDb.Properties(1)
Ersetzt man die 1 in voriger Code-Zeile durch eine Variable, dann lassen sich alle Properties über eine Schleife auflisten:
For i = 0 To 1000
Debug.Print _ Currentdb.Properties(i).Name
Next i
Diese Schleife wird nach einigen Durchläufen einen Fehler hervorrufen, nämlich dann, wenn i einen Wert hat, der keiner gültigen Ordinalzahl mehr entspricht.
Eleganter ist deshalb die folgende For Each-Schleife:
Dim prp As DAO.Property
For Each prp In CurrentDb.Properties
Debug.Print prp.Name, prp.Value
Next prp
Neben den Namen der Eigenschaften gibt diese Routine gleichzeitig noch mit prp.Value die Werte derselben aus.
In der Beispieldatenbank finden Sie eine etwas ausführlichere und fehlerresistente Version dieser List-Funktion im Modul mdlProperties und in der Prozedur ListProperties.
Nur für Abonnenten
Ab hier wird’s wirklich spannend – der Rest ist exklusiv für Abonnenten.
Mit dem Abo von Access im Unternehmen bekommst du den kompletten Artikel – inklusive vollständigem Code, Beispieldatenbank und Schritt-für-Schritt-Erklärung.
So sparst du dir stundenlanges Herumprobieren, vermeidest teure Fehler in deiner Access-Anwendung und kannst Lösungen direkt in deinem Unternehmen einsetzen, statt nur darüber zu lesen.
Teste Access im Unternehmen jetzt 4 Wochen lang kostenlos: Voller Zugriff auf alle Artikel, Downloads und Beispieldatenbanken. Kein Risiko – wenn es für dich nicht passt, kündigst du einfach innerhalb der ersten vier Wochen.
Bereits Abonnent? Hier einloggen
Kostenlos & unverbindlich
Oder hast Du eine konkrete Frage zu Deiner eigenen Access-Anwendung?
Vielleicht stellt Deine Anwendung Dich vor eine Herausforderung, zu der Du bisher keine Lösung findest. Schlechte Performance, kein ausreichender Zugriffsschutz, Du bist unsicher über Dein Datenmodell oder Dein Code liefert unerklärliche Fehler?
In unserem kostenlosen Access-Audit schaut sich André Minhorst persönlich gemeinsam mit Dir Deine Lösung per Zoom an – und zeigt Dir, wo Datenmodell, VBA-Code, Ergonomie und Sicherheit Optimierungspotenzial bieten.
Jetzt kostenloses Access-Audit anfordern →