File. Geodatabase API .NET Wrapper: Wie kann festgestellt werden, ob die Tabelle / Feature-Class gesperrt ist?

Ich habe den .NET-Wrapper der Datei gdb API verwendet und er hat meine Anforderungen sehr gut erfüllt (im Vergleich zur Verwendung von ArcObjects). Eines der Dinge, die ich noch nicht herausgefunden habe, ist, ob es einen geeigneten Weg gibt, um festzustellen, ob eine Tabelle oder Feature-Class (fc) gesperrt ist, bevor ich versuche, darauf zu schreiben.

Was ich getan habe, ist das Umschließen eines Updates / Einfügens in einen Versuch / Fang, und wenn ich zu "Sperrausnahme kann nicht erfasst werden ..." komme, weiß ich, dass das Objekt durch etwas anderes gesperrt ist.

Fehlt mir eine bessere Methode, um festzustellen, ob in eine bestimmte Tabelle oder einen bestimmten fc geschrieben werden kann?

Ich glaube nicht, dass es dafür explizit einen Hook in der Datei-Geodatabase-API gibt. Sie können jedoch eine Problemumgehung verwenden, indem Sie das Dateisystem wie oben erwähnt auf das Vorhandensein einer "..sr.lock" -Datei überprüfen.

Datei-Geodatabases werden wie Ordner im Dateisystem gelesen, und es gibt eine dieser Dateien für jeden Benutzercomputer, der eine aktive (oder nicht abgeschlossene ...) Verbindung zur Datei-Geodatabase (eine in der Tabelle _gdb) und / oder einer beliebigen Funktion hat Klassen, mit denen sie derzeit verbunden sind.

Es ist schneller als darauf zu warten, dass ein Fehler von einem Zugriffsfehler zurückkehrt. Die obige Antwort von MattB mit dem Sperr-Dashboard ist eine großartige Idee für mehrere Benutzer.

Ich verwende ArcObjects und habe die von Ihnen erwähnte try / catch-Methode verwendet.

In meinem Fall muss mehr als ein Benutzer Daten in derselben Feature-Class in einer Geodatabase lesen und schreiben. Ich habe einen "Ladebildschirm", der den Benutzer darüber informiert, dass die Daten verwendet werden, und dann versucht eine Schleife alle paar Sekunden im Hintergrund, bis eine Sperre für sie erstellt werden kann.

Die andere Art, wie ich Schlösser verwendet habe, wird unten beschrieben. Ich weiß, dass meine Verwendung dieser Methode zum Betrachten von Sperrdateien sich von dem unterscheidet, was Sie tun möchten, aber das Konzept ist dasselbe und Sie können möglicherweise etwas Ähnliches verwenden, wenn Sie den Typ der Sperre bestimmen müssen oder wem die Sperre gehört . Hier ist die Info, wenn Sie interessiert sind.

Da Sie die spezifischen Sperrdateien sehen können, wem sie gehören, welche Art von Sperre sie sind usw. Wenn Sie in die Geodatabase im Windows Explorer schauen, erstellen Sie eine eigenständige "Status" -Anwendung, die die Sperrdateien der spezifischen Sperrdateien überwacht Feature-Class, die wir alle verwenden.

Mit dieser Methode kann ich in Echtzeit anhand eines einfach zu lesenden Dashboards sehen, wer diese Feature-Class gesperrt hat (basierend auf dem Computernamen) und welche Art von Sperre sie haben. Wenn beispielsweise eine "sr" -Sperre (Schema) angezeigt wird, von der ich weiß, dass sie die Feature-Class zu ihrem Inhaltsverzeichnis hinzugefügt haben, bedeutet eine "rd" -Sperre, dass sie aus der Feature-Class lesen. Eine "wr" -Sperre bedeutet, dass sie schreiben Daten und eine "ed" -Sperre bedeuten, dass für die Feature-Class eine Bearbeitungssitzung geöffnet ist.

Dies ist sehr hilfreich bei der Durchführung von Wartungsarbeiten, um einen Blick nach unten zu werfen und sicherzustellen, dass sich dies nicht negativ auf jemanden auswirkt. Der Eintrag "Unbekannt" warnt mich auch, wenn jemand Unerwartetes die Feature-Class verwendet und ich weitere Untersuchungen durchführen kann.

Hier ist ein Screenshot des von mir verwendeten Dashboards.