ArcGIS Pro - Error 999999 "Cannot acquire a lock"

14348
12
09-29-2015 12:50 PM
TravisBugg1
New Contributor III

I find that I'm getting this error quite a bit. Mostly when working with Mosaic Datasets, but also with other geoprocessing tools. The data is stored on a network location. No one else is accessing the data. I'm not sure why there is a lock in place. In the past, I've been able to get around this by using the ArcPy command line. That works maybe 50% of the time.

I just tested this by creating a new File GDB and then attempting to create a Mosaic Dataset within the GDB. The GDB had never touched, and still I get this error. Is this because I'm accessing a network drive? This is the same location that I work in when in ArcMap 10.1, and it works fine from there.

Also, I've noticed that about half of the time, Mosaic Datasets aren't even visible from the "Add Data" window.

Can anyone shed any light on the situation? Why are these GDBs locked? Adding vector data from file GDBs doesn't seem to be a problem, but mosaic datasets are very problematic. I've upgraded to ArcGIS Pro 1.1.1, and this is still happening.

Thanks.

Edit: It looks like the Create Mosaic Dataset tool gets as far as creating the AMD...CAT catalog file within the GDB before it fails.

0 Kudos
12 Replies
EvanCarey1
New Contributor

I am having the same issue when working with a network dataset. There should be no reason for a lock, I am working completely local. 

0 Kudos
StephenUsmar2
New Contributor II

I am working locally from a file geodatabase and I've found that compressing and uncompressing the dataset removes the 999999 lock error. This is done using the Compress File Geodatabase Data and Uncompress File Geodatabase Data tools. There was no reason for locks on my datasets but this seemed to work for me.

BenSperry
New Contributor II

I was having the same problem. What eventually worked is just closing the Attribute View for the feature I was working with. I don't know if this is the whole problem but it worked for me.

DavidHorrocks
New Contributor II

I encountered the same problem while trying to calculate a field. Checking the "Start Editing" checkbox in the tool dialogue fixed the issue.

deleted-user-EpRzjYvkmULR
New Contributor III

This worked for me on Calculate Field and Repair Geometry.

Can we get someone from Esri to weigh in on this? Why is this happening in a FGDB? Currently working in ArcGIS Pro 2.2.3. Starting an edit session through the tool and saving the edits is a very lengthy workaround for me given that I have well over a million records in the feature class in question.

ChristopherSanchez
New Contributor II

I was looking all over for an answer to why I kept getting an Error saying "cannot acquire a lock" and found a couple of solutions but none of it worked. I just found a weird solution that is actually really simple! So if you're that random person still trying to figure something out this may work!

I wrote up my calculation, then clicked into one of the cells as if I were going to write something into it, then clicked out of the cell completely, then ran my function and it ran through. I'm not sure why this is what I have to do in order for my field calculator to work, but hope this helps someone!

WernerStangl
New Contributor II

Wow. It didn't work for me the first time, but randomly clicking in and out cells in the attribute table and changing the to-be-calculated field in the drop-down menu back and forth made it work at the third try. Terrible bug!

0 Kudos
JoeBorgione
MVP Emeritus

This is an older thread, and the only mention of software version is 10.1 back in 2015.  What version of ArcGIS are you 2020 guys using?  Can you elaborate on the workflow?  Database flavor, etc?

That should just about do it....
0 Kudos
ChrisNewton
New Contributor II

I'm experiencing a similar problem to above when using Calculate Field in ArcGIS Pro 2.5.2 . I've selected records from a table using select by attributes, I'm now trying to populate a text field for all selected records, which returns the above error. All data stored locally in a gdb.

0 Kudos