In Workgroup oder Enterprise-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 oder die Karte geschlossen 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.
Freigegebene Schemasperren
ArcGIS setzt automatisch eine freigegebene Sperre auf ein einzelnes Dataset, wenn dieses 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 freigegebene 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 dieses Dataset jedoch eine freigegebene Sperre vorhanden, kann keine exklusive Sperre gesetzt werden.
Exklusive Schemasperren
Eine exklusive Sperre dient dazu, ein 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 das 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 ein Dataset, das Sie ändern möchten, keine freigegebene Sperre vorhanden sein.
Sperren in Personal-Geodatabases
In Personal-Geodatabases gelten alle Sperren für sämtliche Inhalte der gesamten Geodatabase. Wenn eine exklusive Sperre oder eine freigegebene 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.
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 freigegebene als auch exklusive Sperren, für individuelle Datasets und die in Beziehung stehenden Tabellen. Beispiel:
- Wenn Sie eine Sperre auf eine Feature-Class innerhalb eines Feature-Datasets anfordern, gilt diese Sperre für das gesamte Feature-Dataset und alle seine Inhalte.
- Sperren gelten außerdem für beide Seiten einer Beziehungsklasse. Wenn zum Beispiel zwei Standalone-Feature-Classes über eine Beziehungsklasse miteinander in Beziehung stehen und Sie eine exklusive oder eine freigegebene Sperre auf eine dieser Feature-Classes anfordern, gilt die Sperre auch für die jeweils andere Feature-Class.
Sperren in Workgroup- oder Enterprise-Geodatabases
Benutzer müssen ein Dataset besitzen, um Änderungen am Schema vorzunehmen, und über die entsprechenden Rechte verfügen, um die Daten anderer Benutzer zu ändern.
Alle Schemasperren, sowohl gemeinsame als auch exklusive Sperren, gelten für individuelle Datasets und die in Beziehung stehenden Tabellen. Beispiel:
- Wenn Sie eine Sperre auf eine Feature-Class innerhalb eines Feature-Datasets anfordern, gilt diese Sperre für das gesamte Feature-Dataset und alle seine Inhalte.
- Sperren gelten außerdem für beide Seiten einer Beziehungsklasse. Wenn zum Beispiel zwei Standalone-Feature-Classes über eine Beziehungsklasse miteinander in Beziehung stehen und Sie eine exklusive oder eine freigegebene Sperre auf eine dieser Feature-Classes anfordern, gilt die Sperre auch für die jeweils andere Feature-Class.