Wann immer ein Fehler auftritt, dessen Ursache nicht bekannt ist, oder eine Anwendung unerwartete Ergebnisse liefert, ist es Zeit fürs Debugging (zu deutsch: austesten, entwanzen, Fehler suchen und beseitigen). Unter Access spielt sich dies zum größten Teil in der VBA-Entwicklungsumgebung ab. Wir erläutern, wie Debugging funktioniert, welche Werkzeuge die gute alte VBA-IDE liefert und welche Tricks Sie einsetzen können.
Den VBA-Editor kann man in seiner jetzigen Form fast schon als altehrwürdig einstufen. An ihm perlt mühelos ab, was die Benutzer anderer, modernerer Entwicklungsumgebungen auf Trab hält: nämlich ständige Innovationen.
Mit dem Wechsel zu Access 2007 gab es genau eine änderung, die den meisten Entwicklern noch nicht einmal aufgefallen sein dürfte: Für den Einsatz des Mausrades zum Scrollen durch die Zeilen eines Moduls braucht man nun kein separates Tool mehr. Falls Sie Access 2007 verwenden und dieses Tool trotzdem installiert haben: Sie können es von der Festplatte werfen.
Davon abgesehen ist auf den VBA-Editor schon Verlass: Er bildet zusammen mit Access ein eingespieltes Team und fällt eher durch Beständigkeit denn durch stetige Weiterentwicklung auf.
Das ist aber kein Grund, ihn nicht einmal genauer unter die Lupe zu nehmen und zu zeigen, wie Sie Fehlern und Fehlverhalten mit seiner Hilfe auf die Schliche kommen. Immerhin bietet der VBA-Editor einige Möglichkeiten zum Debuggen des enthaltenen Codes.
Gründe für das Debugging
Eigentlich ist es ja so: Sie programmieren etwas, probieren es aus und entweder es funktioniert oder nicht. Falls nicht, möchten Sie natürlich gern herausfinden, woran dies liegt. Im besten Fall tritt einfach irgendwo ein Fehler auf und der VBA-Editor stößt Sie mit der Nase darauf, indem er eine entsprechende Meldung ausgibt und die fehlerhafte Zeile gelb hervorhebt.
Mit etwas Glück lässt sich die Herkunft des Fehlers in unmittelbarer Umgebung entdecken; falls nicht, ist eine umfangreichere Analyse angezeigt. Wir sprechen hier nicht von Kompilier- oder Syntaxfehlern, sondern von Laufzeitfehlern, die oft bei der Verarbeitung falscher oder inkompatibler Daten auftreten. Noch unangenehmer sind Fehler, die nicht in einer Fehlermeldung resultieren, sondern schlicht falsche oder unerwartete Antworten der Anwendung erzeugen.
Arten von Debugging
Dieser Beitrag unterscheidet zwei Arten von Debugging: Die erste enthält alle Aktivitäten, die mit der änderung von Code zum Zwecke des Debuggings einhergehen, die zweite beschäftigt sich mit dem “berührungslosen" Debugging: Hier wird der eigentliche Code nicht angefasst, sondern durch das Setzen von Haltepunkten und externes Abfragen von Informationen etwa über das Direktfenster oder das Überwachungsfenster analysiert.
Bevor wir diese beiden Arten vorstellen, schauen wir uns kurz die Grundzüge an, das manuelle Debuggen von Code ohne weitere Hilfsmittel.
Code manuell durchlaufen
Um Code manuell zu durchlaufen, positioniert man einfach die Einfügemarke auf der Prozedur, die man durchlaufen möchte, und wählt entweder den Menüpunkt Debuggen|Einzelschritt aus oder drückt gleich auf die Taste F8.
Es erscheinen dann wie in Bild 1 ein gelber Pfeil und eine gelbe Markierung der aktuellen Zeile. Das Debuggen kann beginnen – weiteres Drücken der Schaltfläche F8 arbeitet den Code schrittweise ab, wobei die Deklarationszeilen übergangen werden. F8 springt auch zu Prozeduren, welche die aktuelle Prozedur aufruft.
Unter Umständen ist das nicht gewünscht, weil die von dort aufgerufene Prozedur eine Menge Code enthält, den Sie in Ihrer Untersuchung nicht berücksichtigen möchten. In diesem Fall verwenden Sie die Tastenkombination Umschalt + F8. Damit durchlaufen Sie nur die in der aktuellen Prozedur enthaltenen Zeilen. Unterroutinen werden nicht berücksichtigt.
Wenn Sie sich einmal in einer Unterroutine befinden und feststellen, dass es hier keine relevanten Informationen zu holen gibt, können Sie mit Strg + Umschalt + F8 zum Ende der Routine springen. Sie landen dann in der aufrufenden Routine, und zwar in der ersten Zeile hinter dem Aufruf.
Fehlt nur noch eine Taste, die den Ablauf ohne weitere Zwischenschritte fortsetzt. Mit dieser können Sie auch komplette Routinen vom Start weg einfach aufrufen. Es handelt sich um die Taste F5.
Haltepunkte
Manchmal möchte man sich nicht mühsam per Einzelschritt bis zur interessanten Stelle im Code vorarbeiten, sondern direkt dorthin springen. Dafür gibt es Haltepunkte. Sie setzen einen Haltepunkt in eine Zeile, indem Sie die Einfügemarke in der Zeile positionieren und die Taste F9 beziehungsweise den Menübefehl Debuggen|Haltepunkte ein/aus verwenden.
Zum Entfernen aller Haltepunkte dienen der Menübefehl Debuggen|Alle Haltepunkte löschen oder die Tastenkombination Strg + Umschalt + F9.
Haltepunkte können Sie auch mit der Maus setzen. Dazu klicken Sie einfach auf der Höhe der betroffenen Zeile auf den links davon befindlichen grauen Balken.
Zurück nach oben
Manchmal möchte man sich im Code nicht vor-, sondern zurückbewegen – beispielsweise um einer Variablen testweise einen neuen Wert per Direktfenster zuzuweisen und eine Anweisung erneut zu testen, ohne direkt die ganze Prozedur neu zu starten.
Dazu ziehen Sie einfach den gelben Pfeil mit der Maus an die gewünschte Stelle (siehe Bild 2).
Bild 2: Per Drag and Drop des gelben Pfeils können Sie Zeilen wiederholt ausführen oder auch überspringen.
Alternativ positionieren Sie die Einfügemarke dort, wo VBA den Code fortsetzen soll, und betätigen die Tastenkombination Strg + F9.
Mit beiden Varianten können Sie übrigens nicht nur zurück, sondern auch vorwärts springen und so die Ausführung der dazwischen liegenden Zeilen unterbinden.
Debugging per Code
Wenn Sie sicherstellen möchten, dass ein bestimmter Codeteil durchlaufen wird, oder feststellen möchten, welchen Wert eine Variable zu einem bestimmten Zeitpunkt hat, können Sie einfach eine Zeile zum Code hinzufügen, welche die benötigte Information liefert.
Dies geschieht entweder durch den Einsatz der MsgBox– oder der Debug.Print-Anweisung. Eine weitere Alternative ist die Debug.Assert-Methode, die das Anhalten des Codes unter bestimmten Bedingungen erlaubt.
Ausgabe per MsgBox
Die Entscheidung, ob man zu Debugging-Zwecken die MsgBox– oder die Debug.Print-Anweisung einsetzt, hängt von den persönlichen Vorlieben, vom Umfang der benötigten Ausgaben und weiteren Faktoren ab.
Wenn Sie nur an ein oder zwei Stellen Informationen ausgeben möchten, ist ein Meldungsfenster sicher in Ordnung. Wenn Sie dieses jedoch in eine Schleife mit vielen Durchläufen einbauen, werden Sie schnell vom ständigen Wegklicken der Meldungen genervt sein. Hier ist die Arbeit mit der Debug.Print-Anweisung doch wesentlich entspannter: Sie brauchen die Routine einfach nur durchlaufen zu lassen und können sich die gesuchten Informationen dann bequem im Direktfenster ansehen (das man übrigens am schnellsten mit Strg + G einblendet, falls es nicht ohnehin schon sichtbar ist).
Debug.Print
Die Debug.Print-Anweisung zeigt den angegebenen Ausdruck im Direktfenster des VBA-Editors an. Die einfachste Variante ist, einen einzelnen Ausdruck auszugeben.
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
