{"id":55001513,"date":"2024-10-01T00:00:00","date_gmt":"2024-08-27T08:47:18","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=1513"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Fehler_in_der_Runtime_von_Access_finden","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Fehler_in_der_Runtime_von_Access_finden\/","title":{"rendered":"Fehler in der Runtime von Access finden"},"content":{"rendered":"

\"\"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.<\/b><\/p>\n

Optimale Lösung: Die Anwendung ist vollständig mit einer Fehlerbehandlung ausgestattet.<\/h2>\n

Probleme wie das geschilderte sollten eigentlich gar nicht in dieser Form auftreten. „In dieser Form“ bedeutet, dass es durchaus einmal vorkommen kann, dass eine Anwendung unter der Runtime-Version von Access anders arbeitet als unter der Vollversion.<\/p>\n

Aber wenn dabei Probleme auftauchen, werden diese in der Regel durch Fehler im VBA-Code ausgelöst. Und wenn die Meldung aus Bild 1 erscheint, ist die Wahrscheinlichkeit hoch, dass es in der Runtime einen Fehler gibt, der durch eine VBA-Anweisung ausgelöst wurde.<\/p>\n

\"Typische<\/p>\n

Bild 1: Typische Fehlermeldung der Runtime<\/span><\/b><\/p>\n

Eine professionell programmierte Anwendung würde in jeder Prozedur eine Fehlerbehandlung enthalten, die beim Auftreten eines Fehlers dafür sorgt, dass diese nicht die eingebaute Access-Fehlermeldung auslöst. Genau diese wird nämlich durch die hier gezeigte Fehlermeldung der Runtime-Version kaschiert.<\/p>\n

Fehler im Griff mit umfassender Fehlerbehandlung<\/h2>\n

Wenn wir flächendeckend unsere eigene Fehlerbehandlung in den Routinen der Anwendung untergebracht hätten, wäre die eingebaute Fehlermeldung der Runtime gar nicht nötig. Eine solche Fehlerbehandlung ist relativ einfach zu realisieren, wenn man dies gleich von Beginn an berücksichtigt. Wenn man jedoch erst einmal eine umfangreiche Anwendung programmiert hat und anschließend die Fehlerbehandlung hinzufügen will, kommt eine Menge Arbeit auf einen zu.<\/p>\n

Fehlerbehandlung per MZ-Tools<\/h2>\n

Auch diese kann man weitgehend vereinfachen, indem man ein Werkzeug wie MZ-Tools <\/b>zum halbautomatischen Anlegen der Fehlerbehandlung nutzt. Mit MZ-Tools können wir sogar automatisch Zeilennummern hinzufügen, was in einem Runtime-Setting essenziell ist, denn sonst können wir kaum herausfinden, wo in einer längeren Prozedur genau der Fehler aufgetreten ist.<\/p>\n

Fehlerbehandlung per vbWatchDog<\/h2>\n

Die nächste Möglichkeit ist der vbWatchDog<\/b>, ein Add-In von Access-Spezialist Wayne Philips. Das ist ein Tool, mit dem man nur durch Hinzufügen einiger weniger Objekte und ein wenig Code die komplette Anwendung mit einer allgemeinen Fehlerbehandlung ausstattet, ohne den einzelnen Prozeduren auch nur eine einzige Zeile Code hinzuzufügen (es sei denn, es ist eine spezielle Fehlerbehandlung erwünscht).<\/p>\n

Problem bei der Runtime: Kein Debug.Print möglich<\/h2>\n

Wenn wir eine Anwendung in der Vollversion testen, um ein eventuell fehlerhaftes Verhalten zu prüfen, hilft uns oft die Debug.Print<\/b>-Anweisung weiter. Damit können wir praktisch vor oder nach jeder Zeile Informationen im Direktbereich des VBA-Editors ausgeben.<\/p>\n

Leider hilft uns auch das in einer unter der Runtime-Version von Access ausgeführten Anwendung nicht weiter, denn hier gibt es gar keinen VBA-Editor, mit dem wir uns die Ausgabe ansehen könnten.<\/p>\n

Herausfinden, wo ein Fehler stattfindet, ohne alles mit Fehlerbehandlungen auszustatten<\/h2>\n

Typischerweise funktionieren Dinge, die unter einer Access-Vollversion reibungslos laufen, gelegentlich in der Runtime-Version nicht. Wenn wir keine Fehlerbehandlung eingebaut haben und vielleicht auch gerade nicht die Ressourcen verfügbar sind, um das nachzuholen, müssen wir ein wenig kleinschrittiger an das Problem herangehen.<\/p>\n

Wir nehmen nun zusätzlich noch an, dass wir es mit einer Anwendung eines Kunden zu tun haben, die wir nicht so genau kennen wie unsere selbst programmierten Anwendungen.<\/p>\n

Dann sehen wir vielleicht vor dem Erscheinen der ominösen Fehlermeldung noch, welche Formulare angezeigt werden, aber welche Prozedur den Fehler ausgelöst hat, finden wir auf diese Weise auch nicht heraus.<\/p>\n

Wenn wir nicht alle Prozeduren mit einer Fehlerbehandlung versehen wollen, müssen wir einen anderen Weg gehen, um herauszufinden, welche Stelle im Code den Fehler auslöst. Dazu gehen wir wie folgt vor:<\/p>\n