topic Re: Problem with File Geodatabase Locking in Data Management Questions

Problem with File Geodatabase Locking

JenniferPhillips — Tue, 24 Jan 2012 20:18:20 GMT

I am having problems with locks in our file geodatabase. I understand that multiple people cannot edit at one time, and that one person cannot edit while others are viewing the same layers. But we have an issue where once someone is in the map with the layer, and then closes out, it keeps the "sr" lock active, and sometimes an "rd" lock too. This prevents one user from being able to edit that layer, even though everyone else is closed out. Typically, the person already closed out will have to restart their computer to get the lock to finally release. This is a big problem, as you shouldn't have to have everyone restart their computer in order to edit.

Does anyone know how to get around this?

Thank you!

Re: Problem with File Geodatabase Locking

AntonyPaul_M1 — Tue, 24 Jan 2012 23:39:11 GMT

Is your file geodatabase is compressed? If so uncompress it and try.

Thanks
Antony

Re: Problem with File Geodatabase Locking

JenniferPhillips — Wed, 25 Jan 2012 16:25:31 GMT

I don't believe that it is compressed. We did try compacting it, and the locks still hung on through that. It actually took a restart of that computer to wipe out the locks.

I found out some more information on file geodatabases, that explains some of my problem. Apparently with file geodatabases, if someone is viewing the data (has it open on their map), and then another user goes in to edit, it will not allow them to save edits, since they cannot acquire a lock. But if that person is editing the data first, and then others open it to view it, it works fine. So it comes down to who gets into the data first.

I do not have an explanation for why the locks do not go away when people close out of the program. The locks hang on sometimes until that person restarts their computer. Like I said before, they even hang on through a compaction. This happens pretty inconsistently, sometimes the locks hang on and sometimes they don't. I still don't understand this.

Re: Problem with File Geodatabase Locking

LanceShipman — Wed, 25 Jan 2012 17:03:46 GMT

The only way a lock file will persist is if a process is maintaining it.The lock files are created as "delete on close" so the operating system will delete them when the creating process closes. If the creating process has not closed the locks will remain until the process is deleted. You should never need to restart you PC to clear the locks. Is your file geodatabase local or on a network disk? What version of ArcGIS are you using?

Re: Problem with File Geodatabase Locking

JenniferPhillips — Wed, 25 Jan 2012 22:16:29 GMT

The file geodatabases are located on our server. I have ArcEditor version 10.1.3.1. The other users in the office use ArcDesktop - some are version 10, others are still on version 9.3.1. Other people in the office access our ArcReader map only and have no software installed.

Thanks,
Jennifer

Re: Problem with File Geodatabase Locking

LanceShipman — Wed, 25 Jan 2012 23:07:55 GMT

Compact only removes orphan locks (which rarely exist). The only way to orphan a lock is to pull the plug on your PC. The locks hanging around means that some process is holding on to them. The lock name includes the file name, the name of the machine, thread id and the process id.

Re: Problem with File Geodatabase Locking

WayneCoffey1 — Wed, 20 Jun 2012 18:06:44 GMT

I have had a similar issue with lock files intruding on my processes. I just resolved one part of the issue when I realized I had the data published in a map service running on ArcGIS server. When I turned the service off the lock files went away and I was able to add new data/ edit existing data in the feature data set.
This seemed like the most relevant thread to post this, please add to others if this helps.

Wayne

Re: Problem with File Geodatabase Locking

DanielHester — Mon, 04 Nov 2013 11:31:56 GMT

We have a similar problem with a shapefile feature class. Periodically it will not save edits with a "Cannot save edits; cannot acquire a lock" error message. Working in 10.1 with a water main shapefile (with about 5 other users on different workstations viewing the layer). It has been suggested to us that the toplogy/rules associated with the layer is causing the problem. Does anyone know if this might be the problem and or has a solution?

Thanks!

Dan

Re: Problem with File Geodatabase Locking

NidhinKarthikeyan — Tue, 05 Nov 2013 10:26:37 GMT

Daniel,

Topology cannot be created on a Shapefile. So you can rule out that suggestion. You will receive the error if any of the other four users are editing the same Shapefile. Also make sure the attribute table is closed after other users make edit and save edits on the Shapefile.

Re: Problem with File Geodatabase Locking

DanielHester — Thu, 07 Nov 2013 15:16:43 GMT

Understoood; however the funny thing is that only one person is editing. Every other user is simply viewing the file.

Re: Problem with File Geodatabase Locking

WilliamCraft — Sat, 14 Dec 2013 03:05:39 GMT

Understoood; however the funny thing is that only one person is editing. Every other user is simply viewing the file.

