arcpy & GDB .lock files: Best Practice for executing arcpy tools while minimizing .lock file persistance

Discussion created by pfoppe on Dec 2, 2014
Latest reply on Nov 21, 2016 by saraemani1

FYI for the community. 


The Problem:

So I recently ran into a problem where I wrote a nice little python script to export some feature classes to a FGDB and then zip the FGDB for delivery.  Every time I tried to zip the FGDB in the same python process as my 'feature class to feature class conversion' execution the zip routine would fail with a message that looked similar to:

Traceback (most recent call last):

  File "<OBSCURE_PYTHON_FILE>.py", line <#>, in <module>



  File "C:\Python27\ArcGIS10.2\Lib\", line 1149, in write

    with open(filename, "rb") as fp:

IOError: [Errno 13] Permission denied: u'<OBSCURE_PATH>\\<FGDB_NAME>.gdb\\_gdb.<HOSTNAME>'

Indicating that something within my process had an 'sr' lock (schema lock??).  By placing some time.wait() statements... I tracked it back to the command:



It appears that the arcpy.FeatureClassToFeatureClass_conversion function was placing a .sr.lock file in the FGDB and that it was not released until the code completed execution. This is a problem since I'm trying to zip up the FGDB after placing some data in it. 


The FIX:

Based on this thread... Lucas Danzinger came to the conclusion that:


The reason it worked when I had it in a function is because the variables were automatically deleted once the code in the function completed successfully.


so I took the arcpy.FeatureClassToFeatureClass_conversion() call and placed in a function called 'tmp()'.  As soon as I did that the .sr.lock files disappeared before my time.wait() executed and the zip process finished with success. 


An alternative (and my preferable method) is to delete the 'res' object (arcpy.Result) once completed.  That also effectively removed the sr.lock file. 

if res.status !=4:
    #do something
del res


So bottom line...

Get in the habit of executing arcpy operations in a function (the .lock will be bound to the scope of the function* and upon completion of the function the .lock file should be cleanly removed) OR delete the result object returned by the function call. 


*If the result is written to a global variable, then the scope would be larger than the function and would most likely still retain a .lock file. 


Hope this article helps others with these type of issues.