a blow? yes, quite. firebird will return from a commit() as soon as the ramdrive aknoledges that
everything went through fine, rather than waiting for the "important" write operation to disk.
how 'bout reversing things? leave the primary db as an on-disk database (and please, synchronous
writes! i feel much safer with firebird's forced-writes than relying on the OS to come back up and
finish writing the journal file ...) and 'shadow' the db onto a ramdrive? run the slow stuff from
the oft-updated ramdrive, but do the 'important' (update/insert/delete) work on the main file? can
we do that?

and i still think the sort file is a problem -- disk i/o is what we're trying to avoid, and i'd say
that sorting on disk is going to be rather slow ... rather avoid it, especially for the big sorts.

found anything new?

-philip

> Thanks for that info Alan. That's a bit of a blow.

> > Shadowing is not under two phase commit operation. There are no
> trasnactions
> > in progress. It merely duplicates the disk write operation.
> > Alan