Hello, Mrs Borrie.
My name is Ivan Maradzhiyski.
I am a computer engineer. I work as an IT manager in an oil trade
company in Bulgaria.
At first I want to express my admirations for your great work!
I work with Firebird RDBMS for about five years. Firebird has many
features that make it a modern, flexible and useful RDBMS.
I have a cluster of servers, data synchronization among them every
five minutes and many clients simultaneously connected to every server.
I use only Slackware and freeBSD on my servers.
From the beginning I have problems with database corruptions.
There is no change with the new Firebird 2.0.3.
I have forced writes switched on, enough RAM, speedy SATA harddisks,
MS Windows-free servers, UPS-es. But the problems continue.
Another problem is with long server rollbacking.
If a client stops his long-running report, the server begins to
rollback and this may take days.
And if a client tries again the report, the server returns deadlock(my
reports write data into cache tables).
It seems there is no reason for a database corruption, but it is a fact.
About 5% of my time is for resolving database corruption problems.
My opinion is that stability and reliability will make you more
popular and gain you more supporters than adding extra functionality.
For instance, I used to work with Sybase SQL Anywhere before Firebird.
An occasion of a database corruption happened only once and that was
because of a defective PC RAM.
My conclusions for database corruptions:
1. Network problems.
I make db connections through VPN.
Sometimes, when VPN fails and there is an open db connection, the
database corrupts.
2. When killing a long running rollback server
process(fb_inet_server). My fault in this case.
3. On power failure. Sybase use transaction recovery log to deal with
power failures.
4. When killing a client process fetching long running reports,
sometimes index and/or data pages appear corrupt.
5. Sometimes, when fetching long running reports, extracting data from
same tables.

I hope I helped you with this information.

Best regards
Ivan Maradzhiyski