seit Januar erhalte ich die Meldung: Sie haben momentan keinen exklusiven Zugriff auf die Datenbank.....
Die Meldung erscheint bei dem Versuch, VBA-Code zu speichern.
- Microsoft Office 365
- Ich bin der einzige User, es ist keine weitere ACCESS-Instanz offen.
- die Meldung erscheint bei mehreren Datenbanken, auch bei solchen, deren VBA-Code seit Jahreswechsel nicht mehr geändert wurde
- in Excel-Modulen kann ich problemlos arbeiten
Bisherige "Schrotschuss"-Maßnahmen:
- neue leere Datenbank erstellt, Inhalte importiert. Hilft 5 Minuten
- LAN ausgeschaltet, Neustart ohne LAN: Hilft nix
Wo muss ich suchen?
12.1.
Es wird immer merkwürdiger: heute früh habe ich die Datenbank wieder neu angelegt, sämtliche Inhalte aus der alten importiert. Name der bisherigen Datenbanken war Set- oder SetzProd...accdb. Die neue heißt Datab01.accdb, und ich konnte bis jetzt 1h lang VBA speichern, alles funktioniert. Hab ich den Parser (oder ein übergeordnetes ACCESS-Tool) mit der Namensgebung verwirrt?
13.1.
gerade die Datenbank kopiert und als neue Version gespeichert, neue Version geöffnet: der Fehler tritt wieder auf
Hallo,
sind die Sicherheitseinstellung im Trust-Center korrekt angepasst?
Haben die User alle Windows-Zugriffsrechte Rechte für die Verzeichnisse, in denen die DB-Dateien gespeichert sind?
Sind alle aktuellen Windows- und Office-Updates installiert?
Evtl. Office deinstallieren und neu installieren.
Weitere Tipps:
Als Admin ausführen:
chkdsk /f /r (auf allen internen Laufwerken)
sfc /Scannow
DISM.exe /Online /Cleanup-image /Restorehealth
Danke für die Hilfe. Es ist wohl ein Berechtigungsproblem. Ich werde mich erst mal mit meinem Konto beschäftigen.
jetzt habe ich den lokalen Super-Administrator (Windows powershell(Administrator)) mit dem Befehl: net user administrator /active:yes aktiviert, mich als solcher eingeloggt und bekomme dieselbe Fehlermeldung. Was mach ich jetzt?
Hallo,
allein sich zum Admin zu machen, hat keine Änderungen an den Einstellungen, bzw. Zustand bezgl. der genannten Fragepunkte zu tun.
Die sagst nicht, ob Du die überprüft hast.
jetzt hab ich die Hausaufgaben gemacht. sfc /Scannow und DISM.exe /Online /Cleanup-image /Restorehealth liefen ohne Fehlermeldung. Bei chkdsk hieß es für Lf C:
<CHKDSK kann nicht ausgeführt werden, weil das Volume von einem anderen Prozess verwendet wird. Soll dieses Volume überprüft werden, wenn das System das nächste Mal gestartet wird? (J/N) j>
Hab ich gemacht, keine besonderen Meldungen vor dem folgenden Bootvorgang. Frage: Muss ich jetzt diesen anderen Prozess (von den vielen, die man im Task-Manager sieht) finden, oder ist der normal. Muss ich evt. doch Office neu installieren?
Hallo,
der "andere Prozess" ist Windows (hat Dateien geöffnet) selber. Es ist normal, wenn für die Untersuchung des OS/Boot-Laufwerks neu gestartet werden muss.
Es fehlt aber immer noch die Untersuchung der Windows-Benutzerrechte für die betroffenen Verzeichnisse...
Und die Prüfung auf aktuelle Windows-/Office-Updates.
Ansonsten kann ich hier per Ferndiagnose nicht viel mehr sagen.
Office neu installieren (evtl. nur reparieren) kannst Du ja trotzdem versuchen.
PS:
In den Access-Optionen/Clienteinstellungen/Erweitert sind der Öffnungs- und Sperr-Modus einstellbar.
Vielleicht liegt das Problem ja dort.
Danke für die Hinweise.
Windows-Benutzerrechte: Administratoren und Benutzer für das gesamte Lf C (Boot und Programm-Lf), und auch die anderen Lf´s
Windows-Update: automatisch
Client-Einstellungen:
Standardöffnungsmodus: freigegeben
Standard bei Datensatzsperrung: keine Sperrung
Datenbanken mit Sperrung auf Datensatzebene öffnen: true
Trust-Center
vertrauenswürd. Speicherorte: <C:\Program Files\Microsoft Office\Root\Office16\ACCWIZ\>
Hallo,
Vertrauenswürdige Sp.-orte: Das reicht nicht! Füge "c:\" mit Unterordnern hinzu, wenn die DB irgendwo auf Laufwerk C: laufen soll
oder mindestens das Verzeichnis (mit Unterordnern), in der die DB(-Dateien) gespeichert sind.
Auch prüfen:
ActiveX-Einstellungen (alle aktivieren)
Makroeinstellungen (alle aktivieren)
hab alles gemacht, und auch Office neu installiert
Das ging dann 30min gut. Nachdem ich ein Formular aus einer anderen Datenbank importiert hatte, kam der Fehler wieder. Wenn der Fehler mal da ist, erscheint er auch bei dem Versuch, in anderen Funktionen in anderen Datenbanken die Programierung zu ändern.
Wie krieg ich denn raus, welche andere Instanz auf die aktuelle Datenbank sonst noch zugreift, wenn ich alleine bin?
Hallo,
ich nehme an, dass Du Dich selber sperrst.
Wenn sicher ist, dass wirklich kein anderer User im Netzwerk gerade auf die Datei zugreift (Ist die denn in FE und BE aufgeteilt und hat jeder User sein eigenes lokales FE?)
dann sind evtl. Netzwerkaussetzer die Ursache.
Ich bin der einzige User, es gibt 2 BE-Datenbanken, die sich in einem Unterordner der FE-Datenbank befinden.
Die Fehler treten beim Programmieren des FE auf
Also Antwort 11 ist missverständlich, nochmal neu und ausführlich:
- ich bin der einzige User
- Es gibt eine FE-Datenbank, in der sich die Formulare, Module und ganz wenige Hilfstabellen, z.B. für Start, befinden
- Es gibt 2 BE-Datenbanken, nur mit Tabellen.
- Die FE-Datenbank ist in einem Ordner, die BE-Db´s sind in einem Unterordner dieses Ordners, alle auf dem PC
- diese Ordner-Struktur gibt´s 2x, einmal für Entwicklung, einmal produktiv
- Es gibt eine weitere Transfer-Db, die die Entwicklungs-FE-Db in die Produktivumgebung transferiert (Kopieren, Umbenennen, Löschen der eingebundenen Tabellen, Löschen der alten Produktivversion).
- Beim Programmieren der Module dieser Transfer-Db, und beim Import eines Formulars tritt der Fehler auf, nicht beim Anwenden der Db´s. Auch nicht sofort, und mit welcher Aktion er ausgelöst wird, hab ich noch nicht rausgefunden
- Wenn der Fehler mal aufgetreten ist, tritt er auch bei der FE-Datenbank auf
Hallo,
ZitatEs gibt eine weitere Transfer-Db, die die Entwicklungs-FE-Db in die Produktivumgebung transferiert (Kopieren, Umbenennen, Löschen der eingebundenen Tabellen, Löschen der alten Produktivversion).
Da werde ich sofort hellhörig und würde mich gleich darauf stürzen.
Wird überall die selbe Access-Version benutzt?
Ist die Produktions-DB fehlerfrei (Komprimier/repariert, VBA-Debuggt und kompiliert)?
Ist die Transfer-DB fehlerfrei? (Komprimier/repariert und kompiliert)
Ist sichergestellt, das beim "Transfer" sowohl die Entwicklungs-DB als auch die Produktions-DB geschlossen sind?
Es ist auch nichts über die Sachlage gesagt, ob jeder User der Produktions-DB sein eigenes lokales FE besitzt.