Zum Speichern von Entwurfsänderungen an Access-Objekten ist eine exklusive Sperre erforderlich.

Ursprüngliche KB-Nummer: 283228

Hinweis

Erweitert: Erfordert Expertenkenntnisse für Codierung, Interoperabilität und Mehrbenutzerfähigkeiten. Dieser Artikel bezieht sich nur auf eine Microsoft Access-Datenbank (.mdb und ACCDB).

Symptome

Wenn Sie versuchen, Symbolleisten anzupassen oder ein Microsoft Access-Formular, einen Bericht, ein Makro oder ein Modul in der Entwurfsansicht zu öffnen, erhalten Sie die folgende Meldung:

Sie haben derzeit keinen exklusiven Zugriff auf die Datenbank. Wenn Sie mit dem Vornehmen von Änderungen fortfahren, können Sie diese später möglicherweise nicht mehr speichern.

Wenn Sie versuchen, Entwurfsänderungen zu speichern, die Sie an einem Access-Formular, -Bericht, -Makro oder -Modul vorgenommen haben, erhalten Sie die folgende Meldung:

Sie haben derzeit keinen exklusiven Zugriff auf die Datenbank. Ihre Designänderungen werden nicht gespeichert.

Wenn Sie versuchen, eine neue Datenzugriffsseite zu speichern, erhalten Sie die folgende Meldung:

Ein Link zu dieser Datenzugriffsseite konnte nicht erstellt werden, da die Datenbank nicht exklusiv gesperrt werden kann.

Ursache

  • Sie versuchen, ein Formular, einen Bericht, ein Makro, ein Modul oder eine Befehlsleiste in der Entwurfsansicht zu öffnen.
  • Sie versuchen, Entwurfsänderungen an einem dieser Objekttypen oder an einem neuen Seitenlink zu speichern, während andere Benutzer dieselbe Datenbank geöffnet haben.

Um Entwurfsänderungen an diesen Objekttypen zu speichern, muss Access eine exklusive Sperre für die Datenbank erhalten können.

Lösung

In Situationen, in denen mehrere Entwickler gleichzeitig eine Access-Anwendung entwerfen, müssen Sie die Quellcodeverwaltung mithilfe des Microsoft Visual SourceSafe-Add-Ins für Microsoft Access implementieren. Oder Sie müssen lokale Arbeitskopien der Datenbank an jeden Entwickler verteilen. Es folgt eine Erläuterung jeder dieser Optionen.

Implementieren der Quellcodeverwaltung

Mit dem Microsoft Access-Visual SourceSafe Add-In können Sie Ihre Access-Anwendung während der Entwicklung unter Quellcodeverwaltung setzen. Wenn Sie Ihre Anwendung unter Quellcodeverwaltung stellen, können Sie änderungen nachverfolgen und speichern, die im Laufe der Zeit an Ihrer Anwendung vorgenommen werden. Mithilfe von Microsoft Visual SourceSafe können Sie den Verlauf eines Objekts überprüfen und dann zu früheren Versionen eines Objekts rückgängig machen. Sie können Objekte in der Microsoft Access-Anwendung auschecken, sie ändern oder neue Objekte in ihrer lokalen Kopie erstellen und sie dann wieder in der Standard Datenbank unter Quellcodeverwaltung einchecken. Die Microsoft Access-Visual SourceSafe Add-In ist mit Microsoft Office XP Developer verfügbar. Um das Microsoft Access Visual SourceSafe-Add-In verwenden zu können, müssen Sie auch Microsoft Visual SourceSafe separat installieren, das auch mit Microsoft Office XP Developer verfügbar ist.

Verwenden einzelner Arbeitsdatenbanken

Eine weitere Möglichkeit, die Sie implementieren können, besteht darin, eine master Kopie der Datenbankanwendung an einem zentralen Ort zu speichern und dann einzelne Arbeitskopien der Datenbank auf jedem Entwicklercomputer zu verwenden. Jeder Entwickler würde einen einzelnen Teil der Anwendung in der lokalen Arbeitskopie der Datenbank entwickeln. Wenn die Entwickler eine Änderung an einem Objekt in der Datenbankanwendung vornehmen möchten, importieren sie das Objekt aus der master Datenbank in die lokale Arbeitsdatenbank. Anschließend nehmen die Entwickler die erforderlichen Änderungen am Objekt in der lokalen Arbeitsdatenbank vor und speichern das Objekt. Wenn die Entwickler bereit sind, die Änderungen an die master-Datenbank zu committen, exportieren sie das Objekt in die master Datenbank, wobei das ursprüngliche Objekt überschrieben wird.

