Flexible Schnellsuche
Wer kennt das nicht als Entwickler: Man möchte mal eben schnell in einer Tabelle nach einem bestimmten Datensatz suchen. Und das auch noch wiederholt, sodass man immer noch den Filter entfernen und diesen neu setzen muss – wozu wir die eingebauten Filter-Elemente der Datenblattansicht nutzen. Viel schöner wäre es doch, wenn wir mal eben das Kriterium und weitere Einstellungen über das Ribbon steuern könnten – während wir die Daten beim Filtern betrachten. Genau dazu haben wir uns für den Eigenbedarf eine kleine Schnellsuche gebaut, die wir in diesem Beitrag vorstellen. Das Beste: Selbst wenn Sie gar nicht genau erfahren wollen, wir es funktioniert, finden Sie die Lösung für 32-Bit- und 64-Bit-Access im Download zu diesem Beitrag.
Optionen einfach in der Registry speichern
In einem weiteren Beitrag namens »Registryeinträge für VBA-Anwendungen« (www.access-im-unternehmen.de/1508) haben wir dir grundlegenden Techniken für das Speichern von Anwendungsdaten in der Registry vorgestellt. Im vorliegenden Beitrag gehen wir noch einen Schritt weiter und vereinfachen diesen Vorgang, sodass die Befehle zum Lesen und Schreiben der Daten noch einfacher werden. Das Verwalten von Informationen wie beispielsweise von Anwendungsdaten in der Registry ist eine Alternative zum Verwenden einer Optionentabelle oder auch einer Textdatei im Anwendungsverzeichnis. Je nachdem, an wie vielen Stellen man lesend oder schreibend auf diese Daten zugreift, möchte man den Zugriff auf die Registry möglichst einfach gestalten. Dazu stellen wir nachfolgend ein paar geeignete Werkzeuge vor.
Fehler in der Runtime von Access finden
Wenn wir eine Datenbank, die unter der Vollversion von Access fehlerfrei läuft, in der Runtime öffnen, kann es zu unerklärlichen Fehlern kommen. Die Runtime verabschiedet sich dann in der Regel mit einer Meldung wie »Die Ausführung dieser Anwendung wurde wegen eines Laufzeitfehlers angehalten.« Damit können wir natürlich erst einmal nicht viel anfangen. Anlass zu diesem Beitrag ist ein konkretes Problem einer Kundin, deren Anwendung auf der Runtime-Version von Access nicht wie gewünscht funktioniert. Beim Testen der Anwendung in der Runtime kam ich jedoch gar nicht erst soweit wie die Kundin. Es tauchte bereits vorher die besagte Meldung auf. Wie können wir nun herausfinden, was genau den Fehler verursacht und welche Zeile ihn auslöst? Vorgehensweisen dazu stellen wir in diesem Beitrag vor.
Fehlerbehandlung per VBA hinzufügen
Eine Fehlerbehandlung ist Teil einer professionellen Datenbankanwendung auf Basis von Microsoft Access. Sobald wir eine Datenbank an einen Kunden oder Mitarbeiter weitergeben, also an einen anderen Benutzer als uns selbst, ist dies praktisch ein Pflichtprogramm. Die Fehlerbehandlung soll den Benutzer über einen Fehler informieren und diesem die Möglichkeit geben, dem Entwickler Informationen über den Fehler zukommem zu lassen. In diesem Beitrag wollen wir die Hauptarbeit bei der Implementierung einer Fehlerbehandlung erledigen. Dazu wollen wir eine Prozedur schreiben, die beliebige Routinen, also Sub-, Function- und Property-Prozeduren, mit einer einfachen Fehlerbehandlung ausstattet – und überdies noch mit einer Zeilennummerierung. Diese ist wichtig, wenn wir schnell herausfinden wollen, an welcher Stelle ein Fehler aufgetreten ist. Zusammen mit dem Namen des Moduls, dem Namen der Prozedur, der Fehlernummer und der Fehlerbeschreibung erhalten wir so Informationen, die in der Regel zum Aufdecken des Fehlers führen.
Zeilennummern per VBA hinzufügen
Wer eine wirklich professionelle Fehlerbehandlung zu seiner Access-Anwendung hinzufügen möchte, kommt nicht um das Anlegen von Zeilennummern herum. Wenn man Zeilennummern festgelegt hat, kann man diese im Falle eines Fehlers mit der nicht dokumentierten Erl-Funktion auslesen. Das heißt, dass wir neben der Fehlernummer und der Fehlerbeschreibung noch auf die Zeilennummer zurückgreifen können, um den Fehler zu lokalisieren. Dazu gehört allerdings auch, dass wir in der Fehlermeldung Informationen über das Modul und die Prozedur unterbringen, in denen der Fehler aufgetreten ist – doch dies lässt sich einfach realisieren. Sehr aufwändig ist es hingegen, alle Prozeduren von umfangreichen Anwendungen mit Zeilennummern zu versehen. Um dies zu realisieren, nutzen wir die Bibliothek Microsoft Visual Basic for Applications Extensibility 5.3, die alle Möglichkeiten bietet, um auf die enthaltenen Module zuzugreifen und den Code automatisiert nach unseren Wünschen anzupassen.
Seitenränder in Access-Berichten
Im Beitrag »Bericht mit unterschiedlichen Seitenrändern« (www.access-im-unternehmen.de/1517) haben wir untersucht, wie wir einem Bericht für gerade und ungerade Zahlen unterschliedliche Seitenränder zuweisen können. Das ist zunächst vor allem daran gescheitert, dass die in der Seiteneinrichtung zugewiesenen Seitenränder größer waren als die per VBA eingestellten. Diese konnten wir zwar korrigieren, aber scheinbar willkürlich wurden diese wieder auf Werte eingestellt, die nicht mit unseren Anpassungen harmonierten. Also schauen wir uns im vorliegenden Beitrag einmal an, woher diese Daten überhaupt kommen, wo sie gespeichert werden und wir wir dafür sorgen können, dass sie uns nicht ins Gehege kommen, wenn wir die Seitenränder einmal auf kleinere Werte einstellen als wir sie in den Seiteneinstellungen vorfinden.
Bericht mit unterschiedlichen Seitenrändern
Berichte werden in der Regel so ausgelegt, dass sie immer auf der linken Seite einen Rand zum Abheften haben. Bei den meisten Dokumenten ist das völlig ausreichend, zum Beispiel für Rechnungen oder Angebote. Es gibt jedoch auch wesentlich anspruchsvollere Aufgaben, die mit einer Access-Anwendung samt Bericht erledigt werden. Diese sollen dann so ausgedruckt werden können, dass Vorder- und Rückseite eines Blatts bedruckt werden und beim aufgeklappten Dokument der breitere Rand immer zur Heftung hin zeigt. Auch wenn die dazu notwendigen Einstellungen selten angewendet werden: Es gibt sie und in diesem Beitrag zeigen wir, wie man einen Bericht so druckt, dass die Seiten als Broschüre geheftet werden können.
Fehlerhafte Zeilen anzeigen lassen
Im Beitrag »Fehlerbehandlung per VBA hinzufügen« (www.access-im-unternehmen.de/1514) zeigen wir, wie man Fehlerinformationen direkt per VBA in eine Fehlertabelle schreiben, um diese später zu kontrollieren. Wenn man nun als Entwickler eine fehlerhafte Datei mit einigen protokollierten Fehlern vom Benutzer erhält, möchte man vielleicht direkt die fehlerhaften Stellen direkt einsehen. Dazu muss man allerdings erst nachsehen, welches Modul, welche Prozedur und welche Zeile betroffen sind, dann die entsprechende Stelle im VBA-Editor suchen und so weiter. Bei einer umfangreichen Datenbank kann das sehr mühselig werden, vor allem wenn man sich von Fehler zu Fehler hangelt. Deshalb liefern wir in diesem Beitrag noch eine praktische Ergänzung, wenn Sie ohnehin schon eine Tabelle wie aus dem oben genannten Beitrag zum Speichern der Fehler verwenden: Ein Formular, dass diese Fehler anzeigt und mit dem Sie per Mausklick auf einen Fehler direkt die entsprechende Stelle im VBA-Editor anzeigen können.
SQL Server-Datenbank kopieren
Wer für einen Kunden Datenbanken auf Basis von SQL Server programmiert, tut gut daran, nicht am offenen Herzen zu operieren, sprich: Änderungen an einer Datenbank erst an einer Kopie dieser Datenbank auszuprobieren. Wer seine eigenen Datenbanken auch auf dem SQL Server verwaltet, gerät da schon leichter in Versuchung, mal eben schnell eine Änderung am laufenden Produktivsystem durchzuführen. Auch wenn man meint, man wüsste genau, was man tut, macht es doch Sinn, zumindest eine Sicherheitskopie der zu bearbeitenden Datenbank anzulegen. Nun bietet der SQL Server keine einfache Lösung zum Herstellen einer Kopie á la Strg + C, Strg + V an. Allerdings wird man dennoch schnell fündig, wenn man nach einer entsprechenden Lösung sucht – in diesem Fall allerdings nur in höheren SQL Server-Editionen, also nicht in der Express Edition.
SQL Server Data Tools installieren und starten
Die SQL Server Data Tools sind eine Erweiterung für Visual Studio, mit denen wir interessante Aufgaben rund um die Verwaltung von SQL Server-Datenbanken erledigen können, die teilweise nicht mit dem SQL Server Management Studio möglich sind. Dazu gehört unter anderem das Vergleichen der Schemata zweier Datenbanken. Diese werden jedoch nicht zwingend direkt mit Visual Studio installiert, sodass wir uns in diesem Beitrag kurz ansehen, wie wir dies nachholen können – bevor wir uns in weiteren Beiträgen ansehen, was wir mit den SQL Server Data Tools alles erledigen können.
Schemata von SQL Server-Datenbanken vergleichen
Es kann in verschiedenen Szenarien sinnvoll sein, einmal den Unterschied zwischen zwei Versionen einer SQL Server-Datenbank zu vergleichen. Gibt es überhaupt Unterschiede? Welche Unterschiede sind das? Wurden Tabellen, Felder, Sichten, gespeicherte Prozeduren oder Trigger hinzugefügt oder entfernt? Wenn wir das herausfinden, können wir zum Beispiel identifizieren, welche Änderungen seit der letzten Veröffentlichung einer Datenbank als Produktivdatenbank in der Entwicklungsdatenbank durchgeführt wurden oder wir können herausfinden, wodurch ein Fehler ausgelöst werden könnte, der seit einem bestimmten Versionsstand immer wieder auftritt. In diesem Beitrag schauen wir uns zunächst einmal an, wie wir die Unterschiede zwischen den Schemata zweier Datenbanken ermitteln können. Dazu nutzen wir die SQL Server Data Tools, die wir in einem anderen Artikel bereits vorgestellt haben.
Wie speichert man Objekte und Module in Access?
Auch uns von Access im Unternehmen fallen immer mal wieder Techniken oder Dinge auf, die uns zuvor noch nicht bekannt waren – und die andere Entwickler schon lange wie selbstverständlich nutzen. Wenn uns so etwas auffällt, berichten wir gern darüber, denn: Wenn wir diese Technik noch nicht kennen, gibt es sicher noch andere Leser, die sich über einen neuen Trick freuen. In diesem Fall geht es um das Speichern von Objekten in Access. Wir zeigen erst einmal, wie das Speichern in Access überhaupt funktioniert und danach, welche für uns neue Technik wir dabei noch kennengelernt haben.