HI

> 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.

> The symptoms we were having before revolved mostly around data corruption.

Hard to believe for me. Using firebird the right way never caused database
corruption to me.

> 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.

This is like working on a engine while the car is running. This is a No-No.

> Another cause may have been from physically switching off machines

presumably during some sort of transactions.

Due to the careful write mechanism in firebird (and interbase) physically
switching off machines should never lead to corrupt databases. The only
exception is, if there is any kind of cached-write-strategie is used on the
host. For Windows this means to disable write-cache for the harddrive the
database is running on.
Anyway, physically powering of a running database *can* result in loss of
the last writen records - this is diffrent from corrupt databases. No
software can prevent this. Not even sybase.

> The company moved to Sybase due to its superior transaction control ...

I don't know Sybase that good. What is superior on it's transaction control
?

> ... because these issues costed the company tens of thousands of dollars

in support to repair the database at machines across the country.

Sorry, but I think this is not true.
Those costs arose from support personel doing things the wrong way but not
from the database system. Train them or fire them.
Obviously sybase seems to prevent support personel from doing some wrong
things, but it's not the database servers job to take support personel by
the hand...

> 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 seems to be a problem with indices. And you are right on this.
Error-checking a database should also find such problems. Right now, gfix
does not do this by default.
Anyway, it is always a good idea to rebuild all indices after a database
analysis and repair.

You could state, that corrupt indices do not affect the data already stores
in the database and therefor need not be considered as corrupt database. But
as I already stated, I assume you are right, this SHOULD be considered a
problem.

> Is there better file locking and handling in FireBird now to minimize data

corruption?

No. It needn't. Just train support personel to work the right way.

> Is there better transaction logging/control in FireBird now to minimize

data corruption?

No. It needn't. Transaction logging/control is fine the way it is and always
was. That's one of the major advantages to firebird...

> Are the firebird database tools improved so that error checking,

detection, and repair will work better?

Sorry, as far as I know, by default they still do not detect such problems.
Anyway, you alway could force this by doing backup/restore - which has by
the way always been the recommended way...

> Where can I find more discussion about this specific topic?

Here. And in firebird-devel.

> Our machines around the country cannot be guaranteed to stay up or never

be shut down inappropriately even during database transactions but the
effect of this has to be minimal and easily detected and repaired.

It already is - and it has been for a long time. Firebird handles everything
possible in a perfect way. Just disable write caching.

Regards,
Steffen