Im ersten Teil dieser Artikelserie haben wir den Backstage-Bereich von Access mit eigenen Befehlen und einer Registerkarte ausgestattet, die Steuerelemente wie editBox, checkBox, dropDown, comboBox und radioGroup enth\u00e4lt. In diesem zweiten Teil gehen wir einen Schritt weiter: Wir lernen die Layout-Elemente groupBox, layoutContainer und imageControl kennen und bauen mit taskFormGroup und taskGroup komplexere Aufgabenbereiche auf.<\/p>\n
Zum Artikel …<\/a><\/p>\n Recordsets sind zentrale Bestandteile beim Zugriff auf Daten mit ADODB. Sie bieten umfangreiche Funktionen zur Navigation, Bearbeitung, Filterung und Analyse von Daten. In diesem Artikel zeigen wir eine vollst\u00e4ndige \u00dcbersicht aller Eigenschaften und Methoden des Recordset-Objekts und erl\u00e4utern diese jeweils ausf\u00fchrlich mit praktischen Beispielen. Besonderes Augenmerk legen wir auf die Ereignisse eines Recordsetes. Im Gegensatz zum DAO-Recordset bietet das ADODB-Recordset n\u00e4mlich die M\u00f6glichkeit, auf verschiedene Ereignisse zu reagieren \u2013 beispielsweise auf \u00c4nderungen im Datensatz.<\/p>\n Zum Artikel …<\/a><\/p>\n Wer Daten zwischen einer Access-Anwendung und einem SQL Server austauscht, landet fr\u00fcher oder sp\u00e4ter bei gespeicherten Prozeduren. Sie kapseln die Datenbanklogik serverseitig, liefern bessere Performance als dynamisch zusammengebautes SQL und lassen sich sauber rechtebasiert absichern. Der Aufruf per ADODB erfordert allerdings jedes Mal eine ganze Reihe gleicher Schritte: Verbindung \u00f6ffnen, Command-Objekt erzeugen, CommandType setzen, Parameter definieren, Werte zuweisen, Prozedur ausf\u00fchren, Ergebnis auslesen. Schreibt man das f\u00fcr jede Prozedur neu, w\u00e4chst der Code schnell zu un\u00fcbersichtlichen Ausma\u00dfen an. In diesem Artikel bauen wir ein kleines Wrapper-Modul, das diese Arbeit einmalig erledigt. Anschlie\u00dfend kannst Du jede gespeicherte Prozedur mit einer einzigen Zeile Code aufrufen \u2013 inklusive Parameter\u00fcbergabe und R\u00fcckgabewert. Als praktisches Beispiel binden wir den Wrapper an ein vollst\u00e4ndiges Mitarbeiter-Formular mit allen vier CRUD-Operationen an.<\/p>\n Zum Artikel …<\/a><\/p>\n Access-Formulare leben traditionell von ihrer Datensatzquelle. Du weist dem Formular eine Tabelle oder eine Abfrage zu, und Access k\u00fcmmert sich um alles Weitere \u2013 Navigieren, Bearbeiten, Speichern, L\u00f6schen. Das funktioniert hervorragend, solange die Daten in einer Access-Datenbank oder in verkn\u00fcpften Tabellen liegen. Arbeitest Du jedoch mit einem SQL Server und m\u00f6chtest den Datenzugriff ausschlie\u00dflich \u00fcber gespeicherte Prozeduren abwickeln \u2013 etwa, weil Du die Datenbanklogik serverseitig kapseln, Berechtigungen feingranular steuern oder die Performance optimieren willst \u2013, st\u00f6\u00dft dieses Modell an seine Grenzen. Gespeicherte Prozeduren lassen sich nicht als Datensatzquelle eines Formulars zuweisen, und die klassischen Access-Mechanismen zum Speichern greifen nicht. In diesem Artikel zeigen wir Dir, wie Du ein vollst\u00e4ndiges CRUD-Formular mit \u00dcbersicht und Detailansicht baust, das komplett ohne Datensatzquelle auskommt. Stattdessen f\u00fcllen wir die Unterformular-Recordsets und die Detailfelder zur Laufzeit mit dem Ergebnis gespeicherter Prozeduren, die wir \u00fcber den Wrapper aus dem Artikel \u00bbADODB: Gespeicherte Prozeduren einfach aufrufen\u00ab (www.vbentwickler.de\/505) aufrufen. Das Ergebnis ist eine Formularoberfl\u00e4che, die sich vom Benutzer aus anf\u00fchlt wie ein klassisches Access-Formular, intern aber ausschlie\u00dflich mit serverseitigen Prozeduren kommuniziert.<\/p>\n Zum Artikel …<\/a><\/p>\n Eine Prozedur, die monatelang unauff\u00e4llig ihren Dienst getan hat, bricht pl\u00f6tzlich mit einer kryptischen Meldung ab \u2013 und der Anwender steht vor einem Dialog, mit dem er nichts anfangen kann. Der Grund ist fast immer derselbe: Es gibt keine oder nur eine halbherzige Fehlerbehandlung. Dabei ist \u00bbOn Error\u00ab eines der m\u00e4chtigsten Werkzeuge in VBA, wenn man wei\u00df, wie man es einsetzt. Wir schauen uns die Muster an, die aus einer fragilen L\u00f6sung eine robuste machen: wie wir Fehler nicht nur abfangen, sondern strukturiert behandeln, Ressourcen zuverl\u00e4ssig freigeben, Fehler zwischen den Schichten einer Anwendung weiterreichen und sie in einer Tabelle protokollieren. Die Beispiele findest Du im Modul \u00bbmdlFehlerbehandlung\u00ab der Beispieldatenbank. Wie das im Einzelnen gelingt, zeigt der vorliegende Beitrag.<\/p>\n Zum Artikel …<\/a><\/p>\n Im Artikel \u00bbVBA Basics: Auflistungen mit Collections\u00ab (www.vbentwickler.de\/514) haben wir die Collection kennengelernt \u2013 eine einfache, geordnete Liste ohne Verweis. Ihr gr\u00f6sstes Manko: Es gibt keine M\u00f6glichkeit zu pr\u00fcfen, ob ein Schl\u00fcssel existiert. Genau hier setzt das Dictionary aus der Microsoft Scripting Runtime an. Es bietet Exists, erlaubt das direkte \u00c4ndern von Werten und liefert Schl\u00fcssel und Werte als Array \u2013 damit ist es die erste Wahl f\u00fcr Duplikatpr\u00fcfungen, H\u00e4ufigkeitsz\u00e4hlungen und Lookup-Tabellen im Speicher. Wie wir es einrichten, was es kann und wo Stolpersteine lauern, zeigt dieser Beitrag.<\/p>\n Zum Artikel …<\/a><\/p>\n Wer VBA-Code optimieren m\u00f6chte, braucht eine zuverl\u00e4ssige Methode zur Zeitmessung. Die VBA-Funktion Timer() liefert die verstrichenen Sekunden seit Mitternacht \u2013 und damit ein einfaches, aber wirkungsvolles Werkzeug, um die Laufzeit von Prozeduren zu messen und verschiedene Implementierungen zu vergleichen. In diesem Artikel zeigen wir, wie Du Timer() gezielt einsetzt und die Ergebnisse sinnvoll auswertest.<\/p>\nADODB: Gespeicherte Prozeduren ausf\u00fchren<\/h3>\n
ADODB: Access-Wrapper f\u00fcr gespeicherte Prozeduren<\/h3>\n
ADODB: Formulare mit gespeicherten Prozeduren<\/h3>\n
Fehlerbehandlung in VBA: Patterns f\u00fcr die Praxis<\/h3>\n
VBA Basics: Auflistungen mit Dictionarys<\/h3>\n
Timer() \u2013 Performance-Messungen in VBA<\/h3>\n