Corrupt Geodatabase

Question

I tried to access a geodatabase in ArcCatalog that I had been using in ArcMap all morning and got this message:

Failed to connect to database. This release of the GeoDatabase is either invalid or out of data. [Invalid Geodatabase release]

My coworker was also using feature classes in the geodatabase in ArcMap. At first, after I got the message, a different coworker was still able to access the geodatabase in ArcMap but not in ArcCatalog, and then after a while, none of us were able to access it in ArcMap or ArcCatalog.

We had this issue a few weeks earlier with another geodatabase. With both, we were using them normally as we have been for months/years.

Our GIS specialist said that he had heard of the issue before and suggested a few things:

1) Compact database - didn't work because it said we could only use that function for personal geodatabases, which doesn't make sense because it says in the description that you can use it for file geodatabases

2) Repair geometry - can't do this because we can't access it

3) Export to workspace - also would not run

We opened an old copy and checked geometry, and nothing was wrong with that. I tried to Google the error, and all solutions didn't apply to us - we did not try to access it in Windows Explorer, it is not on an SDE, etc.

Any suggestions? We have accepted the fact that we likely can't repair it, but we want to prevent this issue from happening again in the future.

Answer 1

There aren't many things you can do when ArcGIS stops recognizing a file geodatabase. The simplest is to write off the edits as lost and replace the directory tree under the .gdb with your most recent backup. If something horrific has happened to your systematic backups, you can try zipping up the remains of the .gdb and contacting Esri Tech Support, where the specialists there have more sophisticated tools for diagnosing the impact of data loss events and salvaging what data may remain.

There aren't many things you can do to prevent future file corruption, either. It is highly unlikely that the loss is due to a bug in the FGDB I/O library. The most likely causes are media failure on the physical disk where the data resided and a transient network event which caused a network write failure. Since network access speed is significantly slower than local access, editing of a network-sourced FGDB should be avoided. A filesystem integrity check should be performed on the volume where the corrupt geodatabase was located, since a bad block, chain of blocks, or sector could poison any data which is stored in it.

Answer 2

Sounds like your team might really benefit from implementing version control infrastructure in ArcGIS. There's a bit of overhead but it's worth it to prevent that kind of headache from happening again. Check out ArcGIS' overview of versioning.