> We've been thinking about the way in which IB and FB (we've used
> both) identifies a session in memmory, because the server starts
> gaining memmory and never releases it until the last user closes the
> application.

I have a client setup with 4 terminal servers, each running between 10
and 30 terminal users and accessing a separate WinNT4 server running
Firebird. This setup has now been in place for a couple of years (the
earlier version accessing IB5.6). It works well and we dont appear to
have any dificulties specific to IB/FB server or the client app (built
using IBO).

The difficulties we have seen in the past relate to memory useage on
the terminal server itself. With 20 or 30 users you need a lot of
memory on the terminal server or things start swapping to virtual
memory with dramatic impacts on performance.

For example the users also run various MS-Office applications and also
Outlook Express for email - both of which can consume huge amounts of
memory. Specifically we have had to get the users to delete all
old/excess mail from Outlook Express as the more messages it contains
the more OE consumes.

Earlier versions of my client application used Delphi runtime
libraries. This gave the application a startup memory use of around
25Mb! Rebuilding to an all-in-on executable reduced the startup
memory requirements to around 12Mb.


Since it is the IB/FB server which seems to be giving you problems you
may have to review what you are doing. The main instance where I have
seen IB/FB consume large amounts of memory and not give it back very
quickly was selecting large numbers of records (around a million or
so for data transfer purposes). It was ok when it is a simple select,
but when the select was more complicated the memory consumption just
grew and grew until the select was finished. (I cant remember the
full details of the select off-hand, I would have to dig through my
email archives since I actually posted a message about it here.) I
ended up having to split the transfer processing into sections in
order to be able to complete the processing without driving the server
into the ground.

--
Geoff Worboys
Telesis Computing