Just about everyone who has used geodatabases has encountered a locking issue in their GIS workflows. Each geodatabase has its own locking processes. We often forget when encountering a lock, such as locked by another application, that locks have an important role.
This blog focuses on this lock with an automated workflow using ArcPy with a temporary file geodatabase. Using sample scripts directly from this blog, you will experience the error in your own integrated development environment (IDE) application. We’ll then show you how to easily resolve it. Lastly, you can explore how mobile, file, and enterprise geodatabase locks compare to one another.
Scenario
In this example, the code creates a temporary geodatabase, adds schema and data, and then deletes the geodatabase. All appears well until your code attempts to delete the geodatabase, and instead returns the following error: Error 000601: Cannot delete temp.gdb. May be locked by another application.
In addition, we wrote the code so that a second run will only attempt to delete the temporary geodatabase. You run the code again, and this time it deletes the geodatabase without error?
Unlike similar workflows that generate this error (such as, other users accessing the data), this scenario is using a temporary geodatabase. No other users are connected to it. Why did the error happen in the first place? How do we write the code to prevent this peculiar locking error from occurring when deleting the geodatabase?
Ironically, I recently ran into the same problem after getting deep into a sample script tool I was designing. I got so deep into writing what the code needed to do, that I failed to consider best practices. Implementing what I have learned in the past would have alleviated this exact issue. These best practices apply to any type of programming. Fortunately, my oversight could benefit others, especially beginner ArcPy or ArcGIS API for Python users. Resources such as our Esri Community site and online help documentation provide brief information on how to resolve this challenge. However, I wanted to provide a working example to use in your own environment to illustrate and resolve the issue.
Sample code
Copy and paste the code below into your IDE of choice (Pycharm, IDLE, Spyder and so on). The only line of code you need to alter is the out_folder_path variable. This script does the following:
- It creates a file geodatabase called TestDelete.gdb in the designated output directory.
- It populates the geodatabase with a feature class.
- Adds a text field and populates it with a list of characters (a, b, c, d, and e) for each row.
- If a geodatabase path exists, it attempts to delete it.
This code will generate the above locking error the first time it runs.
Run it again, and it now properly deletes the geodatabase.
Solution
How do you write code that properly deletes the temporary file geodatabase without the error indicating that it may be locked by another application? Using Python’s del keyword, you release objects that may cause a locking error to occur. In this example, the code used an Insert Cursor to add data to a new field. Deleting the cursor object releases the lock and the code now deletes the temporary geodatabase without error. Delete the previous script and copy and paste this code to see the difference.
Adding del TestCursor allows us to remove the if statement and directly delete the temporary geodatabase.
Takeaways and considerations
As you can see, when working with a file geodatabase as a temporary workspace, the key is to delete unreferenced objects. Once deleted, the temporary file geodatabase is also removed without error. For example, in the sample script tool that I built earlier, I deleted objects that accessed feature classes, tables and cursors that were no longer needed in the code. These sample scripts illustrate that without using the del keyword, the code would error with the locked by another application message. With proper code cleanup, the temporary geodatabase removal works as expected.
As mentioned earlier, each geodatabase handles locking in different ways. If this workflow was using a mobile geodatabase, we wouldn’t get the error at all, with or without the del keyword. You can try it by changing these two lines of the first script to create a mobile geodatabase.
Why does the mobile geodatabase delete without error, whereas the file geodatabase returns the error? It’s all about how they handle locks. To learn more about how each geodatabase handles locking, see the help documentation for mobile geodatabases, file geodatabases and enterprise geodatabases.
As for enterprise geodatabases, it is unlikely that these would be used as a temporary workspace. The complexity of implementing them on a supported database management system (DBMS) is quite involved for this type of workflow.
In the end, it is recommended that you clean up your code by deleting objects that are no longer applicable.
This information can help if you encounter the locked by another application error when automating workflows with temporary file geodatabases. Here’s to one less scripting headache. 😀
All Adobe Stock images are © 2023 Adobe Stock. All rights reserved.
Commenting is not enabled for this article.