Sean,

>> Don't forget the MaxUnflushedWrites and MaxUnflushedWriteTime
>> parameters, which allow you to decide how much data you can afford to
>> lose in case of crash.

S> I don't believe that is the correct way to look at it.

S> The settings control the **window** in which a non-forced write db will
S> be in danger of being corrupted.

Yes, that seems a more correct way to put it.

S> Unless the MaxUnflushedWrites is set to 1, any other value will create a
S> situation where some disk writes could be unflushed, and therefore the
S> "on metal" database is potentially corrupt -- due to some pages writes
S> being potentially written out of order by the OS disk/cache management.

I had assumed that in case of crash anything that was not flushed is
not written at all. Couple this with the careful write strategy and
the result is no corruption possible. But if there's a chance for
unflushed writes to be written to disk when a crash occurs, then
you're right and corruprion can happen.

S> Personally, I will never allow a production database to be deployed with
S> Forced Writes = OFF -- I want to sleep at night.

So do I - although other reasons for not sleeping at night abound. I
wish every piece of software I use had a "let me sleep at night"
setting. :-)

Ciao
--
Nando Dessena
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================