.accdb läuft, .accde aber nicht

Fehlermeldung in einer frisch erstellten .accde-Datenbank

Bild 1: Fehlermeldung in einer frisch erstellten .accde-Datenbank

Haben Sie das schon einmal erlebt Sie haben Ihre Anwendung fertig programmiert und alles läuft einwandfrei. Sie müssen nur noch die Kompilierung in eine .accde-Datenbank vornehmen, damit der Kunde keinen Zugriff auf den Quellcode hat. Auch das gelingt ohne Probleme. Kaum starten Sie die .accde-Datenbank, geht jedoch plötzlich nichts mehr: Es funktionieren einfach keine Ereignisprozeduren mehr, und falls vorhanden, meckert auch das Ribbon, dass es seine Callback-Funktionen nicht mehr ausführen kann. Was ist hier geschehen und wie lösen wir das Problem Das zeigen wir in diesem Artikel.

Manchmal liefert Access Phänomene, die man sich einfach nicht erklären kann. In meiner neuesten Anwendung, die das Ribbon nutzt, erscheint zum Beispiel nach der Umwandlung in eine .accde-Datenbank die Meldung aus Bild 1.

Fehlermeldung in einer frisch erstellten .accde-Datenbank

Bild 1: Fehlermeldung in einer frisch erstellten .accde-Datenbank

Was genau passiert hier Das konnten wir nicht exakt herausfinden. Uns war an dieser Stelle wichtig, überhaupt eine Lösung zu finden.

Und die gab es: Offensichtlich entstehen diese Probleme mit .accde-Datenbanken, wenn sich in irgendeinem Klassenmodul eines Formulars oder Berichts noch eine leere Ereignisprozedur befindet, die beispielsweise wie folgt aussieht – also so, wie direkt nach der Erstellung:

Private Sub Form_Load()
End Sub

Leider ist es nicht so einfach, das Problem so nachzustellen – es tritt nämlich nicht immer so auf. Offensichtlich gibt es noch andere Faktoren, die das Problem „aktivieren“. Wir können daher keine Beispieldatenbank anbieten, die dieses Problem aufzeigt. Dennoch ist es für Sie vermutlich hilfreich, den Inhalt dieses Artikels im Hinterkopf zu behalten … wer weiß, ob und wann Sie einmal dieses Phänomen in einer Ihrer Datenbankanwendungen vorfinden.

Problemlösung

Die Lösung ist ganz einfach: Sie brauchen lediglich die leeren Ereignisprozeduren aus Ihrer Anwendung zu entfernen. Es reicht auch aus, wenn Sie eine beliebige Zeile in die Prozedur einfügen – und wenn es eine Kommentarzeile ist.

Das hört sich allerdings leichter an, als es ist, denn Sie müssen ja zunächst einmal herausfinden, ob sich überhaupt eine leere Ereignisprozedur in der Anwendung befindet und falls ja, wo diese liegt.

Dazu haben wir eine Prozedur programmiert, die alle Prozedurnamen samt Modul ausgibt, die weder Code noch Kommentare enthalten.

Damit die Prozedur funktioniert, benötigen wir einen Verweis auf die Bibliothek Microsoft Visual Basic for Applications Extensibility 5.3 Object Library (siehe Bild 2).


Nur für Abonnenten

Ab hier wird’s wirklich spannend – der Rest ist exklusiv für Abonnenten.

Mit dem Abo von Access im Unternehmen bekommst du den kompletten Artikel – inklusive vollständigem Code, Beispieldatenbank und Schritt-für-Schritt-Erklärung.

So sparst du dir stundenlanges Herumprobieren, vermeidest teure Fehler in deiner Access-Anwendung und kannst Lösungen direkt in deinem Unternehmen einsetzen, statt nur darüber zu lesen.

Teste Access im Unternehmen jetzt 4 Wochen lang kostenlos: Voller Zugriff auf alle Artikel, Downloads und Beispieldatenbanken. Kein Risiko – wenn es für dich nicht passt, kündigst du einfach innerhalb der ersten vier Wochen.

Bereits Abonnent? Hier einloggen


Kostenlos & unverbindlich

Oder hast Du eine konkrete Frage zu Deiner eigenen Access-Anwendung?

Vielleicht stellt Deine Anwendung Dich vor eine Herausforderung, zu der Du bisher keine Lösung findest. Schlechte Performance, kein ausreichender Zugriffsschutz, Du bist unsicher über Dein Datenmodell oder Dein Code liefert unerklärliche Fehler?

In unserem kostenlosen Access-Audit schaut sich André Minhorst persönlich gemeinsam mit Dir Deine Lösung per Zoom an – und zeigt Dir, wo Datenmodell, VBA-Code, Ergonomie und Sicherheit Optimierungspotenzial bieten.

Jetzt kostenloses Access-Audit anfordern →

Schreibe einen Kommentar