Again, thank you guys - I've found the issue in a application that started a "read-only" transaction to update some labels on a form and keeping the OAT stuck.

With my luck, I closed the app and froze the poor server, now trying to sweep 7 days worth of transactions from all other tables... ouch - I was not popular. All in all, I made some program changes, the database is back up and running and the OAT seems to be moving forward slowly as it should.

What a great day this is - this has been troubling us for a while now and we could never pin point the problem.

Regards,
Wim

--- In firebird-support@yahoogroups.com, Svein Erling Tysvær <svein.erling.tysvaer@...> wrote:
>
> >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?
>
> A common reason would be using CommitRetaining rather than Commit. Although CommitRetaining can be convenient, it stops the OAT from moving on so you must ascertain that a hard Commit is used occasionally. Connection pooling by itself shouldn't cause your problems, unless there's also some kind of "transaction pooling" (but a transaction can span several connections). Note that the transaction does not have to do any modification to the database, even SELECTs can make the OAT stuck (the one exception is that transactions that are read only AND read committed do not stop the OAT from moving).
>
> Actually, we had a similar (though not related) problem recently, which turned out to be due to having a TIB_Transaction (IB Objects) with AutoCommit, and then in code do 'if TIB_Transaction1.TransactionIsActive then TIB_Transaction1.Commit'. Due to the AutoCommit, TransactionIsActive was false, so no hard Commit was done. AutoCommit did CommitRetaining, so the OAT got stuck until the program terminated. Our users typically start that program in the morning and closes it at the end of the day, so we only had one day of delay. Your gap indicates that your problematic transaction (well, there could be several problematic transactions, you'll find out) was started shortly after the restore, so programs started later than about July 4th are not suspected.
>
> Set
>