Problem Deleting scratchGDB after script runs

10468
11
02-27-2014 05:22 AM
MarcCusumano
Occasional Contributor
I have a script running that does a bit of spatial analysis, creates a relationship table and exports layout images to JPEG for report.

It runs great, but I am having a problem doing proper cleanup. I go to delete the scratchGDB using arcpy.delete, and it works fine. The problem is that a leftover scratch.gdb remains in the workspace directory.

After running arcpy.delete the leftover scratch.gdb is not a true geodatabase; in ArcCatalog it appears as a folder with a plus to the left of it. Drilling down on the plus and there is nothing in there.

I also added a line to delete that file in python and I get this:

[Error 5] Access is denied: 'D:\\gis\\Data\\scratch.gdb'

Sometimes the script works fine without deleting the scratch.gdb (it simply overwrites), other times it tells me it cannot create the initial output and fails. I would appreciate any help.
Tags (2)
11 Replies
MattEiben
Occasional Contributor
This should work through arcpy:

if arcpy.Exists(r"D:\gis\Data\scratch.gdb"):
    arcpy.Delete_management(r"D:\gis\Data\scratch.gdb")


If that's not working, you could try to do it through straight Python instead.

import shutil, os

# This will remove the entire folder, plus any subfolders
if os.path.isdir(r"D:\gis\Data\scratch.gdb"):
    shutil.rmtree(r"D:\gis\Data\scratch.gdb")


Usually the Arcpy way is preferred though since ArcMap is fond of it's file locks.
0 Kudos
MarcCusumano
Occasional Contributor
Thanks for your reply. However the problem is not a lock or getting things to work. The arcpy.delete function works, and it deletes all feature inside the gdb, and the gdb too.

The problem is there is a leftover folder called scratch where the file geodatabase scratch.gdb used to be. Inside the folder is another folder called "info", and inside of "info" is arc.dir

This is causing the script to fail on the next pass. Since it is running daily via task scheduler, it is not working. This is not acceptable.

Why is the esri delete function not removing the scratch geodatabase? It is better to not delete at all, then at least the scratch geodatabase and features inside are overwritten.

It seems the arcpy.delete function only serves to corrupt the scratch geodatabase, rendering it useless, instead of actually deleting it.
0 Kudos
ClintDow
Occasional Contributor
Perhaps try:

arcpy.Delete_management(arcpy.env.scratchGDB)
arcpy.Delete_management(arcpy.env.scratchFolder)
arcpy.Delete_management(arcpy.env.scratchWorkspace)


This should delete the folders as defined in the user's environmental variables. arcpy.env.scratchGDB and scratchFolder exist within the scratchWorkspace (or the parent folder if the scratchWorkspace is a gdb)

Also these methods return a variable which should be 'true' (string) if the operation was successful for additional checking if necessary.
0 Kudos
MarcCusumano
Occasional Contributor
Perhaps try:

arcpy.Delete_management(arcpy.env.scratchGDB)
arcpy.Delete_management(arcpy.env.scratchFolder)
arcpy.Delete_management(arcpy.env.scratchWorkspace)


This should delete the folders as defined in the user's environmental variables. arcpy.env.scratchGDB and scratchFolder exist within the scratchWorkspace (or the parent folder if the scratchWorkspace is a gdb)

Also these methods return a variable which should be 'true' (string) if the operation was successful for additional checking if necessary.


Thanks for the suggestion. I added these lines, and they "work", but there is still a scratch.gdb folder leftover, and now it has two files inside. Both are "xxxx.sr.lock"

Anybody from esri care to comment? I feel like this should be so easy...
0 Kudos
JamesCrandall
MVP Frequent Contributor
Isn't the scratch.gdb designed to *always* be available and *guaranteed* to exist?  If so, why attempt to delete it (if that's even possible)?

Edit:

Also, the suggested "clean up" is not saying to delete the .gdb or the workspace.  Rather it is saying, delete the contents of the .gbd:

http://resources.arcgis.com/en/help/main/10.1/index.html#//00570000006w000000


import arcpy
import os
inFC = arcpy.GetParameterAsText(0)

