> --- In firebird-support@yahoogroups.com, Lucas Franzen <luc@...> wrote:
> >
> > Michael,
> >
> > > So all in all (based on 1 day of observation ;-) ) I think the sweep
> > > did take a lot of res. and memory.
> >
> > Seems that you found the problem.
> > Good.
>
> Indeed it was ...
>
>
> >
> > > Another thing I tried (on a diff. DB, a smaller customer) was forcing
> > > a disconnect from the DB and a connect to the DB every once in a
> while.
> > > This customer now has a gab between 50 and 400. Usually it was
> > > somewhere between 500 and 6000.
> > >
> > > I think I'll try that on this big customer DB as well.
> > >
> > > Anywas with any comments on this ?
> >
> > Yes.
> > Try to find out which transaction(s) is (are) running that long without
> > being committed and try to change this.
> > Don't use SavePoints or CommitRetaining if there's a chance to use
> commit.
> >
> > I would prefer this one over disconnecting and reconnecting to the
> db ...
>
> I would to.
> I suspect, that somewhere I have a long running query.
> But I also know, that some of the users have a bad habbit of starting
> something and then leave the machine for quite some time.
> I'm still not sure how to solve this easy ...
>
> MIhcael

I have a timer. It gets reset every time they save. If they leave it past
the e.g. 5 minute default setting, the save button action is fired for them.
I have to admin that with IBO, this is a no brainer since IBO permits this
with next to no noticeable change in the users' interface. all records are
still resting on the currently selected record.
It was impossible to achieve this with IBX components since IBX does not
manage the clientside buffers well. You had to write a lot of code to ensure
all datasets, after commit and re-open, returned to their previous record.
The TGrid, however, never returns to a record mid stream. It always brings
the record back to the top of the grid. very noticeable for users and
annoying.
Alan