--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:

> * You have a limited amount of data that fits into an affordable
> amount of memory.

Yes, this is the case.

> * You do not need to concern yourself with concurrency

Correct, concurrency is not a concern.

> In turn, you understand that your system will have limited
> scalability. If you are running in a 32 bit environment, then 2GB is
> your limit (3GB if you know the boot switch to push it). I don't

know

> your problem domain, but I can only assume you have considered the
> implications of loading everything into memory. To solve larger
> problems, you would need to take a different approach.

We'd love to have that problem! ;) Seriousely: this is a general
purpose, general audience app and it shows that most of our clients
have 512MB to 1GB RAM. With the "big numbers" that I cited earlier we
fit pretty comfortably in 512MB.

> However, I am confused as to why you need to constantly perform
> selects if you have already loaded your database into memory in your
> application. Surely it would be faster to use what is already in

memory.

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.

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

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

Thank you!
Val