can anyone help me with issue - how to delete the FGDB, in which netwarok dataset was created and built?
In my script I create a temp FGDB with arcpy.CreateFileGDB_management, then
This temp FGDB is then copied to another FGDB. The problem is, when I want to delete this temp geodatabase.
I am not able to delete it with arcpy.Delete_management, even if before it I used compact tool.
I also tried shutil.rmtree("path_to_TempFGDB"), but this throws me an error -
[WinError 32] The process cannot access the file because it is being used by another process: '<Path to temp FGDB>\\MMB_NW.gdb\\a00000009.FDO_ID.atx' - still the same file.
Do you have any idea, why this file is still being locked? Is there any way, how to remove this lock? There is no PRO or another tool which would use the FGDB, just the Python.
Thank you for any idea.
Just an general FYI for people reading this looking for solutions
Feature classes and tables participating in a network analysis dataset or a topology cannot be deleted.
The in_memory workspace does not support geodatabase elements such as subtypes, domains, representations, topologies, geometric networks, network datasets, or feature datasets.
Which now raises the question, can the gdb be deleted by conventional means after the script is complete?
If so, one thing to consider in your workflow is to check for the existence of your temporary gdb at the beginning of a script and if it exists, try the delete there.
Dear Dan Patterson, I used this workaround now.
I thought, that it could work, when I want to delete whole FGDB.
I was just curious, what is the problem here. When I run another standalone script to delete the FGDB with folder (or delete the tempFGDB at the start of the script - as you noted) - then it works fine, but if I run rmtree or another delete tool in the script which made the tempFGDB and Network dataset, I am not able to delete the temp FGDB.
I suspect garbage collection by either python or arc*, who knows for sure... sometimes adding a time.sleep solves a problem, sometimes not.
I only get worried if I can't delete something after the script has finished by 'conventional' means, that is through python, Pro tools or the operating system.
So check first, then delete if you have a repetitive workflow makes me worry less but does leave a bit of junk lying around. Just add a secondary standalone 'delete' process to your toolbox (assuming you are creating them) for preparing for an analysis, or to clean up after.
Apparently, gil, threading and python versions cover some of these issues, but I find it just makes my head hurt sometimes PEP 0 -- Index of Python Enhancement Proposals (PEPs) | Python.org