Die Anwendung öffnet sich, aber ihr Code läuft nicht
Symptom
Eine ausgelieferte Anwendung öffnet sich auf dem PC eines Benutzers, aber von ihrem Code geschieht nichts: Das Startformular erscheint ohne seine Daten oder bleibt leer, Schaltflächen bewirken nichts, das Anwendungsmodell wird nicht angewendet, WKL-Steuerelemente bleiben leer. Oft erscheint gar keine Meldung; in anderen Fällen zeigt Access vor dem Öffnen der Datenbank den Microsoft Access-Sicherheitshinweis.
Umgebung
Microsoft 365 Access, Vollversion und Runtime, 32 und 64 Bit; ACCDE und ACCDB.
Ursache
Access führt den Code einer Datenbank nur aus, wenn es ihr vertraut. Darüber entscheiden die Makroeinstellung des Trust Centers (Datei › Optionen › Trust Center › Einstellungen für das Trust Center › Makroeinstellungen) und die vertrauenswürdigen Speicherorte; was der Benutzer sieht, hängt von beiden und von der Art der Datei ab. Für eine ACCDE und eine ACCDB, ohne und mit vertrauenswürdigem Speicherort:
| Makroeinstellung | Datei nicht an einem vertrauenswürdigen Speicherort | Datei an einem vertrauenswürdigen Speicherort |
|---|---|---|
| Alle Makros aktivieren | Code läuft | Code läuft |
| Alle Makros mit Benachrichtigung deaktivieren (Standardwert), ACCDE, Vollversion und Runtime | Sicherheitshinweis; nach Öffnen läuft der Code | Code läuft, kein Hinweis |
| Alle Makros mit Benachrichtigung deaktivieren, ACCDB, Vollversion | Kein Hinweis, nur die Meldungsleiste; der Code bleibt bis Inhalt aktivieren abgeschaltet | Code läuft |
| Alle Makros mit Benachrichtigung deaktivieren, ACCDB, Runtime | Sicherheitshinweis; nach Öffnen läuft der Code | Code läuft |
| Alle Makros außer digital signierten Makros deaktivieren | Kein Hinweis, der Code ist abgeschaltet; eine ACCDE wird gar nicht geöffnet | Code läuft |
| Alle Makros ohne Benachrichtigung deaktivieren | Kein Hinweis, der Code ist abgeschaltet; eine ACCDE wird gar nicht geöffnet | Code läuft |
| Alle Makros aktivieren oder Standardwert, Datei als aus dem Internet heruntergeladen gekennzeichnet | Hinweis „Microsoft hat die Ausführung von Makros blockiert“, der Code ist abgeschaltet – auch mit Alle Makros aktivieren | Code läuft |
„Gar nicht geöffnet“ bedeutet: Access zeigt sein leeres Fenster – Titel Access, das Menüband, kein
Navigationsbereich, keine Dokumentregisterkarten, kein Startformular. Die Starteigenschaften der Datei
(StartUpShowDBWindow, AllowBypassKey und die übrigen) spielen dann keine Rolle: Eine ausgelieferte Kopie für die
Produktion und eine für die Administration sehen gleich aus, und das Gedrückthalten der Umschalttaste beim Öffnen
ändert nichts. Ist der Code vertrauenswürdig, wirken die Starteigenschaften: Die Administrationskopie zeigt ihren
Navigationsbereich, die Produktionskopie behält ihr Startformular und blendet den Bereich aus, auch bei gedrückter
Umschalttaste (AllowBypassKey = False).
Ein vertrauenswürdiger Speicherort gilt nur für Dateien direkt in seinem Ordner, sofern nicht Unterordner dieses
Speicherorts sind ebenfalls vertrauenswürdig gesetzt ist: Ein Frontend in ...\Frontends\1.0\ ist durch einen
Speicherort ...\Frontends\ ohne diese Option nicht vertrauenswürdig. Ein vertrauenswürdiger Speicherort wirkt bei
jeder Makroeinstellung und hebt auch die Sperre einer aus dem Internet heruntergeladenen Datei auf.
Die ActiveX-Einstellung des Trust Centers (ActiveX-Einstellungen) wirkt unabhängig davon: Mit Alle Steuerelemente ohne Benachrichtigung deaktivieren bleiben die WKL-Steuerelemente auch an einem vertrauenswürdigen Speicherort leer – der Code läuft, und das Erstellen eines WKL-Steuerelements scheitert mit dem Access-Fehler 2926 (das Steuerelement ist durch die Sicherheitseinstellungen deaktiviert). Die übrigen ActiveX-Optionen hinderten die WKL-Steuerelemente an einem vertrauenswürdigen Speicherort nicht am Laden.
Ein Skript, das Access mit einer solchen Datei startet, wartet vergeblich: Access mit abgeschaltetem Code
beantwortete eine an sein Hauptfenster gesendete Schließen-Anforderung, indem es das Fenster schloss, aber der Prozess
bleibt bestehen. Das gilt für Access, das unsichtbar oder minimiert gestartet wurde. Prüfen Sie das Vertrauen mit
Test-AccessTrust.ps1, bevor ein Skript die Anwendung startet.
Lösung
- Ermitteln Sie den Grund, ohne Access zu starten: Führen Sie
tools\deploy\Test-AccessTrust.ps1 -Path <file>aus dem Release-Paket als der betroffene Benutzer aus. Exitcode und Ausgabe nennen genau einen Grund (siehe `WklTrustCode` in der API-Referenz (Englisch)); in VBA liefert `WklApplication.CheckTrust` (API-Referenz, Englisch) dieselbe Antwort. - Bei Code 10 (kein vertrauenswürdiger Speicherort erfasst die Datei): Legen Sie das Frontend mit
tools\deploy\Set-AccessTrustedLocation.ps1 -Path <folder>an einen vertrauenswürdigen Speicherort – mit-AllowSubfolders, wenn das Frontend in einem Unterordner dieses Ordners liegt, zum Beispiel in einem Ordner je Version. - Bei Code 30 (nur signierte Makros erlaubt): Legen Sie die Datei an einen vertrauenswürdigen Speicherort (Schritt 2); ein signiertes VBA-Projekt wertet die Prüfung nicht aus.
- Bei Code 41 (ActiveX-Einstellung des Benutzers): Wählen Sie in Access unter Datei › Optionen › Trust Center › Einstellungen für das Trust Center › ActiveX-Einstellungen eine beliebige Option außer Alle Steuerelemente ohne Benachrichtigung deaktivieren.
- Bei Code 50 (Datei aus dem Internet): Legen Sie die Datei an einen vertrauenswürdigen Speicherort (Schritt 2), oder entfernen Sie die Kennzeichnung im Explorer mit Eigenschaften › Zulassen oder in PowerShell mit
Unblock-File. - Bei einem Code einer Gruppenrichtlinie (11, 12, 13, 20, 40): Die IT ändert die Richtlinie oder legt den Speicherort per Richtlinie fest; der Benutzer kann sie nicht übergehen.
- Weisen Sie Benutzer nicht an, als übliche Arbeitsweise auf Inhalt aktivieren zu klicken: Das wirkt nur für dieses eine Öffnen, und beim nächsten Start oder bei einem anderen Benutzer greift dieselbe Sperre.