<\/p>\n
Erfahren Sie, wie Sie Variablen sitzungsübergreifend in Datenbank-Properties speichern können.<\/p>\n
SMTP, VBA<\/p>\n
Access 2000 und höher<\/p>\n
DBProperties.mdb<\/p>\n
Sascha Trowitzsch, Berlin<\/b><\/p>\n
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. <\/b><\/p>\n
<\/b><\/p>\n
Ein Beispiel für eine Einstellung, die man über Anwendungssitzungen hinweg speichern könnte, ist die Position von Fenstern.<\/p>\n
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.<\/p>\n
Andere Wege wären INI-Dateien (Textdateien) oder auch persistente disconnected ADO-Recordsets: Immerhin lassen sich auch ADO-Recordsets als Dateien abspeichern.<\/p>\n
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.<\/p>\n
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. <\/p>\n
Eine geöffnete Access-Datenbank im MDB-Format besitzt immer ein von der Bibliothek DAO abgeleitetes Database-Objekt.<\/p>\n
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.<\/p>\n
Und wie fast alle Objekte der DAO-Bibliothek hat auch das Database-Objekt eine Auflistung namens Properties.<\/p>\n
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).<\/p>\n
Access stellt diese Eigenschaften selbst ein, um dann beim öffnen der MDB zu wissen, wie es mit der Datenbank verfahren soll.<\/p>\n
Diese Eigenschaften sind eingebaut und können theoretisch weder per VBA gesetzt, noch gelöscht werden.<\/p>\n
Zumindest äußert sich die Online-Hilfe von Access so – eine Fehlinformation, wie Sie später sehen werden.<\/p>\n
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.)<\/p>\n
Neben den eingebauten Properties lassen sich aber beliebige selbst definierte Eigenschaften erzeugen und dann Werte in ihnen speichern.<\/p>\n
Sie lesen eine Database-Eigenschaft per VBA entweder über den Namen der Eigenschaft oder über ihre Ordinalnummer aus:<\/p>\n
Debug.Print CurrentDb.Properties(\"Name\")\r\nDebug.Print CurrentDb.Properties(1)<\/pre>\nErsetzt man die 1 in voriger Code-Zeile durch eine Variable, dann lassen sich alle Properties über eine Schleife auflisten:<\/p>\n
For i = 0 To 1000\r\n Debug.Print _ Currentdb.Properties(i).Name\r\nNext i<\/pre>\n<\/p>\n
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.<\/p>\n
Eleganter ist deshalb die folgende For Each-Schleife:<\/p>\n
Dim prp As DAO.Property\r\nFor Each prp In CurrentDb.Properties\r\n Debug.Print prp.Name, prp.Value\r\nNext prp<\/pre>\nNeben den Namen der Eigenschaften gibt diese Routine gleichzeitig noch mit prp.Value die Werte derselben aus. <\/p>\n
In der Beispieldatenbank finden Sie eine etwas ausführlichere und fehlerresistente Version dieser List-Funktion im Modul mdlProperties und in der Prozedur ListProperties.<\/p>\n
Property setzen<\/h3>\n
Der Wert für eine Property wird durch einfache Zuweisung gesetzt:<\/p>\n
CurrentDb.Properties(\"StartUpForm\")= \"frmStart\"<\/pre>\nDas ist eigentlich die Kurzform, denn eigentlich wird hier die Eigenschaft Value des Properties gesetzt (in einer Zeile):<\/p>\n
CurrentDb.Properties(\"StartUpForm\").Value<\/pre>\nValue ist jedoch die Default-Eigenschaft des Property-Objekts und kann daher weggelassen werden.<\/p>\n
Der Datentyp einer Property ist Variant, daher kann die Property beliebige Werte annehmen. Es können also zum Beispiel Long-Werte, Strings oder Datumswerte übergeben werden.<\/p>\n
Property erzeugen<\/h3>\n
Nun wird es interessant: über die DAO-Methode CreateProperty kann man eine benutzerdefinierte Eigenschaft erzeugen:<\/p>\n
CurrentDb.CreateProperty <Name>, _\r\n <Datentyp>, <Wert><\/pre>\nDer Datentyp ist eine der Konstanten der Enumeration DAO.DataTypeEnum – etwa dbText für einen String oder dbLong für einen Long-Integer. Der übergebene Wert muss dazu passen.<\/p>\n
Mit obiger Code-Zeile befindet sich das Property noch quasi im luftleeren Raum – ohne Bezug zum Datenbank-Objekt. Erst durch das Zuweisen zur Properties-Auflistung des Datenbank-Objekts wird es dann auch gespeichert:<\/p>\n
Dim prp As DAO.Property\r\nSet prp = CurrentDb.CreateProperty _ (\"Autor\", dbText, \"Trowitzsch\")\r\nCurrentDB.Properties.Append prp<\/pre>\nSomit ist in der benutzerdefinierten Eigenschaft „Autor“ der Datenbank der Wert „Trowitzsch“ gesetzt. Eine längere Alternative zu diesem Code wäre diese:<\/p>\n
Dim prp As DAO.Property\r\nSet prp = CurrentDb.CreateProperty _ (\"Autor\")\r\nprp.Type = dbText\r\nprp.Value = \"Trowitzsch\"\r\nCurrentDB.Properties.Append prp<\/pre>\nProperty löschen<\/h3>\n
Das Löschen einer Datenbankeigenschaft erfolgt mit dieser Anweisung:<\/p>\n
CurrentDb.Properties.Delete \"Autor\"<\/pre>\nNormalerweise dürfte das selten notwendig sein. Ein Fall wäre, dass Sie eine Property mit einem Datentyp angelegt hätten, diesen aber etwa von dbText in dbLong umwandeln wollten. Das geht nämlich nicht: Die Zuweisung eines neuen Datentyps führt zu einem Laufzeitfehler. Sie müssen die Property erst löschen und unter dem gleichen Namen mit dem neuen Datentyp anlegen.<\/p>\n
Hinweis<\/h3>\n
Wenn Sie versuchen, eine eingebaute Access-Eigenschaft zu löschen, beispielsweise Version, so löst das einen Fehler aus. Soweit entspricht dies der Aussage in der Online-Hilfe. Fraglich ist hier nur, was unter „eingebauter“ Eigenschaft zu verstehen ist. So existiert ein Property Build, das die Versionsnummer der msaccess.exe zurückgibt, mit der die Datenbank erstellt wurde. Man kann die Property löschen, sie wird beim nächsten Start der Datenbank aber automatisch wieder gesetzt. Das lässt sich auch noch mit weiteren von Access erzeugten Properties machen, wovon allerdings abzuraten ist. Es kann dazu führen, dass die Datenbank sich nicht mehr starten lässt. Im Versuch habe ich festgestellt, dass eine auf diese Weise „behandelte“ Datenbank mit keinerlei Reparaturversuchen wieder zum Leben zu erwecken war. Erstaunlicherweise gelang dann allerdings das öffnen in der Beta-Version von Access 2007 … <\/p>\n
Mit diesen Grundlagen können Sie nun öffentliche Routinen basteln, mit deren Hilfe sich von überall aus der Datenbank heraus Werte dauerhaft speichern und auslesen lassen. In der Beispieldatenbank finden Sie etwa die in Quellcode 1 dargestellte Routine.<\/p>\n
Die Prozedur SetAProperty erwartet als Parameter die Angabe eines Eigenschaftennamens in sName und des Wertes in AValue.<\/p>\n
Die Routine versucht zunächst, eine Objektvariable oPrp auf die Eigenschaft zu setzen. Schlägt dies fehl, weil etwa die Eigenschaft nicht existiert, so wird sie im If-Teil neu angelegt.<\/p>\n
Da dabei die Angabe des Datentyps zwingend notwendig ist, muss dieser aus dem übergebenen Wert selbst bestimmt werden. Das erledigt die VBA-Funktion VarType(). Leider stimmen die von dieser Funktion zurückgegebenen Konstanten nicht mit den Datentypen von DAO überein. Deshalb wird eine übersetzung der Konstanten in einer Hilfsfunktion TranslateType vorgenommen, die hier nicht abgebildet ist.<\/p>\n
Quellcode 1: Routine zum dauerhaften Speichern einer „Variablen“<\/b><\/p>\n
Sub SetAProperty(sName, AValue As Variant)\r\n Dim dbs As Database\r\n Dim oPrp As DAO.Property\r\n Set dbs = DBEngine(0)(0)\r\n On Error Resume Next\r\n Set oPrp = dbs.Properties(sName)\r\n If oPrp Is Nothing Then\r\n On Error GoTo 0\r\n Set oPrp = dbs.CreateProperty(sName, TranslateType(AValue), AValue)\r\n dbs.Properties.Append oPrp\r\n Else\r\n oPrp.Value = AValue\r\n End If\r\n Set oPrp = Nothing\r\n Set dbs = Nothing\r\nEnd Sub<\/pre>\nDie folgende Version ist wesentlich kürzer:<\/p>\n
Function GetAProperty(sName) As Variant\r\n On Error Resume Next\r\n GetAProperty = DBEngine(0)(0). _ Properties(sName).Value\r\nEnd Function<\/pre>\nIhnen fällt vielleicht auf, dass in diesen beiden Quellcodes statt CurrentDb die Variante DBEngine(0)(0) zum Einsatz kommt. Grund ist die wesentlich höhere Geschwindigkeit dieses Ausdrucks.<\/p>\n
Als Beleg das Resultat eines Tests, den Sie mit der Prozedur BenchmarkSetGetProp der Beispieldatenbank auch selbst ausführen können:<\/p>\n
Wird beim Auslesen CurrentDb.Properties verwendet, dann lässt sich die Funktion GetAProperty auf aktueller Hardware circa 1.500 Mal pro Sekunde aufrufen. Mit DBEngine(0)(0).Properties erhöht sich dieser Wert auf ca. 200.000! <\/p>\n
Das zeigt, dass sich diese benutzerdefinierten Datenbank-Properties auch gut in Schleifenkonstrukten verwenden lassen, weil das Auslesen nur sehr wenig Zeit kostet.<\/p>\n
In der Beispieldatenbank DBProperties.mdb finden Sie einige Anwendungsfälle für die in Kapitel 3 abgebildeten Routinen.<\/p>\n
So werden die Fensterpositionen der beiden Formulare frmKundenSimple und frmKundenKomplex beim Schließen in einer benutzerdefinierten Eigenschaft gespeichert und beim nächsten öffnen wiederhergestellt.<\/p>\n
Des Weiteren öffnet sich beim Start der Datenbank nach dem Intro-Formular immer das Beispielformular, das Sie zuletzt geöffnet hatten.<\/p>\n
Die dafür verantwortliche Code-Zeile sieht so aus:<\/p>\n
DoCmd.OpenForm GetAProperty(\"LastForm\")<\/pre>\nIm UnLoad-Ereignis der Formulare steht jeweils:<\/p>\n
SetAProperty \"LastForm\", Me.Name<\/pre>\nAußerdem wird jedes Formular mit dem Datensatz geöffnet, mit dem man es verlassen hat. Dazu wird beim Entladen in einer Eigenschaft der Primärschlüssel des Datensatzes gespeichert und beim öffnen mit Me.Recordset.FindFirst wieder angesprungen. Das funktioniert im Formular frmKundenKomplex sogar für den Detaildatensatz des eingebetteten Unterformulars.<\/p>\n
Downloads zu diesem Beitrag<\/h3>\n
Enthaltene Beispieldateien:<\/p>\n
DBProperties.mdb<\/p>\n