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