Subject | Improvements in the last year |
---|---|
Author | triptomik |
Post date | 2004-05-27T20:49:24Z |
Hey Guys,
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.
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.
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.
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.
My questions are:
*Do the improvements made to FireBird recently address these issues
and were they a major concern with other companies/organizations ?
More specifically:
*Is there better file locking and handling in FireBird now to minimize
data corruption?
*Is there better transaction logging/control in FireBird now to
minimize data corruption?
*Are the firebird database tools improved so that error checking,
detection, and repair will work better?
*Where can I find more discussion about this specific topic?
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.
Thank you very much for taking the time to assist me with this, my
company very much respects the volunteer work of open source
developers and supporters and, on occasion, pays for developers to
contribute as well.
Augey Mikus
Software Development Consultant
ScriptRx, Inc.
www.scriptrx.com
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.
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.
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.
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.
My questions are:
*Do the improvements made to FireBird recently address these issues
and were they a major concern with other companies/organizations ?
More specifically:
*Is there better file locking and handling in FireBird now to minimize
data corruption?
*Is there better transaction logging/control in FireBird now to
minimize data corruption?
*Are the firebird database tools improved so that error checking,
detection, and repair will work better?
*Where can I find more discussion about this specific topic?
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.
Thank you very much for taking the time to assist me with this, my
company very much respects the volunteer work of open source
developers and supporters and, on occasion, pays for developers to
contribute as well.
Augey Mikus
Software Development Consultant
ScriptRx, Inc.
www.scriptrx.com