Backstage-Bereich von Access erweitern, Teil 2
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ält. 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.
ADODB: Gespeicherte Prozeduren ausführen
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ändige Übersicht aller Eigenschaften und Methoden des Recordset-Objekts und erläutern diese jeweils ausführlich mit praktischen Beispielen. Besonderes Augenmerk legen wir auf die Ereignisse eines Recordsetes. Im Gegensatz zum DAO-Recordset bietet das ADODB-Recordset nämlich die Möglichkeit, auf verschiedene Ereignisse zu reagieren – beispielsweise auf Änderungen im Datensatz.
ADODB: Access-Wrapper für gespeicherte Prozeduren
Wer Daten zwischen einer Access-Anwendung und einem SQL Server austauscht, landet früher oder später 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 öffnen, Command-Objekt erzeugen, CommandType setzen, Parameter definieren, Werte zuweisen, Prozedur ausführen, Ergebnis auslesen. Schreibt man das für jede Prozedur neu, wächst der Code schnell zu unübersichtlichen Ausmaßen an. In diesem Artikel bauen wir ein kleines Wrapper-Modul, das diese Arbeit einmalig erledigt. Anschließend kannst Du jede gespeicherte Prozedur mit einer einzigen Zeile Code aufrufen – inklusive Parameterübergabe und Rückgabewert. Als praktisches Beispiel binden wir den Wrapper an ein vollständiges Mitarbeiter-Formular mit allen vier CRUD-Operationen an.
ADODB: Formulare mit gespeicherten Prozeduren
Access-Formulare leben traditionell von ihrer Datensatzquelle. Du weist dem Formular eine Tabelle oder eine Abfrage zu, und Access kümmert sich um alles Weitere – Navigieren, Bearbeiten, Speichern, Löschen. Das funktioniert hervorragend, solange die Daten in einer Access-Datenbank oder in verknüpften Tabellen liegen. Arbeitest Du jedoch mit einem SQL Server und möchtest den Datenzugriff ausschließlich über gespeicherte Prozeduren abwickeln – etwa, weil Du die Datenbanklogik serverseitig kapseln, Berechtigungen feingranular steuern oder die Performance optimieren willst –, stößt 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ändiges CRUD-Formular mit Übersicht und Detailansicht baust, das komplett ohne Datensatzquelle auskommt. Stattdessen füllen wir die Unterformular-Recordsets und die Detailfelder zur Laufzeit mit dem Ergebnis gespeicherter Prozeduren, die wir über den Wrapper aus dem Artikel »ADODB: Gespeicherte Prozeduren einfach aufrufen« (www.vbentwickler.de/505) aufrufen. Das Ergebnis ist eine Formularoberfläche, die sich vom Benutzer aus anfühlt wie ein klassisches Access-Formular, intern aber ausschließlich mit serverseitigen Prozeduren kommuniziert.
Fehlerbehandlung in VBA: Patterns für die Praxis
Eine Prozedur, die monatelang unauffällig ihren Dienst getan hat, bricht plötzlich mit einer kryptischen Meldung ab – 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 »On Error« eines der mächtigsten Werkzeuge in VBA, wenn man weiß, wie man es einsetzt. Wir schauen uns die Muster an, die aus einer fragilen Lösung eine robuste machen: wie wir Fehler nicht nur abfangen, sondern strukturiert behandeln, Ressourcen zuverlässig freigeben, Fehler zwischen den Schichten einer Anwendung weiterreichen und sie in einer Tabelle protokollieren. Die Beispiele findest Du im Modul »mdlFehlerbehandlung« der Beispieldatenbank. Wie das im Einzelnen gelingt, zeigt der vorliegende Beitrag.
VBA Basics: Auflistungen mit Dictionarys
Im Artikel »VBA Basics: Auflistungen mit Collections« (www.vbentwickler.de/514) haben wir die Collection kennengelernt – eine einfache, geordnete Liste ohne Verweis. Ihr grösstes Manko: Es gibt keine Möglichkeit zu prüfen, ob ein Schlüssel existiert. Genau hier setzt das Dictionary aus der Microsoft Scripting Runtime an. Es bietet Exists, erlaubt das direkte Ändern von Werten und liefert Schlüssel und Werte als Array – damit ist es die erste Wahl für Duplikatprüfungen, Häufigkeitszählungen und Lookup-Tabellen im Speicher. Wie wir es einrichten, was es kann und wo Stolpersteine lauern, zeigt dieser Beitrag.
Timer() – Performance-Messungen in VBA
Wer VBA-Code optimieren möchte, braucht eine zuverlässige Methode zur Zeitmessung. Die VBA-Funktion Timer() liefert die verstrichenen Sekunden seit Mitternacht – 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.
Datenbank-Zeitreisen: Temporal Tables im SQL Server
Wer hat den Preis geändert, und wie hoch war er eigentlich vor drei Wochen? Wann ist dieser Datensatz gelöscht worden, und wie sah er kurz davor aus? Sobald eine Datenbank produktiv läuft, tauchen solche Fragen auf – und oft steht man mit leeren Händen da, weil die alten Werte längst überschrieben sind. Der klassische Ausweg ist eine selbstgebaute Historientabelle samt Triggern, die bei jedem INSERT, UPDATE und DELETE die alte Zeile wegschreiben. Das funktioniert, ist aber Handarbeit. Der SQL Server bringt seit der Version 2016 eine eingebaute Lösung mit: System-Versioned Temporal Tables. Die Datenbank führt die komplette Änderungshistorie vollautomatisch mit, und Abfragen zu einem beliebigen Zeitpunkt der Vergangenheit sind eine Zeile Zusatz-SQL. Wie das gelingt, wie und wo die alten Daten landen und wie Du eine bestehende Tabelle nachträglich versionierst, liest Du in diesem Beitrag – und auch, was Temporal Tables nicht können.