Feature class in geodatabae not recognized

Question

Hi everyone,
I've been digitizing lines into a line feature class in a file geodatabase for the last few months.  Today I tried to export the feature class to a shapefile and got the following error.
Error exporting data.
FDO error: -2147024894 [GDB_UserMetadata]
FDO error: -2147024894 [GDB_UserMetadata]
FDO error: -2147024894 [GDB_ObjectClasses]
FDO error: -2147024894 [GDB_ObjectClasses]
FDO error: -2147024894 [GDB_ObjectClasses]
FDO error: -2147024894 [GDB_ObjectClasses]
When I look at the geodatabase in Catalogue it does not show my line feature class within it (it is the only feature class within the geodatabase).  
I can edit the feature class, it draws up correctly without any problems when I open the .mxd I've been working from for the past few months.  I can add and delete fields from the attribute table without any problems so...I assume the data is still there.
I've tried running the check geometry tool but get the following error:
ERROR 000210: Cannot create output N:\gdmp\Solar\rob_working\powerlines_from_SRTM.gdb\power_lines_srtm_CheckGeomet1
Failed to execute (CheckGeometry).
Hopefully someone can help.
Rob

VinceAngelo · Answer

Yeah, they were three weeks from delivery, too.  I got called in to evaluate and confirm
the bad news.
 
*And* it was meant to be a replacement for a client that lost a 6TB instance when the 
systems group failed to do backups because "it's a RAID array," and the RAID controller
had a memory leak that corrupted 8% of the blocks across five different filesystems.
Good times, indeed.
 
- V

JoeBorgione · Answer

File corruption can happen.

(I had a 
client lose a 9TB RDBMS instance when a mirroring backup process failed to detect filesystem 
corruption and overwrote the last successful backup with random garbage -- two weeks later
they had to restart a 15 week load procedure from CD and DVD media).

- V

OUCH!  That's a real bummer...

VinceAngelo · Answer

A file geodatabase is really a database without the RDBMS. It gets better performance, but it also 
doesn't have the ACID properties of an RDBMS (or the logging or backup and restore procedures
of one, either, unfortunately).   
 
File corruption can happen.  The best way to insulate yourself is to make regular backups.  It 
also wouldn't hurt to run some sort of validation procedure that visits all the rows in all the tables,
since a backup won't help if a corruption is introduced and permeates all your backups (I had a 
client lose a 9TB RDBMS instance when a mirroring backup process failed to detect filesystem 
corruption and overwrote the last successful backup with random garbage -- two weeks later
they had to restart a 15 week load procedure from CD and DVD media).
 
- V