Cannot delete temp gdb on subsequent iterations because of lock

[FranklinAlexander]

I am having a major problem preventing me from running a python 3x script. I am iterating over dozens of folders and creating lots of temporary data on each iteration. I am creating a temp gdb to store the temp data, then deleting and creating a new one on each pass. I have done this before with no issue, but now, after the first iteration I am getting a lock error Cannot delete C:/WebDev/Projects/...\temp.gdb. May be locked by another application. I want to emphasize that nothing is open, all programs including ArcPro have been closed before running the script and the error persists. I know this is a common issue and am hoping that someone can please give me a work-around. I have also tried just overwriting the gdb, but cannot do that either. 

I have found this statement in the esri documentation regarding schema locks:

"Scripts may always update the schema of data created by tools within the same script, even if the current workspace is being used by another application."

If I understand this correctly, as long as the data being created from within the script (including the temp gdb) I should not be getting a lock error when attempting the delete it. 

Can anyone please shed some light on this?

Thanks! 

[DanPatterson]

is in_memory not an option?

Write geoprocessing output to memory—ArcGIS Pro | Documentation

[FranklinAlexander · Accepted solution]

Yes, I did try that and it works great once I have finished developing and testing the script:

tempDB = arcpy.env.scratchGDB

While testing, however, I need to be able to see the temp data so I can troubleshoot my errors and I cannot do that if the temp data is in memory. I did find a solution that seems to be working so far. I just create a fresh temp gdb first (not inside the for loop) and set arcpy.env.overwriteOutput = true. I don't have any lock errors deleting the temp gdb when on the 1st iteration, so that works fine. Just a little frustrating that I have been testing this script for weeks without any issue (even with ArcPro open!) and the last few days I started getting the lock error. 

Thanks for the suggestion and it's nice to have that option when setting the script to run on a schedule from the enterprise server. Less that can break!

[JoshuaBixby]

With nothing open that access that FGDB, make sure there are no orphaned lock files.  If a previous run terminated prematurely or incorrectly, it might be an orphan lock that the script is seeing and not allowing the FGDB to be cleaned up.

[FranklinAlexander]

Thanks for the suggestion. I am not sure I am able to check on that since I don't have admin privileges. However, I don't think that is the issue since the script doesn't throw an error on the first iteration. If there is an orphan lock, then I think it is being caused by some process in the script and not by ArcPro or some other program not releasing it. At this point, I have found a workaround, so it's not an issue any more.