Feature class in geodatabae not recognized

[RobKay]

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

[JoeBorgione]

A suggestion; typically you can click on the error for a hyperlink with 'details ' of the error. I use the the word details quite liberally here.

The next suggestion would be to bundle up your data and contact tec support. It maybetough this week with the UC running.

[RobKay]

Hi everyone,
Fixed this problem...much to my relief.
This is what I did.  I used the Copy Features tool (Data Management - Features) to copy the features of the line feature class to another file geodatabase.  This was done through my working .mxd because as mentioned before, the feature class was not visible/recognized through ArcCatalogue or FME.
I was then able to export the feature class to shape file from the new file geodatabase.
Solution turned out to be simple but still don't know why it happened.
Cheers,
Rob

[VinceAngelo]

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

[JoeBorgione]

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]

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