I have been using the file gdb API .NET wrapper, and it has suited my needs quite nicely (vs. using ArcObjects). One of the things I have yet to figure out is if there is a proper way to determine if a table or feature class (fc) is locked before attempting to write to it.

What I have been doing is wrapping a update/insert in a try/catch, and if I get to 'can't acquire lock exception...', I know the object is locked by something else.

Am I missing a better way to tell if a given table or fc can be written to?

  • I would also be interested in an answer to this question, not just for the File Geodatabase API, but ideally also for ArcObjects. – stakx Mar 28 '13 at 16:55
  • Since they are two completely different APIs I would suggest asking a separate question. I'm not sure whether the bounty could be moved over though. – blah238 Mar 28 '13 at 17:01
  • I agree with @blah238. The answer for ArcObjects is to use The ISchemaLockInfo & ISchemaLock to provide information about a schema lock; I think there is no answer for the Filegeodatbase API – Devdatta Tengshe Mar 28 '13 at 17:10
  • 2
    Locking isn't exposed through the file geodatabase API. You will have to attempt to either write, or get the write lock, and deal with the exception. – travis Apr 3 '13 at 18:28
  • 2
    Did you try Esri::FileGDB::Table::IsEditable ? – Kirk Kuykendall Apr 3 '13 at 20:16

I don't think there is a hook in the file geodatabase API for this explicitly. But you can use a workaround by checking the file system for the presence of a "..sr.lock" file as mentioned above.

File geodatabases are read like folders on the file system and there will be one of these files for each user machine that has an active (or unterminated...) connection to the file geodatabase (one on the _gdb table) and/or any feature classes that they are currently connected to.

Its quicker than waiting for an error to return from an access failure. MattB's answer above with the lock dashboard is a great idea for multiple users.


I use ArcObjects and have used the try/catch method you mentioned.

In my case more than one user needs to read and write data in the same feature class in a geodatabase. I have a "load screen" that comes up and lets the user know that the data is in use and then a loop keeps trying every few seconds in the background until a lock is able to be created for them.

The other way I've used locks is described below. I know my use of this method of looking at lock files differs from what you are wanting to do but the concept is the same and you may be able to use something similar if you need to determine the type of lock or who the lock belongs to. Here is the info if you're interested.

Since you can see the specific lock files, who they belong to, what type of lock they are etc. if you look inside the geodatabase in Windows Explorer is to create a stand-alone "status" application that monitors the lock files of the specific feature class we all use.

Using this method I'm able to see in real time from an easy to read dashboard who has that feature class locked (based on computer name) and what type of lock they have. For example if it sees an "sr" (schema) lock I know they have the feature class added to their Table of Contents, an "rd" lock means they are reading from the feature class, a "wr" lock means they are writing data and an "ed" lock means they have an edit session open on the feature class.

This is very helpful when performing maintenance to be able to glance down and make sure it's not going to have a negative effect on anyone. The "Unknown" entry also alerts me to when someone unexpected is using the feature class and I can investigate further.

Here is a screen shot of the dash board I use. FeatureClass Status Dashboard

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.