tempFC = arcpy.env.scratchGDB + os.path.sep + "tempFC"
arcpy.CopyFeatures_management(inFC, tempFC)

# Do some work here...

# Clean up when done...
#
arcpy.Delete_management(tempFC)




Why not use the "in_memory" workspace instead?
0 Kudos
JamesCrandall
MVP Frequent Contributor
There's also another similar thread on this topic from yesterday too:

http://forums.arcgis.com/threads/103648-Scratch-Workspace

Some good info in there.
0 Kudos
MarcCusumano
Occasional Contributor
Isn't the scratch.gdb designed to *always* be available and *guaranteed* to exist?  If so, why attempt to delete it (if that's even possible)?

Edit:

Also, the suggested "clean up" is not saying to delete the .gdb or the workspace.  Rather it is saying, delete the contents of the .gbd:

http://resources.arcgis.com/en/help/main/10.1/index.html#//00570000006w000000


import arcpy
import os
inFC = arcpy.GetParameterAsText(0)

tempFC = arcpy.env.scratchGDB + os.path.sep + "tempFC"
arcpy.CopyFeatures_management(inFC, tempFC)

# Do some work here...

# Clean up when done...
#
arcpy.Delete_management(tempFC)




Why not use the "in_memory" workspace instead?


I had actually thought of using in memory workspace, but was not sure if you can use it with a map document. Part of my script uses a detailed layout saved in an .mxd in the same folder the script runs with the layers pointed into the scratchGDB for jpeg exports.

I'll try just deleting the feature classes out of the scratch gdb. I would feel more comfortable if the gdb was completely deleted however as "schema locks" seem to always come back to haunt me.
0 Kudos
GeorgeRiner
New Contributor III

I get what the OP is getting at. I had the same issue. Except that I was creating script/tool that left a file geodatabase as its result. I need to have the tool test to see if this resulting file geodatabase already exists before it creates it. If it exists, it will delete it and create an empty one before proceeding into the guts of the script.

Thus, the expected code was:

gdb_dir = r"C:\Temp"
gdb_name = "result_gdb.gdb"
gdb_path = r"C:\Temp\result_gdb.gdb"
if arcpy.Exists(gdb_path):
  arcpy.Delete_management(gdb_path)
arcpy.CreateFileGDB_management(gdb_dir,gdb_name)
arcpy.CreateFeatureclass_management(gdb_path,"myPolys","POLYGON")

Except that, like the OP, when I step through this in the debugger, right after the "Delete_management" call, I notice that a file directory with the same name as the file geodatabase still exists. Thus, if this non-gdb file directory exists, the Exists() function call returns a <True> value and the code would end up calling the Delete_management function.

I discovered that the following code produces curious (surprising, unexpected) results:

gdb_dir = r"C:\Temp"
gdb_name = "result_gdb.gdb"
gdb_path = r"C:\Temp\result_gdb.gdb"
arcpy.CreateFileGDB_management(gdb_dir,gdb_name)
arcpy.CreateFeatureclass_management(gdb_path,"myPolys","POLYGON")
arcpy.Describe(gdb_path).workspaceType
# returns u'LocalDatabase'
arcpy.Delete_management(gdb_path) # the first call to Delete
arcpy.Exists(gdb_path)
# returns True
arcpy.Describe(gdb_path).workspaceType
# returns u'FileSystem' # the type has changed
arcpy.Delete_management(gdb_path) # the second call to Delete
arcpy.Exists(gdb_path)
# returns False # now it returns false

So, now the python code might have to check just how much the target file geodatabase has been deleted.

I don't want to enable overwriting for the script. I'm not using a 'scratch' workspace. It's not an 'in_memory' usage. I just expect that when I call a function to Delete something that that thing is actually deleted, not just turned into a different type of object.

So, now the code is:

while arcpy.Exists(gdb_path):
     arcpy.Delete_management(gdb_path)     # just keep calling Delete until it finally goes away
0 Kudos
PriscillaCole
New Contributor II

I tried this while loop.... And it's still while-ing, several minutes later. Does this approach actually work, or is this an infinite loop?

0 Kudos