At 06:52 AM 18/11/2007, you wrote:

>The platform is Fedora Core 5 hosting Firebird/SuperServer 2.0.3
>(LI-V2.0.3.12981 Firebird 2.0) using the binary tarsball as downloaded
>from firebirdsql.org. The client application is a simple Perl test
>script using DBI-1.601 and DBD::InterBase 0.47, the current latest
>versions of each. I'm using the Firebird-supplied ``employee.fdb''
>database for this simple test.
>
>The crux of the question is that ONLY the ``Next transaction'' value
>increments. All of the other transaction-related counters reported by
>``gstat -h'' remain static. The application is such that ``Next
>transaction'' increments at the rate of once per second. I am aware of
>the importance of ``keeping the OIT moving'' and am curious if ONLY
>the incrementing of ``Next transaction'' is a problem waiting to happen.

It indicates that you have started (n-1) transactions (where n=Next transaction) and none have been committed. As soon as you commit the *oldest* one you have running, the Oldest Active will move forward. Since all of the transactions you have started so far are still running, Oldest [Interesting] is still the same as Oldest Snapshot (which is the "high-water mark" transaction from the previous garbage collection). Nothing has been garbage-collected, so the Oldest Snapshot remains the same as the Oldest Interesting

>If need be, I can post the short Perl script here (but am aware that
>this is not the venue for DBI and DBD queries). So I have framed the
>question in a general Firebird context concerning the transaction
>counters.

Add some COMMITs. :-) Just make sure they are hard COMMIT calls, not COMMIT RETAINING.

I don't know the DBD::InterBase driver but it's not uncommon for driver interfaces to default to performing what's sometimes called "Autocommit". Usually, this is implemented with COMMIT RETAINING, not a hard COMMIT. COMMIT RETAINING causes the behaviour you have described and you are quite right to be concerned about its sins with regard to garbage collection...

./heLen