Unexpected results editing file geodatabase feature class

[WayneGuidry]

My understanding is that a file geodatabase only allows one user to edit a featureclass at a time, however this is not what I'm experiencing.

If I log in as myself on one machine and open ArcMap, point to a shared file geodatabase on our server, add a feature class to the map, and then click "start editing"... so far so good.

From a second machine if a co-worker logs in and (from ArcMap) connects to the exact same feature class and attempts to open an edit session, it allows it to occur and we can both edit at the same time which doesn't seem right based on ESRI documentation (I didn't think it supported multi-user editing).

I noticed if I login to both machines and attempt the same procedure it will give me an error on the second machine saying the feature class cannot be edited, but this is not occurring when a coworker logs in and performs the same test. Is this expected behavior?

[ChrisDonohue__GISP · Accepted solution]

Generally, once a File Geodatabase is being edited, a lock is placed on it to prevent other users from editing it.  That being said, I have seen instances of multiple users who managed to get into the same feature class in the same file geodatabase and simultaneously edit it.  And, unfortunately, this usually soon resulted in a corrupted feature class.

In one case of mixed up communications, a colleague and I both got an urgent request to do a simple update on a feature class and both got into it without realizing the other was in it also.  We both edited it, then when we saved it then errored out and became unusable.  Oooops.  Luckily we were able to restore it from our backup system once we realized what happened.

The ESRI folks can give you the exact details, but my understanding is that the locks are placed in part based on the permissions assigned to the user.  That explains why you cannot access it with two machines, but a co-worker and you can.

Chris Donohue, GISP

[WayneGuidry]

Thanks for the information Chris. That is definitely concerning that you can corrupt a featureclass by not realizing someone else is editing it. Seems like the locking system needs to be corrected or even redesigned if it can't be fixed as is.

[ChrisDonohue__GISP]

Another thought - I've seen this issue crop up enough that I wonder if there is a third-party software out there that has been developed to help GIS Editors with communicating who is or isn't in a File Geodatabase.  Something that easily showed that a File Geodatabase was currently being accessed (instead of having to manually look at the folder with Windows Explorer and look in the File Geodatabase for the files with the "...sr.lock" in their names and then try to determine who the person accessing it is from the cryptic computer name that is part of the lock file name).

All you Developers out there, here's a product awaiting development! 

Chris Donohue, GISP