> I have 3 points here:
> 1) The previous Commit was an Edit, so IBO must have the latest
> data in its buffers. Hence, no refresh is necessary.
> 2) To me, transaction events (commit/rollback/etc.) should be
> independent events. Why does IBO hold previous state information
> between transaction events?
> 3) If IBO is unsure of its data after the Rollback, why doesn't
> it do it everytime? (regardless of whether a Commit has been done
> previously).

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.)

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.)

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.

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't think of another way to do what I want. All I want is
> to close all open child datasets if the user scrolls the main
> customer grid. If you can help me with another algorithm, I'm all
> ears (as Ross Perot said!).

Ahhh, a grid. The bane of a programmers lot.

Here is some code attached to a TIB_DataSource OnDataChange
event...

procedure TForm1.DLOnDataChange(Sender: TIB_DataLink;
ADataSource: TIB_DataSource; AField: TIB_Column);
begin
if Sender.Dataset.Fields.IsRowNumChanged then
// do what I have to do when the row changes
end;

The IsRowNumChanged property is used to determine whether the event
is the result of a row change (or if false its just a field value
change on the current row).

There were some issues with IsRowNumChanged at some point, but I
believe they were resolved.

The possible problem with this from your perspective is that it
comes after the fact - whereas you seem to be wanting to do it
before the row actually changes, which I guess makes some sort of
sense but I am concerned about inserting such dataset state changing
code (effecting related datasets) into the dataset event processing.



What I do with my applications is have an outer tab-page in which
the tabs are not visible. One page shows the (readonly) grid that
the users can use to display and select a particular row. As a
result of a double-click, enter or F4 (open) command the page
changes to the "detail view" of the selected record. This detail
view often has internal tabpages etc showing all the child data.

In the detail view the users can still scroll through the records
using navigation buttons provided, its just that they cannot scroll
by clicking on the grid.

As you can imagine this removes a lot of the complication and puts
the program in control of the order of events. Such an interface
would also give your application the ideal events in which to
perform the various open/close processing.


The only other scenario I can imagine is code attached to the grid
OnCellClick event in which you check to see if the row is about to
change.


HTH

--
Geoff Worboys
Telesis Computing