QFX import problems
Derek Atkins
warlord at MIT.EDU
Thu Aug 5 23:24:06 EDT 2004
Benoit Grégoire <bock at step.polymtl.ca> writes:
> Well, there is already code in the importer that, at the very end, either
> commits every transactions still flagged to be imported, and deletes (and
> commits) every other. Trouble is the engine doesn't handle (well, so I was
> told) reverts cleanly enough to change it to commit transactions to be
> imported, revert others.
What does it mean to "Rollback" a transaction that you're "importing"?
It's not supposed to have hit the CoA yet, so there's nothing to
revert. You definitely want to "destroy" at this point..
But a better approach is to not even allocate the transaction until
after the user hits ok.
> Well, you don't need an "undo import". You necessarly still have pointers to
> every transactions untill the very end of the import process. As long as you
> didn't commit, you can revert objects individually by walking the list.
> That's already what the code does to do the commits.
Yes, but what if the user decides they didn't want to import it after
they clicked "OK"? Perhaps we just don't care, but I've certainly
performed many tests where I perform the import and then exit without
saving. Once we have the SQL backend I wont be able to do that
anymore, so I'd like an "undo".
> Maybe one day I'll have time to look into this. At worst, there's only few
> decades left till retirement ;)
Hehe..
> Benoit Grégoire, http://benoitg.coeus.ca/
-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 at MIT.EDU PGP key available
More information about the gnucash-devel
mailing list