--- In IBObjects@y..., Geoff Worboys <geoff@t...> wrote:

>
> The point is that a commit does a post.
>
> When you do a rollback without a prior post IBO is able to just
> return to its bufferred old values. When a post has been done
> previously IBO has no way of knowing whether there was one or
> many posts performed. Which ones were commitretained, which ones
> were not. So it cant be sure that its current "old" buffer values
> are valid or not. (ie. The transaction event is largely
> independent of the post, and because of this IBO can no longer
> certain of the validity of its buffers.)

I can appreciate that there is a beehive of activity going on under
the IBO covers (and I would love to spend the time to fully
understand it), but the fact is that regardless of the work that IBO
has to do to refresh its buffers, this is not a Scroll. Call it
a 'row refresh' or a 'buffer refresh' or anything else, but it is not
a Scroll and should not fire the Scroll events. As you say below, I
can use BufferSynchroFlags or even DML caching to programmatically
control the refreshing of data, so this refreshing should be
independent of the Scroll events. Simply... a Scroll should mean that
the rowNum has changed.

> In addition to all that there is the fact that when a row has
> been posted its data may or may not be remain consistent with
> the values at the server (since triggers can alter any value).
> (This is what the BufferSynchroFlags options are about.)

To solve my problems, would it be worthwhile to have a
Before/AfterRowRefresh Event on the TIB_Query which would be fired on
a refresh and the Scroll events would then only fire on a rowNum
change?

> Add to that is the fact that, regardless of the BufferSynchroFlags,
> sometimes IBO is forced to refresh records after post anyway - when
> they contain blobs or arrays - in order to get server applied
> changes to the blob/array id.

I have no problems with a refresh after a Post.

> As you can see the whole mess gets rather complicated, and it is
> not always obvious just what is necessary and what is not.

I can appreciate that. But it is extremely important that Events
are based on a very specific database activity and not used as
a 'default' handler for a broad range of database functions.