Subject | Re: [IBO] cancelling the edits in detail table on master detail setup |
---|---|
Author | Helen Borrie |
Post date | 2003-12-12T06:28:23Z |
At 02:06 PM 12/12/2003 +0800, you wrote:
changed rows to their state before any updates occurred in the buffer.
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.
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
>Thanks Helen. May I ask a few more question?No, it will cancel all uncommitted work in the transaction and revert the
>
>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.
changed rows to their state before any updates occurred in the buffer.
> >Rollbackretaining actually performs a rollback, thus ending the transaction
> > Helen
>
>What is the difference then between rollbackretaining and cancelall?
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.
> >Mostly it's not needed; and it's very "anti-client-server" to detach a big
>Why is it that I have read about not to use cacheupdate anymore in IBO?
>Is it the cacheupdate in IBO has some problem?
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