> I am sorry if I didn't make it clear enough: we almost do not do any
> DB SELECT-s (except in the beginning when we load the data). Only
> occasional UPDATE-s and INSERT-s. Yes, all queries are in memory.

For inserts, the cache would be used to enforce the unique restriction
on any primary keys. Updates still need to do a select internally, so
I imagine both of these operations would benefit from the in memory cache.

Whether the frequency of 'occasional UPDATE-s and INSERT-s' is high
enough to justify the memory footprint is something only you can answer.

>
>
> > To the database engine, it is like power being cut before it had a
> > chance to complete its writes. You have lost any uncommitted work
> > (obviously) and any unflushed writes. If you have disabled forced
> > writes, you could be in for corruption trouble or if your lucky you
> > may just lose some data you thought was committed. If you create the
> > database in 1.5 or higher, Forced writes are enabled by default.
>
> Yeah, we did not touch the forced writes.

Good

>
> > That said, your application should detect if the media is removed
> > while your application is running, and provide an error message that
> > advised them to never do it again. Possibly your application can
> after
> > the server disconnects manually flush the drive (I am sure it would
> be
> > possible using some Windows API) and then advise the user it is safe
> > to remove the media.
> >
> > Once you disconnect from the embedded database, all the writes
> should
> > have been flushed, so even if they rip it out it should be fine.
>
> Some of the things that you suggest are already done for us by the U3
> platform (this is a software platform promoted by a consortium of
> flash drive makers, where all your data and programs reside on you
> your flash disk so that you can travel really light). Currently we do
> ClearAllPools() before exiting. Am I understanding you correctly that
> even after this call there is a chance that not all buffers are
> flushed even though the forced writes are enabled?

I am not familiar with U3, so I can only answer generically. Once you
have unloaded the Firebird dll from memory, the embedded Firebird
instance is gone and so can not make any more changes to the file.

If ClearAllPools flushes any writes to disk, and if it is called after
unloading the server from memory, then it should all be there.

Adam