"}],"short_description":"Data management tips and tricks for managing locks in a temporary file geodatabase with automated workflows.","flexible_content":[{"acf_fc_layout":"content","content":"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.<\/p>\n
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<\/a>) application. We\u2019ll then show you how to easily resolve it. Lastly, you can explore how mobile, file, and enterprise geodatabase locks compare to one another.<\/p>\n"},{"acf_fc_layout":"content","content":" 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<\/a>.<\/p>\n 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?<\/p>\n"},{"acf_fc_layout":"image","image":{"ID":2072952,"id":2072952,"title":"FirstRunError_SecondRunNoError_PyCharm2","filename":"FirstRunError_SecondRunNoError_PyCharm2.png","filesize":83400,"url":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/FirstRunError_SecondRunNoError_PyCharm2.png","link":"https:\/\/www.esri.com\/arcgis-blog\/products\/arcgis-pro\/data-management\/locked-by-another-application-using-arcpy-and-a-file-geodatabase\/firstrunerror_secondrunnoerror_pycharm2","alt":"Illustration of code shows the error of locked by another application on first run and no error on second execution.","author":"313872","description":"","caption":"","name":"firstrunerror_secondrunnoerror_pycharm2","status":"inherit","uploaded_to":2070612,"date":"2023-09-11 19:00:25","modified":"2023-09-20 16:14:55","menu_order":0,"mime_type":"image\/png","type":"image","subtype":"png","icon":"https:\/\/www.esri.com\/arcgis-blog\/wp-includes\/images\/media\/default.png","width":1056,"height":576,"sizes":{"thumbnail":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/FirstRunError_SecondRunNoError_PyCharm2-213x200.png","thumbnail-width":213,"thumbnail-height":200,"medium":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/FirstRunError_SecondRunNoError_PyCharm2.png","medium-width":464,"medium-height":253,"medium_large":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/FirstRunError_SecondRunNoError_PyCharm2.png","medium_large-width":768,"medium_large-height":419,"large":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/FirstRunError_SecondRunNoError_PyCharm2.png","large-width":1056,"large-height":576,"1536x1536":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/FirstRunError_SecondRunNoError_PyCharm2.png","1536x1536-width":1056,"1536x1536-height":576,"2048x2048":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/FirstRunError_SecondRunNoError_PyCharm2.png","2048x2048-width":1056,"2048x2048-height":576,"card_image":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/FirstRunError_SecondRunNoError_PyCharm2-826x451.png","card_image-width":826,"card_image-height":451,"wide_image":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/FirstRunError_SecondRunNoError_PyCharm2.png","wide_image-width":1056,"wide_image-height":576}},"image_position":"center","orientation":"horizontal","hyperlink":""},{"acf_fc_layout":"content","content":" 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?<\/p>\n 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. \u00a0Implementing 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<\/a> site and online help documentation<\/a> 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.<\/p>\n"},{"acf_fc_layout":"content","content":" Copy and paste the code below into your IDE<\/a> 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:<\/p>\n Click anywhere in the code window, then use the \u2b06\ufe0f and down \u2b07\ufe0f arrows on the keyboard to scroll through the code.<\/p>\n","image_reference":false,"layout":"code_snippet","image_reference_figure":"","snippet":"# Import system modules\r\nimport arcpy\r\nimport os\r\n\r\n# Set local variables\r\nout_folder_path = r\"C:\\Testing\\Testing\"\r\nout_name = \"TestDelete.gdb\"\r\ngdbPath = os.path.join(out_folder_path,out_name)\r\nfc_name = \"TestFC\"\r\n\r\n# CreateFileGDB if it doesn't already exist.\r\n# Add a new text field\r\n# Populate the text field with each text string in a list (total of 5 rows)\r\nif not os.path.exists(gdbPath):\r\n myGDB = arcpy.management.CreateFileGDB(out_folder_path, out_name)\r\n fc = arcpy.management.CreateFeatureclass(gdbPath, fc_name, geometry_type='POLYGON')\r\n arcpy.management.AddField(fc,'NAME','TEXT')\r\n attList = ['a','b','c','d','e']\r\n with arcpy.da.InsertCursor(fc, ['NAME']) as TestCursor:\r\n for att in attList:\r\n TestCursor.insertRow(att)\r\nelse:\r\n myGDB = gdbPath\r\n\r\nif gdbPath:\r\n arcpy.management.Delete(myGDB)\r\n","spotlight_name":"","section_title":"","position":"Center","spotlight_image":false},{"acf_fc_layout":"content","content":" This code will generate the above locking error the first time it runs.<\/p>\n Run it again, and it now properly deletes the geodatabase.<\/p>\n"},{"acf_fc_layout":"content","content":" 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\u2019s 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.<\/p>\n"},{"acf_fc_layout":"sidebar","content":" Click anywhere in the code window, then use the \u2b06\ufe0f and down \u2b07\ufe0f arrows on the keyboard to scroll through the code.<\/p>\n","image_reference":false,"layout":"code_snippet","image_reference_figure":"","snippet":"# Import system modules\r\nimport arcpy\r\nimport os\r\n\r\n# Set local variables\r\nout_folder_path = r\"C:\\Testing\\Testing\"\r\nout_name = \"TestDelete.gdb\"\r\ngdbPath = os.path.join(out_folder_path,out_name)\r\nfc_name = \"TestFC\"\r\n\r\n# CreateFileGDB if it doesn't already exist.\r\n# Add a new text field\r\n# Populate the text field with each text string in a list (total of 5 rows)\r\nif not os.path.exists(gdbPath):\r\n myGDB = arcpy.management.CreateFileGDB(out_folder_path, out_name)\r\n fc = arcpy.management.CreateFeatureclass(gdbPath, fc_name, geometry_type='POLYGON')\r\n arcpy.management.AddField(fc,'NAME','TEXT')\r\n attList = ['a','b','c','d','e']\r\n with arcpy.da.InsertCursor(fc, ['NAME']) as TestCursor:\r\n for att in attList:\r\n TestCursor.insertRow(att)\r\nelse:\r\n myGDB = gdbPath\r\n\r\n#Add this line to remove locking error\r\n#The del keyword is the \u2018key\u2019 solution.\r\ndel TestCursor \r\n\r\narcpy.management.Delete(myGDB)","spotlight_name":"","section_title":"","position":"Center","spotlight_image":false},{"acf_fc_layout":"content","content":" Adding del TestCursor allows us to remove the if statement and directly delete the temporary geodatabase.<\/p>\n"},{"acf_fc_layout":"content","content":" 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.<\/p>\n As mentioned earlier, each geodatabase handles locking in different ways. If this workflow was using a mobile geodatabase, we wouldn\u2019t 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.<\/p>\n"},{"acf_fc_layout":"sidebar","content":"","image_reference":false,"layout":"code_snippet","image_reference_figure":"","snippet":"out_name = \"TestDelete.geodatabase\"\r\nmyGDB = arcpy.management.CreateMobileGDB(out_folder_path, out_name)\r\n","spotlight_name":"","section_title":"","position":"Center","spotlight_image":false},{"acf_fc_layout":"content","content":" Why does the mobile geodatabase delete without error, whereas the file geodatabase returns the error? It\u2019s all about how they handle locks. To learn more about how each geodatabase handles locking, see the help documentation for mobile geodatabases<\/a>, file geodatabases<\/a> and enterprise geodatabases<\/a>.<\/p>\n 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.<\/p>\n In the end, it is recommended that you clean up your code by deleting objects that are no longer applicable.<\/p>\n This information can help if you encounter the locked by another application error when automating workflows with temporary file geodatabases. Here\u2019s to one less scripting headache. ?<\/p>\n"},{"acf_fc_layout":"content","content":" All Adobe Stock images are \u00a9 2023\u00a0Adobe Stock. All rights reserved.<\/p>\n"}],"related_articles":"","card_image":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/GoldenKeyinPuzzle826x465.jpg","wide_image":"https:\/\/www.esri.com\/arcgis-blog\/app\/uploads\/2023\/09\/GoldenKeyinPuzzle1920x1080.jpg","show_article_image":false},"yoast_head":"\nScenario<\/h2>\n
Sample code<\/h2>\n
\n
Solution<\/h2>\n
Takeaways and considerations<\/h2>\n