Thanks Helen for the details. Please read inline

On 17/10/2010 05:01, Helen Borrie wrote:
>
> gstat -h will tell you some useful things about the state of garbage
> collection. If your client code is behaving correctly, you should not
> see enormous differences between the 'Oldest transaction', the 'Oldest
> Active transaction' and the 'Oldest snapshot'.
>
Oldest transaction 10360730
Oldest active 10360731
Oldest snapshot 10360731
Next transaction 10360732
Bumped transaction 1

So I believe this should be good (I have pasted the whole data below).

One thing is that between start and stop of my application and starting
and closing a screen I have an increase of almost 200 count of
transaction numbers, for eg. previously Oldest transaction was 10360535
now it is Oldest transaction 10360730. Is this good? Is there a limit
to the counter? If I reach it I believe I need to do a backup and
restore, but what might happen if the limit is reached what kind of a
behavior should me application be prepared for? The reason I ask is
this, is because users do not tend to have database administrators, they
are simple users and I won't be able to keep a tag on them being just a
developer so I need to preempt via code and warn them that they need to
do this or that.

> Not all frameworks are created equal with regard to completing
> transactions. What's more, if your framework provides an
> autocommit-style of transaction management, you should take steps to
> find out whether it uses COMMIT RETAINING instead of a hard COMMIT.
> Hard COMMIT = good, COMMIT RETAINING is a bad legacy from the old
> Borland world, that should be avoided.
>

As per the header the Attributes is set to "force write", so is this
fine if we are aiming for a Hard COMMIT? Sorry about my lack of
knowledge of database tuning.


> Most driver frameworks for Firebird have their own forums or lists.
> That's where you should go for advice about what your framework does
> under the hood.
>
Yes, I have subscribed to such forums. Just FYI, I use Visual FoxPro as
the development language and use Remote Views for data-entry purposes
and SQL-Pass Through to get details for application data-validation /
reporting as required, all via ODBC.

> It's not ideal to be having to shut out users, though. Nor is it great
> to be having users put up with regularly degrading performance. IMO it
> should never be regarded as a way to avoid improving the behaviour of
> applications.
>

Thanks a lot.

Kind regards
Bhavbhuti


Database header page information:
Flags 0
Checksum 12345
Generation 10360799
Page size 4096
ODS version 11.1
Oldest transaction 10360730
Oldest active 10360731
Oldest snapshot 10360731
Next transaction 10360732
Bumped transaction 1
Sequence number 0
Next attachment ID 126225
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Feb 27, 2009 18:01:35
Attributes force write

Variable header data:
Sweep interval: 20000
*END*