Fix for corrupt Feature Class in file GDB?

[DarylHochhalter]

Using ArcGIS 10.4, I have a point feature class in a file GDB that is somehow corrupt. I've tried Recovering the File GDB, that feature class comes back empty. I've tried uncompress, it tells me nothing is compressed even though the command should be dimmed out in that case. I've tried deleting and recreating the spatial index. When I try to export the data I get an error or it exports 2632 features even though the table says it has 2951 features. copy and paste fails when I choose paste from the popup menu with the error "copy failure". You can't see the missing features (features that won't export or import or paste) in the map, just that the table says they are there and you can select all and get 2951 of 2951 features. Even if you export just the table, you get 2632 features in the output table.

I tried adding fields to the table so I could calc geometry, but after adding field to the table it then shows only 2632 records.

Any help recovering 300 points would be appreciated!

[JoshuaBixby]

Robert, I agree that exporting to XML workspace can't hurt at this point, even if the odds are low any new data will be exported.

Regarding empty geometries, the most common way I have seen they get introduced into a feature class is when the feature class allows NULL for the geometry column and a user adds records without geometry in an edit session.  There is a bit of a hodgepodge when it comes to whether NULL or empty geometries get inserted into feature classes when no shapes are entered for records.  I cover some of the scenarios in one of my blog posts:  /blogs/tilting/2015/05/29/whats-in-your-feature-class-nothing-null-or-empty 

Even if a feature class has empty geometries, empty geometry are valid geometries, similar to how an empty string is a valid string even if there is nothing to see or print.  Records with empty geometries should export no different than records with non-empty geometries unless the back-end data store doesn't support empty geometries for some reason.

[LeeDavis1]

This just happened to me on a very large table of line segments. +2000 small line segments and attribute table of about 50 columns. This is a scary problem with File Geodatabase because for some unknown reason your data can disappear and it cannot be recovered by any means. It seems to me that something between the attribute and geometry tables gets out of sync, and the data no longer reads properly. Whats strange is that I can see the records in the attribute table but not in the map. Then when I export the data I only get like 20 of 2000+ features.

I get the attached error when I try to access the table preview from ArcCatalog.

This has happened to me a couple times now so I am careful with File Geodatabase because it is buggy. It seems to happen when I have multiple instances of arcmap or arccatalog looking at the same features, even though I'm only editing in one. This kind of thing never happened with Access based Personal Geodatabase, good ole MDB. Esri, please research and fix!

[George_Thompson]

Where was the file geodatabase being stored when the corruption happened?

[LeeDavis1]

C Drive actually. I know that editing FDGB on unstable networks can corrupt it so this is unusual.

[George_Thompson]

Interesting. I have not seen too much corruption on local drives.

I would recommend that you contact Esri Technical Support and have them look into this. If you do not report it to them and get a possible defect created, we cannot know what to fix.:)

[LeeDavis1]

I will if it happens again I have already replaced the feature class. I have noticed that if I'm careful to have only one arcmap or catalog session going when I edit it won't happen.

[Bob_Spaulding]

SOLVED (for me)!  Maybe unapproved methods, but there were few other good choices.  So I struggled with a similar issue for a week.  A feature class in a file geodatabase was corrupted, and my organization's server backup failed.  Any time I tried to view the feature class, it would halfway draw and then crash either ArcMap or ArcCatalog. I tried the "Recover File Geodatabase" tool.  I tried the "Fix Geometry" tool.  No luck.

Until a little voice told me I should fire up QGIS on my Macbook Pro and open up the file geodatabase there. And so I could see all the points on the map, and I could see, sort and filter the table.  I tried exporting to shapefile, and that failed to open in either ArcMap or ArcGIS Online.  I tried exporting to Excel, and that failed (though possibly user error).  But luckily, the table itself had embedded XY coordinates in it, and I was able to export to CSV.  

Again, the forum managers may intrinsically not sanction my particular methodology, but if nothing else works, I thought it deserved mention.  Credit to ESRI due if they haven't taken down my response by the time you're reading it!  Sometimes the last possible solution is the one that spurs creativity, and is ultimately what works!

[HagenProbsthain1]

I have the same problem, but with lines - and not only in one fGDB, it happens every now and then. For me it seems to be it's dependent of feature linked annotations. Just thats why it caught my eye, some annotations exist without lines.

If I go to the extent of the layer, I only see a part of all the lines. After zoom in, the lines appear on the screen. But nothing helps, not editing (move and move back), no repair tool, no update of the spatial index, no recover file geodatabase tool. Copy and paste fails, export to XML fails, export data from layer fails.

Strangely, QGIS with installed GDAL (default) is able to read the lines correctly, but an installation of QGIS with the FileDB API SDK from ESRI (see: https://gis.stackexchange.com/questions/26285/installing-file-geodatabase-gdb-support-in-qgis/26301#...) shows the same behaviour as ArcMap.

The export of the layer from QGIS (with default installation of GDAL) to a shapefile works. So I can import the shapefile features back to my fGDB featureclass.

Now the problem is forwarded to ESRI.

[AllisonBailey]

This was extremely helpful.

I had a very simple File Geodatabase with 5 feature classes in it.   One of the feature classes was a set of ~1500 points that I spent most of a day creating.  As I was editing, I saved the features frequently.   The next day when I opened the MXD, the point feature class was completely empty!  There were no error messages about a corrupt geodatabase, just an empty data table.   I tried the Recover File Geodatabase tool, but it did not recover the missing points.

Fortunately, thanks to your info, I was able to use GDAL on the command line to "find" and restore those points. When using ogrinfo, The default GDAL read-only FGDB driver (OpenFileGDB) found a discrepancy between a *.gdbtable and a *.gdbtablx and alerted me:

Warning 1: File ts3_yp.gdb/a0000000e.gdbtable (layer trainingpts_aldflh) declares 1511 valid records, but ts3_yp.gdb/a0000000e.gdbtablx declares only 0 total records. Using that later value for safety (this possibly ignoring features). You can also try setting OPENFILEGDB_IGNORE_GDBTABLX=YES to completely ignore the .gdbtablx file (but possibly retrieving deleted features), or set OPENFILEGDB_USE_GDBTABLE_RECORD_COUNT=YES (but that setting can potentially cause crashes)
Feature Count: 0

I tested setting the two environment variables:

When I set OPENFILEGDB_IGNORE_GDBTABLX=YES, ogrinfo did not see the feature class at all.

But, when I set OPENFILEGDB_USE_GDBTABLE_RECORD_COUNT=YES, ogrinfo listed the 1511 records. 

I was then able to use ogr2ogr to export the points from the geodatabase to a shapefile (or csv or other format) and restore my data!

For the record, I am working on ArcMap v.10.6 on a Mac running Parallels for Windows applications.  I save the data onto a folder on the Mac drive, not the Parallels "C" drive.  I have not previously had any issues with this workflow and have been using it since 2013.

I have never run into this situation where data completely disappeared from a file geodatabase and I'm very appreciative for this thread so I could work through a solution to retrieve it.

[KariBuckvold]

So I know this probably isn't the most copacetic solution, but doing a Windows File Explorer "Previous Version" on the folder has actually worked for us. https://support.microsoft.com/en-us/help/17119/windows-7-recover-lost-deleted-files