Viewing the contents of a file geodatabase OR editing its contents using an Esri product, it doesn't matter which, will produce a .LOCK file inside the file GDB's folder on the file system which can be seen via Windows Explorer. It will contain some numbers in its filename, one of which refers to the process ID (PID) of the active process connecting to it. To know which process or application has your FGDB locked, open Task Manager and explore the contents of your GDB folder on the file system using Windows Explorer. Add the PID field to Task Manager and then compare the process IDs in Task Manager to that of the lock file to identify the culprit. The presence of the .LOCK file is essentially an exclusive lock and won't allow you to do much else other than view the FGDB contents until it is gone. Killing those connections can be done by ending the process brutally in Task Manager or gracefully closing an application or stopping a GIS service, if applicable.

Now, if there is no lock file or process holding on to the FGDB, then you probably have a system lock of some sort that hasn't cleared up. Rebooting should resolve that; but if rebooting isn't possible then you'll need to close the FGDB files manually. If you have Windows 7 or Server 2008 R2 or higher, then go to the Start menu and type 'fsmgmt.msc', pick the Open Files node, multi-select the files that are open in your FGDB folder, and right click them to close all.

Re: Problem with File Geodatabase Locking

OlegLukyanov — Mon, 16 Dec 2013 09:34:38 GMT

Hi,

Is there any way to edit data in file geodatabase with ArcGIS Desktop Basic and share it for viewing with ArcGIS Server map service without stop\start service by user?

It seems I could edit data in personal geodatabase in ArcMap and see changed data in ArcIMS ArcMap service earlier.

Thanks

Oleg

Re: Problem with File Geodatabase Locking

WilliamCraft — Mon, 16 Dec 2013 09:59:32 GMT

Hi,

Is there any way to edit data in file geodatabase with ArcGIS Basic and share it for viewing with ArcGIS Server map service without stop\start service by user?

It seems I could edit data in personal geodatabase in ArcMap and see changed data in ArcIMS ArcMap service earlier.

Thanks

Oleg

You can edit the data VALUES of your published object classes using a desktop or web client while the services are running. I don't think the level of AGS dictates this. But typically you cant make schema changes to those objects though since services place a lock on them when running. Technically, you could modify the schema while the service is running if you change the schema locking setting in the service configuration file but unexpected results can occur until you restart the service anyways.

Re: Problem with File Geodatabase Locking

OlegLukyanov — Mon, 16 Dec 2013 10:11:20 GMT

"You can edit the data VALUES"

Is it true for ArcGIS Desktop Basic (former ArcView) and file geodatabase? As I understood from previous post it is possible trouble due file geodatabase locks?

Thanks

Oleg

Re: Problem with File Geodatabase Locking

WilliamCraft — Mon, 16 Dec 2013 10:38:42 GMT

"You can edit the data VALUES"

Is it true for ArcGIS Desktop Basic (former ArcView) and file geodatabase? As I understood from previous post it is possible trouble due file geodatabase locks?

Thanks

Oleg

I looked at a comparison chart for the basic, standard, and advanced levels of ArcGIS for Desktop. The standard and advanced levels have "Edit a multiuser enterprise geodatabase" specified as a capability but the basic level does not. That being said, I'm not sure if that translates into the functionality you're describing. If you have a seat of ArcGIS for Desktop Basic, give it a try and post your results. I'm just as curious as you at this point.

Re: Problem with File Geodatabase Locking

OlegLukyanov — Mon, 16 Dec 2013 10:57:47 GMT

Sorry,
but we don't have ArcGIS for Desktop Basic now. We have AGD Standard and ArcGIS for Server Stanard for WG.
And I need more inexpensive solution for our new users like file geodatebase editing.

Thanks

Oleg

Re: Problem with File Geodatabase Locking

TylerVeinot2 — Thu, 04 Apr 2019 12:55:01 GMT

I am haing a similar issue, we have a file geodatabase that we access through ArcGIS 10.6 and QGIS 2.18.x and 3.4.6 and 3.6.1. QGIS was being used to make some simple edits and changes without issue. Suddenly several layers started throwing the error "Failed to Update Row (User does not have permission to execute this operation); No ones user permissions have changed to caused this. My ArcGIS is still able to edit and there are no locks on the data anywhere in the filegeodatabase so we don't understand what the issue is. As it is I am the only one able to edit and this is a huge hindrance because there are more edits than what I can do. I tried compressing/uncompressing, compacting, copying. The only thing that sort of worked was exporting the effected layers to a shapefile, deleting them from the geodatabase, and importing the shapfiles back into the database. Any thoughts on this one?