I have an application written in Java which uses ArcObjects 9.3. The application accesses a file GeoDatabase. The application produces output in the GeoDatabase that will be accessed by ArcMap. The problem is that ArcMap can't access the file GeoDatabase because my application still has locks on it. The only workaround I have is to close my application, which removes all the locks. But there's got to be a better way than that. Does anyone have a solution for freeing up these locks?

FileGDBWorkspaceFactory fileGDBWF;
fileGDBWF = new FileGDBWorkspaceFactory();
ws = new Workspace(fileGDBWF.openFromFile(workspacePath, 0));
  • What method are you using to open the tables in the file geodatabase? Oct 5 '10 at 16:03
  • The code I used to open the geodatabase looks like this: FileGDBWorkspaceFactory fileGDBWF = new FileGDBWorkspaceFactory(); ws = new Workspace(fileGDBWF.openFromFile(workspacePath, 0));
    – Bill
    Oct 29 '10 at 14:03

I'd have to think that your application must still be accessing the FGDB somehow. I write to FGDBs programmatically (with .NET though) and don't have to do anything to specifically release my FGDB after I write to it. There really is no way to kill the lock files either. I actually talked to Craig Gillgrass with ESRI about killing lock files and they told me there is no way to do it. Now, that said, I have seen instances where orphaned lock files get left behind, and those usually can be deleted, since they are orphaned. Here's some .NET that I use to check for locks, maybe it will help:

// Before we do anything, run through the FGDB FCs and see if there are locks on any of them
            string gdb = String.Concat(c.fgdbDir, @"\", kvp.Key[0], ".gdb");
            gp.SetEnvironmentValue("workspace", gdb);
            IGpEnumList fcs = gp.ListFeatureClasses("*", "", "");
            string fc = fcs.Next();
            while (fc != "")
                IFeatureClass u = OpenFc(String.Concat(c.fgdbDir, @"\", kvp.Key[0], ".gdb"), fc);
                IDataset ds = (IDataset)u;
                // Get a schemalock on the dataset - this means there is always at least one lock on the FC
                ISchemaLock sl = (ISchemaLock)ds;
                IEnumSchemaLockInfo enumSLI;
                sl.GetCurrentSchemaLocks(out enumSLI);
                int slc = 0;
                ISchemaLockInfo sli = enumSLI.Next();
                while (sli != null)
                    sli = enumSLI.Next();
                // If schemalock count is >=2, then we have a problem, something else has a lock on the FC
                if (slc >= 2)
                    c.msg = "Schemalock count on FC '" + fc + "' in FGDB '" + kvp.Key[0] + "': " + slc.ToString();
                    Messaging.Log(c.msg, c.lw);
                    ISchemaLock sl2 = (ISchemaLock)ds;
                    IEnumSchemaLockInfo enumSLI2;
                    sl2.GetCurrentSchemaLocks(out enumSLI2);
                    ISchemaLockInfo sli2 = enumSLI2.Next();
                    while (sli2 != null)
                        c.msg = "  Schemalock info: " + sli2.TableName + " : " + sli2.UserName + " : " + sli2.SchemaLockType;
                        Messaging.Log(c.msg, c.lw);
                        sli2 = enumSLI2.Next();
                fc = fcs.Next();
                // Set schemalock object = null so lock we created goes away, otherwise, there will still be a lock on the FC
                //  and processing will bomb



Chad, can you elaborate on your code? How do you process the keys in the keyToDelete list that you have gathered. Also, how did you create kvp (keyValuePair I'm assuming). I've realized that the dbf file is not locked, but a stray .sr.lock file, which itself is locked is what is causing the problem.

  • I loop through the keys (which are names of the my file geodatabases) in keysToDelete and remove them from the list of FGDBs to process, as since they have locks on them, I can't do any processing on them. kvp is a dictionary that gets passed into the method. HTH. If the lock files are orphans, you should be able to delete them. It's just hard to know which ones are orphaned - sometimes the filesystem date on the lock file is a clue. Dec 30 '10 at 13:29

Thanks for you answers. I finally found a solution that worked for me. It involves a class in ArcObjects that I never heard of: Cleaner. It has one method called release which allows you to release the locks on a single ArcObject, which is what I needed to do. It also has some shotgun methods to release all the objects in a thread, or all the objects in the process, but it cautions against using those unless you know that the thread is terminating, or the JVM is shutting down, respectively.

I'm not sure why I needed to manually release the lock, but doing so fixed my problem.

Anyway, here's the link to the JavaDoc for this class:


12/30/2011: I found that maintaining a Java HashSet of my ArcObjects made it easy to release any locks that were left behind. There's no penalty for attempting to release a lock that's already been released.


Here is the page on Interface ISchemaLock in Java for arcgis 9.3, and the same with code examples for VB and C# (v9.2).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.