Bug: Transaction is Committed instead of Rollback'ed

Dave Peticolas dave@krondo.com
Wed, 14 Mar 2001 15:15:46 -0800


Derek Atkins writes:
> 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.

Can you give me some more details about how you got TransCommitEdit to
be called? Specific key/mouse strokes and register cells would be
helpful because I haven't been able to reproduce it.

thanks,
dave