Comment déverrouiller un gdb?

11

J'ai des problèmes pour libérer ma gdb dans ArcGIS10. Mon outil fonctionne avec une gdb locale, mais je n'ai pas pu le libérer après le processus. Dans Ag9.3, je peux le publier simplement par Marshal.ReleaseComObject (espace de travail), mais cela ne fonctionne pas dans AG10. La libération de tous les FeatureCursors n'aide pas non plus. Seule la fermeture de l'application entière "supprime" le verrou. Est-ce que quelqu'un sait comment libérer mon gdb et "supprimer" le verrou sans fermer l'application?

arcgis-10.0 arcobjects

— AnnemieK
source

Recherchez sur ce site le «verrouillage de la géodatabase fichier», certains d'entre eux pourraient vous aider.

— Chad Cooper

Bien sûr, j'ai déjà cherché sur le site. Mais malheureusement, aucune des suggestions ne m'a aidé. J'ai essayé le Compact-GP, mais cela n'a pas déverrouillé le gdb. Il ne semble pas non plus être un verrou orphelin, car je ne peux pas modifier la gdb dans ArcCatalog avant de fermer mon application. Mais quel objet dois-je libérer pour déverrouiller ma gdb en plus de libérer l'espace de travail?

— AnnemieK

gis.stackexchange.com/search?q=file+geodatabase+lock

— Mapperz

1

Depuis gis.stackexchange.com/questions/6230/… , il semble que vous ayez rencontré un bogue. Si aucune des réponses ci-dessous ne s'applique, je ferai un suivi auprès du support technique d'Esri.

— Matt Wilkie

2

J'ai jeté un coup d'œil rapide et j'ai trouvé des informations sur le scénario de verrouillage que vous semblez rencontrer. Dans ArcObjects 10, il existe une option SetWriteLock et FreeWriteLock.

jetez un oeil sur le lien du forum en particulier l'exemple de Lance Shipman d'Esri http://forums.arcgis.com/threads/36881-the-performance-fgdb-api-amp-arcobjects

Amusez-vous, CDB

— CDBrown
source

SetWriteLock et FreeWriteLock ne se trouvent pas dans ArcObjects mais dans l'API FileGeodatabase (séparé des arcobjects). Cette bibliothèque peut écrire / libérer des verrous mais uniquement ceux qui ont été créés avec cette bibliothèque. Le modèle de nom de fichier est différent (n'inclut pas le nom de l'ordinateur, etc.).

— mstaessen

2

Il est facile d'accéder à cette condition - tout ce dont vous avez besoin est d'un objet contenant une référence à quelque chose qui a besoin de l'espace de travail pour rester en vie. Comme un objet personnalisé qui contient une fonctionnalité par exemple.

Une fois que vous êtes sûr de ne pas détenir de telles références, essayez d'appeler GC.collect () pour forcer le garbage collector dans un mode de nettoyage quasi-déterministe

— Ragi Yaser Burhum
source

2

Si vous utilisez des curseurs dans votre application, assurez-vous d'utiliser ComReleaser pour gérer la durée de vie des curseurs et détruisez-les lorsque vous en avez fini avec eux. Sinon, ils peuvent verrouiller votre SGBD. Je peux me tromper, mais je ne pense pas que le fait d'appeler ReleaseComObject sur l'espace de travail seul supprime la référence aux curseurs. Jetez un œil à ce billet de blog ESRI ...

http://blogs.esri.com/Dev/blogs/geodatabase/archive/2008/12/18/Using-the-ComReleaser-to-manage-the-lifetime-of-cursors-in-.NET.aspx

— Jeff Berry
source

0

Idée trouvée sur http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//003n0000007w000000

«Ces fichiers .lock sont supprimés chaque fois que vous exécutez l'outil de géotraitement Compact»

string[] lockfiles = Directory.GetFiles(project.Path, "*.lock",   SearchOption.AllDirectories);

if(lockfiles.Length > 0)
{
int lockCt = 0;
while (lockCt < lockfiles.Length)
{
 string inFGDB = System.IO.Path.GetDirectoryName(lockfiles[lockCt]);

 ESRI.ArcGIS.DataManagementTools.Compact compactProcess = new   ESRI.ArcGIS.DataManagementTools.Compact();

 compactProcess.in_workspace = inFGDB;

 geoprocessor.Execute(compactProcess ,null);

  lockCt++;
}
}

— Ajay
source