Do you remember my case? slow database. Then, through gstat we found bad
transaction handle from application's side.

I fixed up and now there is no gap between the OIT and the Oldest Snapshot.
Oldest transaction equals with Oldest snapshot (extreme equal), as you can
see in the bellow gstat.



After 2 weeks of usage, after backup restore, the database has begun to be
slow again. Of course is not so bad case as previously but still something
else is going wrong.



Just to remind you:

- The same application is running on different customer's branch
with more daily movements and they have no problem at all.

- The only difference between two branches is that the terminals
(and server) of this slow database are never close (they never rest ;) ).



Database "C:\Progra~1\Praxis~1\Trade\Database\ble_eg_pos.fdb"


Database header page information:

Flags

Checksum 12345

Generation 26825033

Page size 16384

ODS version 11.0

Oldest transaction 4253402

Oldest active 4253403

Oldest snapshot 4253403

Next transaction 26825027

Bumped transaction 1

Sequence number 0

Next attachment ID 0

Implementation ID 16

Shadow count 0

Page buffers 0

Next header page 0

Database dialect 3

Creation date May 23, 2008 0:54:59

Attributes force write



Variable header data:

Sweep interval: 20000

*END*



Do you see something wrong here?

What is the meaning of the "Next transaction" indication?



Best regards guys.

Dennis





[Non-text portions of this message have been removed]