Paul Reeves wrote:

> This is curious.
>
> Have you looked in the NT Event Logs?
> How many users?
> Has anything else changed?

No changes that I can think of. However, the single app that is used is
under constant development - maybe I've introduced some bad vibes ...
Just a few users - hardly ever more than 5.

Anyhow. I visited the site today. Things weren't quite what I had been
told (are they ever?). Available RAM was about 30MB, but now there was
also a second database running.
The difference between OIT and NextTransaction was about 2000 - this may
indicate a problem in the application, but some transactions are quite long
(e.g. when exporting most of the database for use in another
application). The use of RAM was observed through TaskManager - not the
most reliable source for info, but probably close enough.

The server has 256MB RAM, and is running NT4WSsp6. This probably means
that with two databases running (each with 8192 cache pages @ 8KB) 200+MB
RAM will be required. So, the observation that it was running low on RAM
isn't totally unexpected. Probably, the previous observation (before
patching) when RAM was totally depleted had been scary.
When all the users of one of the databases disconnected, the available RAM
jumped back up. I reduced the number of cache pages for one of the
databases, this should reduce the overall RAM requirements.

The reason for failed backups was that the backup job expected to find gbak
in an Interbase directory (default for Fb/0.9 ?) when the new install had
put it in a Firebird directory.

In short:
1. Things didn't look all bad (when I was there).
2. We'll watch the server closely.
3. If the problem persists, I'll consider build 796.


Thanks for the input.
Aage J.