When moving large data sources between servers and personal computers I frequently utilize cloud storage services, like Google Drive, to help facilitate the move. During a recent project, I ran into an interesting issue when attempting to move an unzipped file geodatabase that contained a large attachment table into Google Drive to transfer between a server and my personal computer. With this discovery, I wanted to share how I identified the issue and resolved it to hopefully save you some time in the future if you run into it.
The Issue
The issue arose when downloading the file geodatabase folder from Google Drive. Once the database was downloaded, I attempted to open the database in an ArcGIS Pro project but got an error that the database was corrupt and missing files. Since it was a large database I assumed something went wrong during the download.
Downloading the database a second time from Google Drive I noticed that I was getting prompted to save two files. One was the expected .gdb folder and the other was a file that should have been in the .gdb folder, in this case, called “a0000000b-003.gdbtable”. Another interesting aspect of this is that -003 was added to the file name. Recognizing that this “a0000000b-003.gdbtable” belonged in the .gdb folder I moved “a0000000b-003.gdbtable” into the .gdb folder and removed the appended -003 from the name. Once that was completed the database opened fine in my Pro project and my attachments were accessible.
The Solution
The solution to mediate the issue before it is discovered on the downloader’s side is to ZIP the file geodatabase folders before uploading to a cloud storage platform, in this case, Google Drive. This will ensure that everything stays together from the start and no stray files get missed, requiring time spent troubleshooting to pinpoint the issue.
Connecting Directly to Cloud Storage Services
Similar issues can occur when working with cloud storage file connections in ArcGIS Pro. ArcGIS Pro supports connecting to cloud storage services, but there are some things to consider. Most of the problems stem from workflows that create .lock filetypes, such as when editing. This is because multiple users can access a file in cloud storage and end up creating multiple copies of the same file. You can read more about this issue here, including Esri’s workarounds for the issue. The webinar recording below from Esri highlights various cloud storage solutions that are supported for use in ArcGIS Pro and will reduce the issues we’ve explored here today.
Having worked with GIS files in a variety of shared storage solutions, my takeaway is that they should be read-only or only have one user at a time doing edits. This will reduce the opportunities for errors, corrupt files, and lost updates that can happen due to locks and version reconciliation.
