Bug: Transaction is Committed instead of Rollback'ed
Derek Atkins
warlord@MIT.EDU
14 Mar 2001 18:14:19 -0500
Dave Peticolas <dave@krondo.com> writes:
> Derek Atkins writes:
> > The more I delve into this, the more I find. What's going on is that
> > the register winds up calling SplitLedger.c:LedgerTraverse(). It
> > winds up, at the bottom of the function, following the path of
> > GNC_VERIFY_NO. For some reason this never winds up calling
> > RollbackEdit(), as far as I can tell.
> >
> > Anyways, the 'No' path winds up breaking out and returning 'FALSE',
> > which is the same thing that 'Yes' returns.
>
> Yes but first the 'No' path calls xaccSRCancelCursorTransChanges
> which may call xaccTransRollbackEdit if needed. Note that a rollback
> is not always needed. The register doesn't actually change the
> transaction unless you record or edit multiple lines. Is that
> the case here?
No, this is not the case. I was just making a change in the register.
However, it still shouldn't call TransCommitEdit() anyways.
> dave
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available