Hi,

At June 28, 2004, 05:16, Santiago Cordoba wrote:

> <You can use the GSTAT command-line to retrieve both information.

> Here It is:

> Database header page information:
> Flags 0
> Checksum 12345
> Generation 5401040
> Page size 8192
> ODS version 10.1
> Oldest transaction 5396132
> Oldest active 5396133
> Oldest snapshot 5394502
> Next transaction 5400951
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 16
> Shadow count 0
> Page buffers 8000
> Next header page 0
> Database dialect 1
> Creation date May 15, 2004 19:25:20
> Attributes force write, database
> shutdown
> Variable header data:
> Sweep interval: 0
> *END*

Just to add to Phil's response. Do you realize that your database is
shutdown? Or, did you shut it down to run GSTAT?

> <And, is it possible that the WAN users using FR might cause some
> <problems(maybe the FR connection is not strong enough, sometimes)?

> I do not understand so that a connection WAN can have poblems

If I'm not mistaken when you mention FR connections, you mean
Frame-Relay connections, right! And, if they are frame-relays, are
those connections staying alive for the duration of the connection.
They might be dropping intermittently(and reconnecting by itself), and
that the user doesn't notice this happening, but Firebird will notice
it. It's just a guess at this point, since someone on this list had
similar problems in the past with FR connections. So, if a connection
is dropped, that could explain the difference between the OAT and the
next transaction. But, this could also happen if a user shuts off(by
pressing on the power button) their computer without properly closing
the application and shutting down the computer. The same can be said
if they disconnected from the remote connection before closing the
application.

Also, does your application uses BLOBs a lot? There has been some
known memory problems with BLOBs, but I don't really know if they are
fully fixed. But, in relations to your case, the high memory usage
could also be related to query sorts(this usually happens when an
index can't be used to order the result set), and FB will use as much
memory as it can, before using temp files on the HD.

Also, I just noticed that you didn't mention if you are using FB 1.5
Superserver or Classic Server. Can you specify which one, just for add
clarity? I suspect you are using Superserver, but I just want to be
sure.

--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)