> 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.
>

You can't use the shadow as a real database while it's a shadow. It's locked
for writes and it's not a database anyway - it's a disk image.

Alan