File Geodatabase API .NET Wrapper: How to determine if Table/Feature Class Is Locked?

Question

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?

Answer 1

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.

Answer 2

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.