Subject Re: [firebird-support] Embedded server database easily corrupted
Author Eddie Bush
When you used SS, was the server located on the same machine as the client, or was the server a different machine from the clients?

If the server was a different machine, then I can see where you would have better luck. The worst you could wind up with in the event of an untimely power-down would be limbo transactions.

I'll cast another vote for a UPS, just in case you're tracking votes :-)

If people are just flipping the switch on their machines, perhaps the key is educating them? If they dislike corrupt databases, maybe they'll be willing to take the time to shutdown properly once they have someone tell them that doing so would help keep the database in a valid state? Hey - stranger things have happened :-D

Good Luck!

Eddie Bush
----- Original Message -----
From: Da Jiao
Sent: Sunday, March 14, 2004 10:05 PM
Subject: Re: [firebird-support] Embedded server database easily corrupted


> First, power-offs (exspecially multiple) are a sign that something is
> Is the user turning off his system by some power switch instead of
> it down? Investigate this.

All happened on the customers' desktops. power-off is just a guess and there
are too many factors out of our control.

> Second, disable write-back-caching in your OS. Database servers are
> to keep information intact, if the system is powered off at any time.
> (Therefor power-offs should only lead to loss of the information that was
> changed during power-off.) As someone on this list stated, embedded server
> is behaves similar to superserver - except to missing multiclient and
> multithread support. It should handle such conditions just fine.

How to disable write-back-caching? It is not only loss of data but corrupted
db file, and the same thing does not happen often for superserver version.
There got be some differences between these two.

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
Version: 6.0.620 / Virus Database: 399 - Release Date: 3/12/2004

[Non-text portions of this message have been removed]