At 02:06 PM 12/12/2003 +0800, you wrote:

>Thanks Helen. May I ask a few more question?
>
>The following you mention above is to cancel only the current selected
>row, right?
>
> > To cancel all work in the transaction that is posted but not committed,
> > call ib_transaction.rollback, or use CancelAll if you want to keep the
> > transaction.

No, it will cancel all uncommitted work in the transaction and revert the
changed rows to their state before any updates occurred in the buffer.

> >
> > Helen
>
>What is the difference then between rollbackretaining and cancelall?

Rollbackretaining actually performs a rollback, thus ending the transaction
and starting a new one with the original context. Cancelall doesn't do a
rollback, so the transaction stays open. I'm not certain how Jason does
that - I think he probably picks up all of the pending-for-commit changes
and issues another update to bring them back to their OLD_ values. What's
the difference in usage? I don't know, really; if he does the CancelAll
the way I think he does, I dislike it, because it adds extra recordversions
to the garbage pile.

> >
>Why is it that I have read about not to use cacheupdate anymore in IBO?
>Is it the cacheupdate in IBO has some problem?

Mostly it's not needed; and it's very "anti-client-server" to detach a big
pile of records from the time-frame of an ordinary transaction and keep the
server uninformed of possible changes. IMO it has its greatest use in BDE
apps, which can't have multiple tasks going on in the application
simultaneously. In client/server, though, I want to keep clear of cached
operations that might continue for hours. I don't want to have users to
have to deal with conflicts that would have been avoided with an on-line
dataset.

Gotta do some proper work now.

HB