Subject Re: Embedded Server Forced Writes Not Working
Author Adam
> I am notable to see forced writes actually cause writes until my app
> shuts down. My understanding is that Forced Write is turned on by
> default and infact if I move the database to a superserver and perform
> SHOW DATABASE using isql it shows Forced Writes as true. The
> DatabaseInfo class of the provider shows that Forced Write is enabled as
> well.

Don't confuse physical disk space allocated to the fdb file to the
amount of data stored in the database. The database works on "pages".
A page is usually 4096 bytes, but other values can be used when you
create or restore the database. Requesting disk space from the OS is
not the sort of thing you want to be doing too frequently. The OS wont
understand the urgency of the request and Firebird will have to wait
for it. Unless you use the "USE_ALL_SPACE" flag in gbak, the restored
database will have enough room left on the same page for record
versions. What I am trying to say is that don't expect the file to
grow the moment you insert data (and don't expect it to shrink, ever).

Here is a quicker test, as long as you don't care too much about the
guinea pig system. You claim that your committed changes are not
written to disk until after the program terminates. Run your program
and make sure the data commits. Pull the power. When you boot up, your
data should all be there, even though the file size may not have
changed. (Obviously this only tests that the data is written sometime
before the reboot. But if you don't commit, although everything was
written to disk, the transaction is flagged as rolled back.

Other things that may or may not be of interest:

1) Garbage collection runs as a separate thread, perhaps this thread
causes the engine to allocate more space.

2) Explorer doesn't immediately reflect the changes in file size.

Adam