I'm sure you'll get responses to your specific questions here, but out of
interest if Sybase was able to address and fix the issues you had previously
had with Firebird/Interbase, I'm curious as to the reason why you want to
move away from Sybase now?

Myles

===========================
Myles Wakeham
Director of Engineering
Tech Solutions Inc.
Scottsdale, Arizona USA
Phone (480) 451-7440
Web: www.techsol.org

> -----Original Message-----
> From: triptomik [mailto:triptomik@...]
> Sent: Thursday, May 27, 2004 1:49 PM
> To: firebird-support@yahoogroups.com
> Subject: [firebird-support] Improvements in the last year
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>