Tipps und Informationen rund um Microsoft AccessAufgrund meiner langjährigen Entwicklungserfahrung mit Access (aktuell fast 10 Jahre) habe ich mich entschlossen, auf dieser Seite einige Praxis-Tipps zu veröffentlichen, die vielleicht etwas abseits vom Tipps&Tricks-Mainstream angesiedelt sind und hauptsächlich erfahrenen Access-Entwicklern einen Mehrwert bieten können. Es handelt sich also nicht um Tipps für Einsteiger oder gelegentliche Access-Benutzer. Um Missverständnissen gleich vorzubeugen: Es geht hier natürlich nicht um persönliche Eitelkeit, sondern nur darum, sinnlose Doppelarbeit im Web zu vermeiden. Viele Fragen und Probleme zur Access-Praxis sind bereits auf anderen Webseiten in durchweg hoher Qualität behandelt worden (z.B. in der Access-FAQ von Karl Donaubauer - ohne Zweifel eine der besten Adressen in diesem Zusammenhang). Stattdessen versuche ich einfach, den öffentlichen Access-Wissenspool um ein paar (hoffentlich) neue und interessante Punkte zu ergänzen. Für weitere Anregungen zu den hier besprochenen Themen bin ich übrigens stets offen. Aktuell werden 3 Themen angeboten (und in Zukunft mehr, wenn es die Freizeit erlaubt): Vorab noch ein Hinweis: Es sollte ja eigentlich klar sein, aber denken Sie bitte trotzdem daran, die Beispiele auf dieser Seite nicht unbesehen in (womöglich geschäftskritische) Anwendungen zu übernehmen, ohne diese ausreichend im Hinblick auf eigene Qualitätsansprüche getestet zu haben (dass sie meinen genügen, ist eine andere Sache). Es handelt sich durchweg um ein freies Angebot: Sie dürfen den Code beliebig verändern und in eigenen Anwendungen einsetzen, eine Gewähr für fehlerfreie Code-Funktion oder für die Sicherheit Ihrer Daten ist aber ausgeschlossen. Access-Hauptfenster mit SDI-AnwendungsoptikDieser Tipp stellt eine interessante Methode vor, Ihre Access-Anwendung zumindest äußerlich wie eine SDI-Anwendung aussehen zu lassen (Access selbst ist eine MDI-Anwendung). Es geht also darum, dem User vorzugaukeln, er arbeite mit einer Anwendung, die nur aus einem Fenster besteht (Beispiel-Screenshot anzeigen). Prinzipiell können Sie das auch erreichen, indem Sie ein Formular maximiert öffnen, so dass es den gesamten MDI-Arbeitsbereich ausfüllt. Dann bleibt oben rechts in der Menüleiste aber mindestens ein Restore-Button übrig, und den bekommt man auch nicht so ohne weiteres weg. Ein weiterer unschöner Nebeneffekt: Haben Sie das Fenster beim Öffnen maximiert (Docmd.Maximize), werden alle anderen Fenster ebenfalls maximiert (z.B. auch das Datenbankfenster, was zumindest beim Entwickeln ziemlich nervt). Außerdem ist dann immer mindestens ein Formular geöffnet, das im Grunde überflüssig ist. Sie können es sich denken: Es gibt noch weitere Probleme mit dieser Methode. Lassen wir es mal dabei. Der Trick, die Hintergrundfarbe des MDI-Arbeitsbereichs zu ändern, ist viel eleganter und sicherer, um den gewünschten Effekt zu erreichen. Sie müssen sich dann um nichts weiter kümmern, als einfach das Formular, das den Basiskörper der Anwendung bildet, ohne Fensterrand zu öffnen und ggf. die Anzeige geöffneter Formulare in der Taskleiste abzuschalten. Letzteres lässt sich auch mit einem kleinen API-Hack bewerkstelligen, falls Sie die dafür zuständige und (leider) globale Default-Einstellung nicht ändern möchten. Ein weiteres kleines Problem, das nebenbei noch zu lösen ist, betrifft die Standard-Systemfarben für Formulare, die unter den verschiedenen Windows-Versionen geringfügig voneinander abweichen (jedenfalls betrifft das den bekannten grauen Fensterhintergrund). Damit der MDI-Hintergrund passend zu Formularen eingefärbt wird, deren Hintergrundfarbe auf einer Windows-Systemfarbe basiert, beinhaltet die Beispiel-Anwendung noch eine kleine Funktion zur Ermittlung des dezimalen RGB-Farbwerts aus der Farbe des Formular-Detailbereichs. Sie können natürlich auch eine eigene Farbe einstellen, wenn Sie dem Anwender sein Batman-Theme nicht gönnen möchten ;-)
Import/Export von Daten über die Windows-ZwischenablageWenn Ihnen TransferSpreadsheet und OutputTo auch schon mangels Flexibilität Kopfzerbrechen bereitet haben, ist dieses Beispiel vielleicht etwas für Sie: Es zeigt, wie Daten z.B. mit Excel über das Clipboard ausgetauscht werden können, wobei Sie die volle Kontrolle über diesen Prozess behalten. Außerdem ist der Vorgang recht flott - genauso schnell, wie Sie es vom manuellen Kopieren und Einfügen von Daten zwischen Anwendungen kennen. Das Konzept ist simpel und für Import und Export sehr ähnlich. Um Daten zu importieren, wird ein Formular, dass auf der Import-Zieltabelle (oder Abfrage) basiert und die entsprechenden Felder anzeigt, geöffnet. Die Daten aus der Quelle - im Beispiel eine Excel-Arbeitsmappe - werden mittels COM-Automatisierung in das Clipboard bugsiert und in Access über die korrespondierenden Menübefehle (acCmdSelectAllRecords, acCmdPasteAppend) in das Formular eingefügt. Soweit alles auch kein Problem. Der Trick besteht jetzt darin, diesen Vorgang in Access geschickt zu verbergen. Im Gegensatz zu Excel muss nämlich in Access ein Formular sichtbar sein, damit die genannten Menübefehle funktionieren. Dies wird im Beispiel dadurch bewerkstelligt, dass ein ungebundenes, nicht verschiebbares Popup-Fenster genau über dem Formular platziert wird, in das die Daten eingefügt werden sollen. Das funktioniert tatsächlich, weil das Popup-Fenster den Fokus an das darunterliegende Formular abgeben kann. Zusätzlich wird das Formular beim Öffnen auf eine Größe von 1 Twip verkleinert (das würde eigentlich auch genügen, da ein so kleines Formular ohnehin niemandem auffällt). Als besonderes Schmankerl ist es beim Importieren sogar möglich, per Code auf die Ereignisse zu reagieren, die beim Einfügen ausgelöst werden (z.B. Form_AfterInsert), und zwar für jeden einzelnen Datensatz. Das Import-Formular in der Beispiel-DB realisiert darüber einen Zähler, der den Import-Fortschritt anzeigt (siehe Code in Formular XPasteCount). Mit den Bordmittel-Importfunktionen ist das nicht machbar. Es gibt allerdings auch einen kleinen Schönheitsfehler, was den Import via Clipboard betrifft: Bei Einfügefehlern wird die Tabelle "Einfügefehler" angelegt, das ist leider nicht vermeidbar. Davon betroffen sind auch Datensätze, die Sie während des Imports per Code ablehnen (mittels Cancel=True im BeforeUpdate-Ereignis). Zum Exportieren von Daten: Das funktioniert, wie erwähnt, fast genauso wie das Importieren, nur agiert das verborgene Formular hier als Datenquelle. Ein Praxis-Anwendungsfall könnte z.B. darin bestehen, verschiedene Abfrage-Ergebnisse oder gefilterte Formular-Inhalte untereinander in ein Excel- oder Word-Dokument zu schreiben. Die OutputTo-Funktion will immer eine neue Datei erstellen, ist hier also unbrauchbar. TransferSpreadsheet funktioniert nur mit Tabellen und Abfragen, aber nicht mit Formularen als Datenquelle. Außerdem kann TransferSpreadsheet (wie der Name nahe legt) nur Excel- oder Lotus123-Dateien als Ziel verwenden. Mit der hier vorgestellten Methode kommen Sie etwas weiter, denn Sie können jeden COM-Server als Ziel verwenden, der Copy&Paste über Automatisierung unterstützt. Viel Spaß beim Experimentieren! Noch ein Wort zur Beispiel-DB: Die beigelegte Excel-Datei company.xls muss sich im selben Verzeichnis wie die MDB befinden. Sie dient als Datenquelle für den Import. Die Export-Funktion legt eine Datei export.xls im Verzeichnis der MDB an. Diese Datei wird vor einem Export automatisch gelöscht, falls sie existiert.
Speichern beliebiger Dateien in einer TabelleFalls Sie schon einmal in der Situation waren, komplette Dateien in Ihrer Datenbank unterbringen zu müssen, haben Sie vermutlich zuerst mal Bekanntschaft mit dem OLE-Feldtyp gemacht. Und dann schnell bemerkt, dass man damit nicht besonders weit kommt. Die zwei Prozeduren InputBinFile und OutputBinFile in der Beispiel-DB demonstrieren, wie man Dateien (egal welchen Typs oder Formats) bequem in einem Memofeld speichert und wieder abruft. Wenn Sie diese Lösung in Ihrer Anwendung benutzen wollen, achten Sie übrigens darauf, dass die Unicode-Kompression für das Memofeld, in dem die Dateidaten abgelegt werden sollen, abgeschaltet ist, sonst erhalten Sie Datensalat, falls eine Datei Unicode-Zeichenressourcen enthält - man weiß ja nie. Eine kleine Einschränkung: Eine Datei darf maximal 2 GB groß sein, mehr Daten kann das Memofeld nicht speichern. Damit wäre außerdem auch die Maximalgröße einer MDB erreicht. Als typischen Anwendungsfall sollten Sie ohnehin nicht die Speicherung einer Bilder- oder MP3-Sammlung in einer Access-DB in Betracht ziehen, sondern eher den integrierten Transport von Zusatzdateien (z.B. einer Hilfe-Datei). Bei Bedarf können Sie diese Dateien dann fix aus der DB heraus erzeugen und darauf zugreifen. Die Beispiel-DB enthält nur ein Modul mit den oben genannten Prozeduren und eine Tabelle für die Speicherung der Dateidaten, aber keine grafische Schnittstelle. Eine Beispieldatei (ein GIF-Bild) ist bereits in der Tabelle abgelegt. Zum Testen benutzen Sie einfach das VBA-Direktfenster: InputBinFile "c:\windows\calc.exe" - importiert die Datei calc.exe in die Tabelle BIN. OutputBinFile "attack.gif" - schreibt die Datei attack.gif in das aktuelle DB-Verzeichnis.
|
© melk.de 1998-2018 - 
