Thank you very much for your responses - this makes sense. We have a couple of server side applications that run constantly. Although, they should all be closing their connections. We will investigate further.

Could this somehow be related to the .NET driver with connection pooling? The one application that I suspect starts and commits small incremental transactions, but uses connection pooling?

Regards,

--- In firebird-support@yahoogroups.com, Svein Erling Tysvær <svein.erling.tysvaer@...> wrote:
>
> >I have 20+ databases in production, most of them between 3 and 8GB with no BLOBs. My problem seems to be that
> >sweeping is not executing when I either perform a full backup or doing full table scans. Below is the gstat
> >header info and as you can clearly see that it should have kicked in long ago. We are running classic mode V2.5.
> >Can I see and output/error messages for sweeping?
> >
> >What are we overlooking? Our only current solution is to do a full backup and restore at silly morning hours,
> >otherwise the system grows terribly slow due to garbage not being collected.
> >
> >Oldest transaction 460
> >Oldest active 461
> >Oldest snapshot 461
> >Next transaction 50325450
>
> You are overlooking that oldest transaction and oldest active transaction aren't moving. That means that Firebird must keep all changes done since transaction 460 or 461 started since old versions could still contain data visible to those old transactions. Another way to say this, is that you have one or more programs that do not take proper care of one or more transactions and this is the reason for your slowness. Sweeping could only sweep the first 460 records of your database, the rest cannot be swept until one or many of your transactions commit or rollback.
>
> Set
>