Ein Nachteil dieses Ansatzes besteht darin, dass es keine Möglichkeit gibt, zu bestimmen, ob mehrere Entwickler gleichzeitig an demselben Objekt lokal arbeiten. Wenn der Entwickler das Objekt in die master-Datenbank exportiert, kann der Entwickler unwissentlich Änderungen überschreiben, die ein anderer Entwickler in die master Datenbank committet hat.

Weitere Informationen

Um Entwurfsänderungen an Access-spezifischen Objekten wie Formularen, Berichten, neuen Seitenverknüpfungen, Makros, Modulen und Befehlsleisten zu speichern, muss Access 2002 die Datenbank ausschließlich während des Speichervorgangs sperren können. Tabellen, Abfragen und Beziehungen fallen nicht unter diese Einschränkung, da es sich um Microsoft Jet-spezifische Objekte handelt. Microsoft verwendet diese Anforderung mit Access 2002 aus verschiedenen Gründen:

  • Es bietet Konsistenz mit anderen Visual Basic-Umgebungsclientanwendungen.
  • Die Abhängigkeit von der Jet-Datenbank-Engine wird beendet.
  • Es verbessert die Stabilität von Access-spezifischen Objekten.

Bietet Konsistenz mit anderen Visual Basic-Umgebungsclientanwendungen

Da Access 2002 die Visual Basic-Umgebung hostet, muss das von Microsoft Access verwendete Speichermodell mit anderen Anwendungen konsistent sein, die die Visual Basic-Umgebung hosten. Die Visual Basic-Umgebung ermöglicht nur das exklusive Bearbeiten und Speichern von Visual Basic-Projekten, die nicht der Quellcodeverwaltung unterliegen. Dies gilt für Visual Basic 6.0 und alle Office-Anwendungen, die die Visual Basic-Umgebung hosten.

Beendet die Abhängigkeit von der Jet-Datenbank-Engine

Access bietet die Möglichkeit, Microsoft Access-Projektdateien (.adp) und auch Microsoft Access-Datenbanken (.mdb) zu erstellen. Mithilfe eines Access-Projekts können Entwickler Microsoft SQL Server als weitere Datenbank-Engine für Microsoft Jet verwenden. In der Vergangenheit waren alle Access-spezifischen Objekte (Formulare, Berichte, Makros, Module und Befehlsleisten) zur Speicherung von der Jet-Datenbank-Engine abhängig. Diese Objekte wurden in Access-spezifischen Systemtabellen in der Microsoft Jet-Datenbank gespeichert. Da Es für Access möglich ist, Microsoft SQL Server als Alternative zu Microsoft Jet zu verwenden, musste Microsoft einen Speichermechanismus für Access-spezifische Objekte entwickeln, der nicht auf der Jet-Datenbank-Engine basiert.

Verbessert die Stabilität von Access-spezifischen Objekten.

Das Projektspeichermodell verbessert die Stabilität von Access-spezifischen Objekten und dem Visual Basic-Projekt. Visual Basic for Applications hat die Bearbeitung von Visual Basic-Projekten mit mehreren Benutzern ohne Quellcodeverwaltung nie zugelassen. Microsoft Access 95 und Microsoft Access 97 könnten diese Einschränkung umgehen, indem Projektänderungen, die in einer Umgebung mit mehreren Benutzern vorgenommen wurden, in Visual Basic for Applications ausgeblendet und später mit dem Projekt zusammengeführt werden. Dies hatte jedoch das Potenzial, die Stabilität des Visual Basic-Projekts zu beeinträchtigen. Daher erfordert Microsoft Access beim Entwerfen von Access-spezifischen Objekten eine exklusive Sperre, um sicherzustellen, dass das Projekt nur über einen Editor verfügt.

Bearbeiten von Access-Objekten in einer Umgebung mit mehreren Benutzern

Da Benutzer eine Datenbank entweder zur exklusiven oder zur gemeinsamen Nutzung öffnen können, hängt das von Access gezeigte Speicherverhalten davon ab, wie der Benutzer die Datenbank geöffnet hat und ob derzeit mehrere Benutzer darauf zugreifen.

Wenn ein Entwickler die Datenbank zur exklusiven Verwendung öffnet, kann der Entwickler den Entwurf jedes Access-spezifischen Objekts speichern, vorausgesetzt, der Entwickler kann die Datenbank für Lese-/Schreibzugriff öffnen und verfügt über die richtigen Berechtigungen zum Ändern des Entwurfs des Objekts.

Wenn ein Benutzer die Datenbank für die gemeinsame Verwendung öffnet, kann der Benutzer den Entwurf jedes Access-spezifischen Objekts speichern, vorausgesetzt, der Benutzer kann die Datenbank für Lese-/Schreibzugriff öffnen, verfügt über die richtigen Berechtigungen zum Ändern des Entwurfs des Objekts und Access kann eine exklusive Sperre für die Datenbank erhalten.

