topic Locks persistent even having finished the geoprocess in Python Questions

Locks persistent even having finished the geoprocess

BorjaParés — Wed, 21 Sep 2011 06:52:35 GMT

Hello, I developed a Python script that reads a feature class in a file geodatabase and added to a mxd through arcpy.mapping library functions. The process is as follows:

df = arcpy.mapping.ListDataFrames(mxd, "Layers")[0]
arcpy.MakeFeatureLayer_management(env.workspace + "\\" + s, aux)
addLayer = arcpy.mapping.Layer(aux)
arcpy.mapping.AddLayer(df, addLayer, "BOTTOM")
del addLayer, aux, df
mxd.save()
arcpy.env.workspace = "";
del mxd

Even removing all references of the del command, I still maintain the following blocks in the File GDB to the features that add to the mxd:

_gdb.MAD0WK198.1104.5048.sr.lock
Anno_dee.MAD0WK198.1104.5048.sr.lock
Annotation1.MAD0WK198.1104.5048.sr.lock
Point1.MAD0WK198.1104.5048.sr.lock
Polygon1.MAD0WK198.1104.5048.sr.lock
Polyline1.MAD0WK198.1104.5048.sr.lock

I tried to delete the mxd generated but locks persist. This creates a big problem to me because the process then has a process of erasing entities of the GDB and clear, with the active locks I can not run the delete of each feature.

I noticed that just is arcpy.mapping.AddLayer line (df, addLayer, "BOTTOM") that generates the locks because if they put that line of code not generated, but brother python script ends are not released.

Any suggestion?

Thanks in advance!

Re: Locks persistent even having finished the geoprocess

curtvprice — Fri, 10 Dec 2021 22:45:43 GMT

Have you tried deleting the feature layer you created with arcpy.Delete_management?

The way I usually do it is this:

lyrPoly = "lyrPoly"
arcpy.MakeFeatureClass(fc,lyrPoly)
...
arcpy.Delete_management(lyrPoly)

Re: Locks persistent even having finished the geoprocess

curtvprice — Fri, 23 Sep 2011 19:20:31 GMT

This has been a major problem for me in the past and I posted the problem with personal geodatabases some time ago. The issue was supposed to be fixed with file geodatabases, but I've experienced problems.

Schema locks are not "going away" because they are critically needed to prevent destruction of geodatabase data. Personal geodatabase locks were a pain because a lock applied to the entire geodatabase (.mdb file). File geodatabase locks still exist, but they only applied to one feature class or table at a time.

The help has been updated with some very useful details on this topic:

'>Schema locking
File geodatabases and locking

Re: Locks persistent even having finished the geoprocess

StacyRendall1 — Sat, 24 Sep 2011 01:31:47 GMT

I have had problems with this also, but not in cases as simple as the original posters. Locks sometimes take a long time (well... long time for a computer) to clear, which is a huge pain in the ass. If you really need to do something that requires accessing the same .gdb quickly you are probably best to reconsider your entire method. I got around it once by doing all my calculations in Python, storing my temporary data in Python objects and writing to the output file only once with an UpdateCursor...

FYI this blog post, and the comments, discuss the issues pretty well, with regard to Cursors.