I have problems to release my gdb in ArcGIS10. My tool works with an local gdb, but I failed to release it after the process. In Ag9.3 I can release it simply by Marshal.ReleaseComObject(workspace), but this doesn't work in AG10. Also releasing all FeatureCursors doesn't help. Only closing the whole application "deletes" the lock. Does anyone know how to release my gdb and "delete" the lock without closing the application?
-
Search this site for "file geodatabase lock", some of those might help.– Chad CooperCommented Oct 24, 2011 at 11:47
-
Of course I searched the site before. But unfortunenatly none of the suggestions helped me out. I tried the Compact-GP, but this didn't unlock the gdb. It also doesn't seemed to be an orphaned lock, cause I cannot edit the gdb in ArcCatalog before I close my Application. But which object do I have to release for unlocking my gdb in addition to releasing the workspace?– AnnemieKCommented Oct 24, 2011 at 12:41
-
gis.stackexchange.com/search?q=file+geodatabase+lock– Mapperz ♦Commented Oct 24, 2011 at 14:13
-
1From gis.stackexchange.com/questions/6230/…, it appears you may have run into a bug. If none of the answers below apply, I'd follow up with Esri tech support.– matt wilkieCommented Nov 2, 2011 at 16:04
4 Answers
I had a quick look and found information on the locking scenario you seem to be having. In ArcObjects 10 there is a SetWriteLock and FreeWriteLock option.
have a look at the forum link specifically the sample from Lance Shipman from Esri http://forums.arcgis.com/threads/36881-the-performance-fgdb-api-amp-arcobjects
Have Fun, CDB
-
SetWriteLock and FreeWriteLock are not in ArcObjects but in the FileGeodatabase API (Separate of arcobjects). This library can write/release locks but only the ones that were created with this library. The filename pattern is different (does not include computer name, etc.). Commented Aug 18, 2015 at 15:46
Getting to this condition is easy - all you need is one object that is holding a reference to something that needs the workspace to stay alive. Like a custom object that holds a Feature for example.
Once you are sure you hold no such references, try calling GC.collect() to force the garbage collector into a quasi-deterministic cleanup mode
If you are using cursors in your application make sure to use the ComReleaser to manage the lifetime of the cursors and destroy them when you are done with them. Otherwise they can lock your DBMS. I might be wrong but I don't thing calling ReleaseComObject on the workspace alone removes the reference to the cursors. Take a look at this ESRI blog post...
Found Idea from http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//003n0000007w000000
“These .lock files are removed whenever you run the geoprocessing Compact tool”
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++;
}
}