In message #64294, Ann W. Harrison wrote:

>Gstat counts all records in the database, including those that are
>marked as deleted but have not yet been removed. Records that are
>marked as deleted are not actually removed until after the end of all
>transactions that started before the delete was committed.
>
>Even when that condition is meet, the record is only garbage
>collected when some transaction tries to read it, so gstat may be
>counting records that are awaiting garbage collection.

Can anyone help explain the "Even when this condition ..." part?
Why would my application ever try to read a record it has deleted?

Because, I have a similar problem where the database file grows
constantly. The application does a lot of record deletes. I'm
using the native Firebird C interfaces in my application.

I "fixed" the application by adding an SQL query after every 100
deletions. A simple query "select * from mytable" seems to do the
trick.

Although I have a workaround, I'd like to understand this issue
better, and I wonder if there is a better way?

Here's gstat output after a test run where the database grew through
out the test cycle. When I run the same test with the "fixed"
application, the database file grows to a fixed size and stays
there.

Database header page information:
Flags 0
Checksum 12345
Generation 50041
Page size 4096
ODS version 10.0
Oldest transaction 50036
Oldest active 50037
Oldest snapshot 50037
Next transaction 50038

Thanks.