Wer kennt das nicht als Entwickler: Man m\u00f6chte 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 \u2013 wozu wir die eingebauten Filter-Elemente der Datenblattansicht nutzen. Viel sch\u00f6ner w\u00e4re es doch, wenn wir mal eben das Kriterium und weitere Einstellungen \u00fcber das Ribbon steuern k\u00f6nnten \u2013 w\u00e4hrend wir die Daten beim Filtern betrachten. Genau dazu haben wir uns f\u00fcr 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\u00f6sung f\u00fcr 32-Bit- und 64-Bit-Access im Download zu diesem Beitrag.<\/p>\n
Zum Artikel …<\/a><\/p>\n In einem weiteren Beitrag namens \u00bbRegistryeintr\u00e4ge f\u00fcr VBA-Anwendungen\u00ab (www.access-im-unternehmen.de\/1508) haben wir dir grundlegenden Techniken f\u00fcr 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\u00f6chte man den Zugriff auf die Registry m\u00f6glichst einfach gestalten. Dazu stellen wir nachfolgend ein paar geeignete Werkzeuge vor.<\/p>\n Zum Artikel …<\/a><\/p>\n Wenn wir eine Datenbank, die unter der Vollversion von Access fehlerfrei l\u00e4uft, in der Runtime \u00f6ffnen, kann es zu unerkl\u00e4rlichen Fehlern kommen. Die Runtime verabschiedet sich dann in der Regel mit einer Meldung wie \u00bbDie Ausf\u00fchrung dieser Anwendung wurde wegen eines Laufzeitfehlers angehalten.\u00ab Damit k\u00f6nnen wir nat\u00fcrlich 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\u00fcnscht 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\u00f6nnen wir nun herausfinden, was genau den Fehler verursacht und welche Zeile ihn ausl\u00f6st? Vorgehensweisen dazu stellen wir in diesem Beitrag vor.<\/p>\n Zum Artikel …<\/a><\/p>\n 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 \u00fcber einen Fehler informieren und diesem die M\u00f6glichkeit geben, dem Entwickler Informationen \u00fcber 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 \u2013 und \u00fcberdies 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\u00fchren.<\/p>\n Zum Artikel …<\/a><\/p>\n Wer eine wirklich professionelle Fehlerbehandlung zu seiner Access-Anwendung hinzuf\u00fcgen m\u00f6chte, 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\u00dft, dass wir neben der Fehlernummer und der Fehlerbeschreibung noch auf die Zeilennummer zur\u00fcckgreifen k\u00f6nnen, um den Fehler zu lokalisieren. Dazu geh\u00f6rt allerdings auch, dass wir in der Fehlermeldung Informationen \u00fcber das Modul und die Prozedur unterbringen, in denen der Fehler aufgetreten ist \u2013 doch dies l\u00e4sst sich einfach realisieren. Sehr aufw\u00e4ndig 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\u00f6glichkeiten bietet, um auf die enthaltenen Module zuzugreifen und den Code automatisiert nach unseren W\u00fcnschen anzupassen.<\/p>\n Zum Artikel …<\/a><\/p>\n Im Beitrag \u00bbBericht mit unterschiedlichen Seitenr\u00e4ndern\u00ab (www.access-im-unternehmen.de\/1517) haben wir untersucht, wie wir einem Bericht f\u00fcr gerade und ungerade Zahlen unterschliedliche Seitenr\u00e4nder zuweisen k\u00f6nnen. Das ist zun\u00e4chst vor allem daran gescheitert, dass die in der Seiteneinrichtung zugewiesenen Seitenr\u00e4nder gr\u00f6\u00dfer waren als die per VBA eingestellten. Diese konnten wir zwar korrigieren, aber scheinbar willk\u00fcrlich wurden diese wieder auf Werte eingestellt, die nicht mit unseren Anpassungen harmonierten. Also schauen wir uns im vorliegenden Beitrag einmal an, woher diese Daten \u00fcberhaupt kommen, wo sie gespeichert werden und wir wir daf\u00fcr sorgen k\u00f6nnen, dass sie uns nicht ins Gehege kommen, wenn wir die Seitenr\u00e4nder einmal auf kleinere Werte einstellen als wir sie in den Seiteneinstellungen vorfinden.<\/p>\n Zum Artikel …<\/a><\/p>\n 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\u00f6llig ausreichend, zum Beispiel f\u00fcr 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\u00f6nnen, dass Vorder- und R\u00fcckseite 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\u00fcre geheftet werden k\u00f6nnen.<\/p>\n Zum Artikel …<\/a><\/p>\n Im Beitrag \u00bbFehlerbehandlung per VBA hinzuf\u00fcgen\u00ab (www.access-im-unternehmen.de\/1514) zeigen wir, wie man Fehlerinformationen direkt per VBA in eine Fehlertabelle schreiben, um diese sp\u00e4ter zu kontrollieren. Wenn man nun als Entwickler eine fehlerhafte Datei mit einigen protokollierten Fehlern vom Benutzer erh\u00e4lt, m\u00f6chte 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\u00fchselig werden, vor allem wenn man sich von Fehler zu Fehler hangelt. Deshalb liefern wir in diesem Beitrag noch eine praktische Erg\u00e4nzung, 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\u00f6nnen.<\/p>\n Zum Artikel …<\/a><\/p>\n Wer f\u00fcr einen Kunden Datenbanken auf Basis von SQL Server programmiert, tut gut daran, nicht am offenen Herzen zu operieren, sprich: \u00c4nderungen an einer Datenbank erst an einer Kopie dieser Datenbank auszuprobieren. Wer seine eigenen Datenbanken auch auf dem SQL Server verwaltet, ger\u00e4t da schon leichter in Versuchung, mal eben schnell eine \u00c4nderung am laufenden Produktivsystem durchzuf\u00fchren. Auch wenn man meint, man w\u00fcsste genau, was man tut, macht es doch Sinn, zumindest eine Sicherheitskopie der zu bearbeitenden Datenbank anzulegen. Nun bietet der SQL Server keine einfache L\u00f6sung zum Herstellen einer Kopie \u00e1 la Strg + C, Strg + V an. Allerdings wird man dennoch schnell f\u00fcndig, wenn man nach einer entsprechenden L\u00f6sung sucht \u2013 in diesem Fall allerdings nur in h\u00f6heren SQL Server-Editionen, also nicht in der Express Edition.<\/p>\n Zum Artikel …<\/a><\/p>\n Die SQL Server Data Tools sind eine Erweiterung f\u00fcr Visual Studio, mit denen wir interessante Aufgaben rund um die Verwaltung von SQL Server-Datenbanken erledigen k\u00f6nnen, die teilweise nicht mit dem SQL Server Management Studio m\u00f6glich sind.\u00a0Dazu geh\u00f6rt 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\u00f6nnen \u2013 bevor wir uns in weiteren Beitr\u00e4gen ansehen, was wir mit den SQL Server Data Tools alles erledigen k\u00f6nnen.<\/p>\n Zum Artikel …<\/a><\/p>\n Es kann in verschiedenen Szenarien sinnvoll sein, einmal den Unterschied zwischen zwei Versionen einer SQL Server-Datenbank zu vergleichen. Gibt es \u00fcberhaupt Unterschiede? Welche Unterschiede sind das? Wurden Tabellen, Felder, Sichten, gespeicherte Prozeduren\u00a0oder Trigger hinzugef\u00fcgt oder entfernt? Wenn wir das herausfinden, k\u00f6nnen wir zum Beispiel identifizieren, welche \u00c4nderungen seit der letzten Ver\u00f6ffentlichung einer Datenbank als Produktivdatenbank in der Entwicklungsdatenbank durchgef\u00fchrt wurden oder wir k\u00f6nnen herausfinden, wodurch ein Fehler ausgel\u00f6st werden k\u00f6nnte, der seit einem bestimmten Versionsstand immer wieder auftritt. In diesem Beitrag schauen wir uns zun\u00e4chst einmal an, wie wir die Unterschiede zwischen den Schemata zweier Datenbanken ermitteln k\u00f6nnen. Dazu nutzen wir die SQL Server Data Tools, die wir in einem anderen Artikel bereits vorgestellt haben.<\/p>\nOptionen einfach in der Registry speichern<\/h3>\n
Fehler in der Runtime von Access finden<\/h3>\n
Fehlerbehandlung per VBA hinzuf\u00fcgen<\/h3>\n
Zeilennummern per VBA hinzuf\u00fcgen<\/h3>\n
Seitenr\u00e4nder in Access-Berichten<\/h3>\n
Bericht mit unterschiedlichen Seitenr\u00e4ndern<\/h3>\n
Fehlerhafte Zeilen anzeigen lassen<\/h3>\n
SQL Server-Datenbank kopieren<\/h3>\n
SQL Server Data Tools installieren und starten<\/h3>\n
Schemata von SQL Server-Datenbanken vergleichen<\/h3>\n