Schemasperre

HinweisHinweis:

In den meisten Fällen kann ArcGIS gemeinsame Sperren und exklusive Sperren auf Datasets in der Geodatabase automatisch anwenden und aufheben, um bei der Verwaltung Ihrer Änderungen Konflikte mit anderen Benutzern zu vermeiden. Die einzige Ausnahme dieser Regel ist, wenn eine Geodatabase in ArcCatalog deaktiviert wird. Der Ordner mit der Geodatabase muss manuell aktualisiert werden, um die Sperre für die Geodatabase aufzuheben. In diesem Abschnitt wird die Funktionsweise dieser Schemasperren beschrieben.

In ArcSDE-Geodatabases können mehrere Benutzer gleichzeitig dieselben Daten lesen und bearbeiten. Damit Sie in einer Anwendung wie ArcMap mit Daten aus einer Geodatabase arbeiten können, muss die Anwendung davon ausgehen, dass dasSchema der Geodatabase auf keinen Fall geändert wird, während Sie mit den Inhalten der Geodatabase arbeiten. Beispiel: Wenn Sie eine Feature-Class aus einer Geodatabase Ihrer Karte hinzufügen, kann deren Schema nicht von Ihnen oder einem anderen Benutzer verändert werden. Sobald Sie die Feature-Class aus Ihrer Karte entfernt haben und keine anderen Benutzer diese Feature-Class abfragen oder bearbeiten, kann deren Schema verändert werden.

Überblick über Schemasperren

Geodatabases und die darin enthaltenen Datasets sind nur selten statisch. Die meisten Datasets werden im Laufe der Zeit bearbeitet und aktualisiert. Aus verschiedensten Gründen werden immer wieder neue Datasets hinzugefügt und vorhandene Datasets entfernt. Außerdem werden für vorhandene Datasets häufig Änderungen des Schemas vorgenommen, um zum Beispiel eine Attributtabelle hinzuzufügen, die Regeln einer Topologie zu ändern, kartografische Darstellungen hinzuzufügen usw.

Wenn Sie mit einer Einzelbenutzer-Geodatabase arbeiten, stellen diese Änderungen kein Problem dar, und Sie müssen sich keine Sorgen darüber machen, wie sich Ihre Änderungen auf andere Benutzer auswirken könnten. Wenn allerdings auch andere Benutzer mit der Geodatabase arbeiten, an der Sie die Änderungen vornehmen möchten, müssen Sie für Schema-Änderungen einige Workflows einrichten. Um beispielsweise Änderungen vorzunehmen, ohne andere Benutzer zu beeinträchtigen, könnten Sie die Bearbeitung des Schemas für einen Zeitpunkt planen, an dem keiner der anderen Benutzer am System angemeldet ist.

In ArcGIS stehen Ihnen einige automatisierte Mechanismen zur Schemasperre zur Verfügung, die Sie bei der Verwaltung von Geodatabase-Änderungen unterstützen. Berücksichtigen Sie diese Funktionen also beim Planen Ihrer Arbeit.

Gemeinsame Sperren

ArcGIS setzt automatisch eine gemeinsame Sperre auf einen einzelnen Dataset, wenn dieser verwendet wird, zum Beispiel immer dann, wenn ein Benutzer die Inhalte einer Feature-Class oder einer Tabelle bearbeitet oder abfragt. Dadurch wird verhindert, dass andere Benutzer Änderungen am zugrunde liegenden Dataset oder dessen Schema vornehmen können, während es in Verwendung ist.

Jederzeit können beliebig viele gemeinsame Sperren auf eine einzelne Feature-Class oder Tabelle gesetzt werden. Wenn Sie das Geodatabase-Schema mit ArcGIS ändern, um z. B. ein Feld hinzuzufügen oder Regeln zu ändern, versucht ArcGIS, eine exklusive Sperre für die geänderten Daten zu setzen. Ist für diesen Dataset jedoch eine gemeinsame Sperre vorhanden, kann keine exklusive Sperre gesetzt werden.

Exklusive Sperren

Eine exklusive Sperre dient dazu, einen Dataset der Geodatabase für die Verwendung durch andere Benutzer zu sperren, damit erforderliche Änderungen vorgenommen werden können, zum Beispiel Änderungen am Schema des Datasets. Sobald ein Benutzer mit entsprechenden Berechtigungen damit beginnt, Änderungen an einem Dataset in der Geodatabase vorzunehmen, setzt ArcGIS automatisch eine exklusive Sperre auf die individuelle Attributtabelle, Feature-Class-Tabelle, Raster-Tabelle oder den Dataset.

Wenn ein Benutzer ein Geodatabase-Schema ändern möchte, dürfen die zu ändernden Datasets nicht gleichzeitig von anderen Benutzern verwendet werden. Anders ausgedrückt darf für einen Dataset, den Sie ändern möchten, keine gemeinsame Sperre vorhanden sin.

Verwenden von Sperren in Personal-Geodatabases

In Personal-Geodatabases gelten alle Sperren für sämtliche Inhalte der gesamten Geodatabase. Wenn eine exklusive Sperre oder eine gemeinsame Sperre für ein Element in einer Personal-Geodatabase angefordert wurde, gilt diese Sperre für die Geodatabase insgesamt. Das bedeutet, dass immer nur ein einziger Benutzer gleichzeitig eine Personal-Geodatabase bearbeiten kann.

Jeder Benutzer mit dem entsprechenden Lese-/Schreibzugriff auf die Microsoft Access-Datenbankdatei (MDB), in der die Personal-Geodatabase gespeichert ist, kann die Schema-Inhalte bearbeiten und ändern.

Wenn Sie auf eine Personal-Geodatabase zugreifen, die auf einem Netzlaufwerk gespeichert ist, oder Sie über einen UNC-Pfad darauf zugreifen, sollten Sie sicherstellen, dass alle Benutzer mindestens Schreibzugriff auf den Ordner mit der Personal-Geodatabase haben. Wenn kein Benutzer Schreibzugriff hat, kann nur ein Benutzer die Personal-Geodatabase öffnen. Alle folgenden Versuche, die Personal-Geodatabase zu öffnen, führen zu einem Schemasperrenfehler, da die Microsoft Jet Engine-Datenbank die LDB-Datei nicht öffnen oder modifizieren kann. Diese wird zur Kontrolle des Zugriffs auf die MDB-Datei benötigt.

Verwenden von Sperren in File-Geodatabases

Benutzer benötigen Lese-/Schreibzugriff auf den Ordner der File-Geodatabase, um Änderungen am Schema vornehmen zu können.

In File-Geodatabases gelten alle Schemasperren, sowohl gemeinsame als auch exklusive Sperren, für individuelle Datasets und die in Beziehung stehenden Tabellen. Beispiel:

Verwenden von Sperren in ArcSDE-Geodatabases

Benutzer benötigen die entsprechenden Berechtigungen für die ArcSDE-Geodatabase, um Änderungen am Schema vornehmen zu können. Informationen zum Einrichten und Verwalten von Berechtigungen in ArcSDE finden Sie unter Benutzerberechtigungen.

In ArcSDE-Geodatabases gelten alle Schemasperren, sowohl gemeinsame als auch exklusive Sperren, für individuelle Datasets und die in Beziehung stehenden Tabellen. Beispiel:


3/6/2012