Sperren heraufstufen

Um sicherzustellen, dass die Verwendung der Datenbank exklusiv ist, verwendet Access die Verbindungssteuerungsfunktion der Jet-Datenbank-Engine, um die freigegebene Sperre des Benutzers auf exklusiv hochzustufen. Access versucht, eine freigegebene Sperre in eine exklusive Sperre hochzustufen, sobald der Benutzer ein Formular, einen Bericht, ein Makro oder eine Befehlsleiste in der Entwurfsansicht öffnet. Access versucht zu diesem Zeitpunkt, die Sperraufstufung zu verhindern, um zu verhindern, dass ein Benutzer mehrere Entwurfsänderungen vorgenommen hat, nur um später festzustellen, dass der Benutzer sie nicht speichern kann, da Access keine exklusive Sperre erhalten kann. Durch versuchen, die Sperrheraufstufung zu versuchen, sobald der Benutzer ein Objekt in der Entwurfsansicht öffnet, kann Access den Benutzer warnen, wenn er keine exklusive Sperre erhalten kann, bevor der Benutzer Entwurfsänderungen vornimmt. Access versucht nicht, beim Öffnen eines Moduls in der Entwurfsansicht die Sperraufstufung zu versuchen. Es wird jedoch versucht, die Sperr-Heraufstufung zu versuchen, sobald der Benutzer ein Modul in der Datenbank bearbeitet.

Access behält die exklusive Sperre bei, bis der Benutzer alle modifiziert Objekte speichert oder verwirft und keine anderen Objekte in der Entwurfsansicht geöffnet sind. Anschließend wird die Sperre von Access auf freigegeben zurückstufen, wenn die Datenbank ursprünglich für die gemeinsame Verwendung geöffnet wurde.

Wenn Access die Sperre nicht auf exklusiv heraufstufen kann, wenn der Benutzer ein Objekt in der Entwurfsansicht öffnet, benachrichtigt Access den Benutzer mit der folgenden Meldung:

Sie haben derzeit keinen exklusiven Zugriff auf die Datenbank. Wenn Sie mit dem Vornehmen von Änderungen fortfahren, können Sie diese später möglicherweise nicht mehr speichern.

Nach dieser Warnmeldung öffnet Access das Objekt in der Entwurfsansicht und ermöglicht es dem Benutzer, Entwurfsänderungen vorzunehmen. Wenn der Benutzer versucht, das Objekt zu speichern, versucht Access, die freigegebene Sperre auf exklusiv heraufzustufen. Wenn die Sperraufstufung erfolgreich ist, speichert Access das Objekt und behält die exklusive Sperre bei, bis der Benutzer alle anderen modifiziert Objekte speichert oder verwirft und kein Objekt in der Entwurfsansicht geöffnet bleibt. Wenn die Sperraufstufung fehlschlägt, erhält der Benutzer die folgende Meldung:

Sie haben derzeit keinen exklusiven Zugriff auf die Datenbank. Ihre Designänderungen werden nicht gespeichert.

Wenn der Benutzer versucht, das modifiziert -Objekt zu schließen und Änderungen zu speichern, fordert Access den Benutzer mit der Option auf, das Objekt zu schließen und daran vorgenommene Entwurfsänderungen zu verwerfen, oder mit der Option, es geöffnet und nicht gespeichert zu lassen.

Schritte zum Reproduzieren des Verhaltens

  1. Starten Sie zwei Instanzen von Microsoft Access auf demselben Computer.

  2. Öffnen Sie die Beispieldatenbank Northwind.mdb in beiden Instanzen.

  3. Öffnen Sie im ersten instance von Microsoft Access das Formular Kunden in der Entwurfsansicht.

    Sie erhalten die Folgende Meldung:

    Sie haben derzeit keinen exklusiven Zugriff auf die Datenbank. Wenn Sie mit dem Vornehmen von Änderungen fortfahren, können Sie diese später möglicherweise nicht mehr speichern.

  4. Klicken Sie auf OK , um die Meldung zu löschen.

    Das Formular wird in der Entwurfsansicht geöffnet.

  5. Fügen Sie dem Formular ein Textfeld-Steuerelement hinzu.

  6. Klicken Sie im Menü Datei auf Speichern .

    Sie erhalten die folgende Meldung:

    Sie haben derzeit keinen exklusiven Zugriff auf die Datenbank. Ihre Designänderungen werden nicht gespeichert.

  7. Klicken Sie auf OK , um die Meldung zu löschen.

  8. Schließen Sie die zweite instance von Access auf Ihrem Computer.

  9. Versuchen Sie im ersten instance von Access erneut, das Formular zu speichern.

    Das Formular wurde erfolgreich gespeichert.