API de géodatabase fichier .NET Wrapper: comment déterminer si la table / classe d'entités est verrouillée?

J'utilise l'encapsuleur de fichier API gdb .NET, et il a très bien répondu à mes besoins (par rapport à l'utilisation d'ArcObjects). L'une des choses que je n'ai pas encore compris est de savoir s'il existe un moyen approprié de déterminer si une table ou une classe d'entités (fc) est verrouillée avant d'essayer d'y écrire.

Ce que j'ai fait, c'est encapsuler une mise à jour / insérer dans un try / catch, et si je parviens à «ne peut pas acquérir d'exception de verrouillage ...», je sais que l'objet est verrouillé par autre chose.

Suis-je manquant d'une meilleure façon de savoir si une table ou un fc donné peut être écrit?

Je ne pense pas qu'il y ait un crochet dans l'API de géodatabase fichier pour cela explicitement. Mais vous pouvez utiliser une solution de contournement en vérifiant le système de fichiers pour la présence d'un fichier "..sr.lock" comme mentionné ci-dessus.

Les géodatabases fichier sont lues comme des dossiers sur le système de fichiers et il y aura un de ces fichiers pour chaque machine utilisateur qui a une connexion active (ou non terminée ...) à la géodatabase fichier (une sur la table _gdb) et / ou toute fonctionnalité les classes auxquelles ils sont actuellement connectés.

C'est plus rapide que d'attendre le retour d'une erreur suite à un échec d'accès. La réponse de MattB ci-dessus avec le tableau de bord de verrouillage est une excellente idée pour plusieurs utilisateurs.

J'utilise ArcObjects et j'ai utilisé la méthode try / catch que vous avez mentionnée.

Dans mon cas, plusieurs utilisateurs doivent lire et écrire des données dans la même classe d'entités dans une géodatabase. J'ai un "écran de chargement" qui apparaît et permet à l'utilisateur de savoir que les données sont en cours d'utilisation, puis une boucle continue d'essayer toutes les quelques secondes en arrière-plan jusqu'à ce qu'un verrou puisse être créé pour eux.

L'autre façon dont j'ai utilisé les verrous est décrite ci-dessous. Je sais que mon utilisation de cette méthode pour regarder les fichiers de verrouillage diffère de ce que vous voulez faire, mais le concept est le même et vous pourrez peut-être utiliser quelque chose de similaire si vous devez déterminer le type de verrou ou à qui appartient le verrou . Voici l'info si vous êtes intéressé.

Comme vous pouvez voir les fichiers de verrouillage spécifiques, à qui ils appartiennent, à quel type de verrouillage ils sont, etc. si vous regardez à l'intérieur de la géodatabase dans l'Explorateur Windows, vous devez créer une application "d'état" autonome qui surveille les fichiers de verrouillage de la classe d'entités que nous utilisons tous.

En utilisant cette méthode, je peux voir en temps réel à partir d'un tableau de bord facile à lire qui a verrouillé cette classe d'entités (en fonction du nom de l'ordinateur) et quel type de verrou ils ont. Par exemple, s'il voit un verrou "sr" (schéma), je sais qu'ils ont la classe d'entités ajoutée à leur table des matières, un verrou "rd" signifie qu'ils lisent à partir de la classe d'entités, un verrou "wr" signifie qu'ils écrivent les données et un verrou "ed" signifient qu'ils ont une session d'édition ouverte sur la classe d'entités.

Cela est très utile lors de la maintenance pour pouvoir regarder vers le bas et s'assurer que cela n'aura aucun effet négatif sur personne. L'entrée "Inconnu" m'avertit également lorsqu'un utilisateur inattendu utilise la classe d'entités et je peux enquêter plus avant.

Voici une capture d'écran du tableau de bord que j'utilise.