Hi Nico,

> As OAT was able to move forward and a
> sweep did cure the problem, I guess there was either a largish
> transaction, which was rolled back (and the engine wasn't able to
> transform that into a commit).
>
> Hi Thomas,
>
> Thanks for the fast reply. So if I understand it well, it could be there was a large update running and the client killed the application through the task manager ? Or something like that.

Not necessarily killed. A regular rollback counts here as well.

> I guess there is nothing much I can do about it ?

Running a scheduled sweep every night, e.g. when there is low load with
nearly zero connections, thus sweep can do it's job best.


But could that large gap between transactionnumbers be the reason of a
performance drop ?

> One more thing : is it a bad thing example : 10 users each of them several forms opened with lets say 20 readonly queries per user open. That's 10 users * 20 queries, results in 200 opened queries. Is that having influence on FB performance, knowing that these queries are all readonly. I guess the server has to keep a cursor open for each query ?

Firebird's performance won't suffer from long-running *read only*, *read
committed* transactions. AFAIR starting with FB 2.0.


--
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com
My blog:
http://blog.upscene.com/thomas/