Note, this can only work this way with IB 6 and higher (All FB versions)
because there was no server-level rollback retaining until recently. All
datasets were required to refresh because all the cursors were removed when
doing a hard rollback. I was merely emulating a rollback retaining before.

Hope this clarifies where some of our confusion may have arisen from.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Jason Wharton" <jwharton@...>
To: <IBObjects@yahoogroups.com>
Sent: Monday, February 25, 2002 4:53 PM
Subject: Re: [IBO] TIBOTable Access Violations when Using set ranges


> > I have investigated it and we discussed this issue some
> > eight months ago. One way or another a stamp has to be
> > associated with the TIBOQueries indicating last time an
> > table UPDATE was issued since the start of a TRANSACTION,
> > this flag to be checked on a ROLLBACK forcing a (SQL) REFRESH
> > or not and to be reset after either a ROLLBACK or COMMIT.
>
> Like I said, that is what it is doing. There is a flag that gets set when
an
> update takes place. Only those datasets are to be affected when a rollback
> occurs.
>
> > I know it still won't be absolute perfect, but probably
> > quite a bit better than waiting for all open TIBOQueries
> > to ROLLBACK and refreshing their SQL Queries.
>
> Yes, that is already part of the design and has been for some time.
>
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com