> Yes, that is already part of the design and has been for some time.

Well then the design doesn't function. In my little example, only
one table receives an update and all other tables refresh on the
rollback.

You want me to puzzle it apart ?

=============================================================

Jason Wharton wrote:

>
> > 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
>
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/