> -----Original Message-----
> From: Geoff Worboys [mailto:geoff@...]
> Sent: Sábado 17 de Marzo de 2001 8:59
>
> > First I connected all of my queries with mastersource
> > properties but I noticed that posting a detail row will
> > post master row implicitly. So I chained queries by myself
> > now to avoid that.
>
> Just curious, why did you decide to do this? I thought the implicit
> posting of the master dataset was one of our greatest achievements :-)
> It allows a complex structure to be presented to the user as a single
> object, with the automation taking care of the interdependancies
> automatically.

With the master-detail functionality behind scenes taking care of the
interdependencies, maybe you wanted to say, Geoff. Or perhaps I spoiled your
explanation even more.
I agree with you: I set up a master detail and when the detail is going to
do the first post, the master does an implicit post (otherwise, db integrity
would catch you) but it remains on logical edit state. Then I continue
filling the detail table, usually bound to a grid with only a few fields.
Since a transaction is in effect, nobody outside this txn can see the
insertions. When I ask the user to confirm or discard changes and the user
wants to cancel, I don't call master.cancel because it would attempt to do a
delete to compensate for the implicit post and so I would need to either
delete the child's records or rely on cascade deletes. I simply rollback the
transaction. All changes seen by the db will discarded, so why bothering to
avoid the implicit IBO mechanism and reinvent the wheel? Andreas, what's
your point against this IBO facility? After all, if the master and the
detail are using the same txn (this is the only reasonable way IMO), all
records will be ignored if the txn is rolled back. It seems to me that you
finally are doing the same than IBO. Remember, the txn isolates all the
changes.

> > Anyway, after finishing procedure I would like to ask user
> > if transaction should be saved and call CommitRetaining/
> > RollbackRetaining depending on users choice.
>
> My preference is to use Transaction.Refresh(true) for commit and
> Transaction.Refresh(false) for rollback. This way the transaction is
> fully reset. CommitRetaining will retain the existing transaction
> context and so continue to hold up any processing that may be waiting
> on the transaction to end. (RollbackRetaining is an IBO simulation
> and will result is a full transaction reset anyway.)

This was in the Jurassic, Geoff. In the Cretaceous, IB implemented
RollbackRetaining and then IBO followed suit and only simulated things for
IB5 and earlier but now it calls the API for IB6, by detecting the engine
version. (This brings to my mind the issue of server version in Firebird.)
Well, this is what the help file says. It seems that Jason changed his mind
afterwards so either the help or the code should be amended to be in sync:
procedure TIB_Transaction.API_RollbackRetaining;
has the call to the API commented and does the IBO emulation always. What
happened, Jason?

C.