The new ScratchGDB and ScratchFolder environments

One of the enhancements to the 10.1 release was the addition of two new environment variables (scratchFolder and scratchGDB) as mentioned in the What’s New for Geoprocessing in 10.1. (If you haven’t read it, check out all enhancements!). While new environment variables may not exactly sound exciting, as a tool developer you’ll want to know this as you probably have worried at one point about handling intermediate data in your model, script or custom function tool. Generally you would want to be writing intermediate outputs to the “in_memory” workspace for performance gains, but there will be times you must persist the output to disk.

Prior to 10.1 you made use of the scratchWorkspace environment to write intermediate data. The scratchWorkspace provides the ability to write temporary data, but can be problematic as it can be either a folder or a geodatabase (depending on how your environment referenced it). You may have constructed your tool thinking that scratchWorkspace is a folder, as you’ve set ArcMap’s scratch location to a folder. When you shared your tool with a co-worker, their scratch environment setting was set to their Default.gdb and your tool failed as it tried to write shapefiles (.shp) into their file geodatabase.

This is where it starts to get exciting. At 10.1 these two new environment variables help you control where your output will be written to. Exactly as they sound, scratchFolder writes to a folder and scratchGDB writes to a geodatabase. Use them in your scripts and models in the same way you do now with the scratchWorkspace.

As shown, use the inline variables %scratchFolder% or scratchGDB% inside your models.

Or reference the environments while scripting by using arcpy.env.scratchFolder or arcpy.env.scratchGDB.

Here are the key points you need to know to when using these:

• Both variables are derived from your scratchWorkspace. This is typically set in the application executing the tool. If the application’s scratchWorkspace is set to c:myTemp, then scratchFolder is that same folder. The scratchGDB would point to c:myTempscratch.gdb. (a File Geodatabase called ‘scratch’ inside that folder)
• These variables guarantee a folder or scratch.gdb will always exist. In the above example, if a scratch.gdb did not exist inside c:myTemp, the use of these variables would create this gdb for you. If your scratchWorkspace was set to c:myTempscratch.gdb, then this variable is the same as scratchGDB.
• If the application does not have a scratchWorkspace set, the default location for both the Folder and GDB becomes the current users’ temp directory as defined by the operating system.
• These variables can be used in both Desktop and Server environments.
• You can continue to use the scratchWorkspace variable in your workflows, but the publishing and packaging process will produce output with tools using scratchFolder or scratchGDB.