> I work for a medical software company that used InterBase/FireBird as
> it's primary local operating database. Unfortunately, due to major
> database corruption and other issues with both the FireBird and
> Borland versions of InterBase, they were forced to migrate away from
> InterBase.

In general, except for systems running on Windows with forced writes off,
Firebird databases rarely become corrupt (well, file copying a database will
make the copy corrupt).

> However, they are now considering FireBird once again. I am charged
> with proving that the various improvements to FireBird over the last
> year or so has fixed the problems we were having and have made
> FireBird generally a lot more stable and worthwhile for enterprise
> use. I would like to say that I have already read documents
> describing all of the improvements made since FireBird 0.9 including
> embedding, memory management, and the porting from C to C++ so please
> only refer me to documents that cover this data corruption topic
> specifically, if they exist.

"A lot more stable" - definitely not. I've never seen a corrupted Firebird
database (albeit I have read about it), and that 'never' hasn't become less
frequent lately ;o) (we switched from InterBase to Firebird when it was version
0.9.4).

> The symptoms we were having before revolved mostly around data
> corruption. One thing that is believed may have caused these issues
> is from support personell copying the various .gdb files either while
> transactions were in progress or without the InterBase service being
> shutdown. Another cause may have been from physically switching off
> machines presumably during some sort of transactions. The company
> moved to Sybase due to its superior transaction control because these
> issues costed the company tens of thousands of dollars in support to
> repair the database at machines across the country.

The copy will in all such cases be corrupt, support personnel should be trained
not to make file copies of database files.

> To test the corruption, the databases would be run through the error
> checking tools provided by firebird to verify and repair the databases
> but they never seemed to actually find any problems with the databases
> even when it was obvious the database was corrupted. For instance, a
> database file would be error checked and verified but if you tried to
> insert a record and then do a select on that same record you would get
> no result.

This sounds like corrupt indexes, which can be fixed by backup/restore I think
(in some cases, you may have to do something to get rid of duplicates
afterwards).

Read the thread "Lost records" from yesterday/today, in particular the last
reply by Alexander V Nevsky (Ded). Then hope for Ann Harrison to answer your
mail, she is the expert in recovering InterBase and Firebird databases and I
think she hasn't fixed many Firebird databases where the corruption were not due
to forced writes off.

Set
- I support Firebird, I am a Firebird Foundation member. Join us at
http://www.firebirdsql.org/ff/foundation. We're quite friendly and welcome new
members.