cmd line: import of transactions and invoice data

Emmanuel Florent emmanuel.florent at
Wed Jan 1 05:04:40 EST 2014

First of all I wish to the Gnucash community a very good year 2014, could
it be just as it ended the previous year: brilliant !

Secondly a big applause for latest release !

So here is my solution, a wrapper:
-load xml from "somewhere",
-open gnucash,
-do work
-close gnucash
-save Gc xml to db.

Somewhere could have be:
-a shared network directory, but, if networking problems can be solved,
concurrent access problem remain and so it would not be multi-users
-a content revision system (think CVS or bzr, ...) but the xml may not be
sorted so problems ...
-a noslq db where db key should match gnucash's guid, What do you think of
that approach, seems not so bad for me to make an initial implementation.

PS: Does someone have a real example GC file a little bit big to see how it
works in real situation and to help me further dev ?


2013/12/31 John Ralls <jralls at>

> On Dec 31, 2013, at 1:15 PM, Jannick < at> wrote:
> > John Ralls <jralls <at>> writes:
> >
> >> It updates the database after any change to the in-memory data. At
> least we
> >> think it does, but we don’t yet have complete test coverage to be sure
> that
> >> we haven’t missed something in our audits.
> >
> > John,
> >
> > this is very helpful.
> >
> > There might be two options: Either the whole db is updated or the changes
> > only [Rereading the posting: only changed tables are updated - at most].
> >
> > The first one might give rise to an issue when more than one user updates
> > the mySQL db at the same time. But good either way I believe if there is
> > just one user having access to the mySQL db for a period of time. If the
> > whole GC db is - or updated GC tables as a whole are - passed on to
> mySQL,
> > then the data integrity feature built into GC can be used and need not be
> > mirrored in mySQL. Point taken!
> >
> >>>
> >>>> However, GnuCash DOES NOT support you writing to the database behind
> it.
> >>>> To write the DB you *MUST* use the GnuCash API (in C, Scheme, or
> Python).
> >>>
> >>> This *is* a very good point. For the benefit of my better
> understanding:
> >>> Given my first guess above is correct, then how does GC work when it
> comes
> >>> to manually input data or insert it via the AqBanking interface
> (HBCI)? What
> >>> does it do when information are handed in?
> >>
> >> It parses the incoming stream and converts it to internal data
> structures,
> > prompting
> >> the user via a dialog box to assign the accounts for each side of the
> > transactions,
> >> then runs data-integrity routines on each transaction to ensure that the
> > transaction
> >> balances, creating an imbalance-account-split if it doesn’t. If you’re
> > using the SQL
> >> backend it updates the various affected tables immediately, otherwise it
> > sets the
> >> book dirty flag.
> >
> > Ahh, then the number of updated tables is reduced to the minimum after
> the
> > GC data-integrity test for the whole in-memory GC db. And - as far as I
> > understand - the *whole* updated tables are passed on to mySQL, right?
> >
> > Just two more FUP questions:
> > 1 - What happens if GC comes across a db which fails the data-integrity
> > tests (because, e.g., it was updated outside the house)? Is GC able to
> cope
> > with this still displaying the db to the GC user?
> > 2 - I am a little tiny Win7 user (no "building" skills etc). Are there
> any
> > code pieces to read to understand how the various steps are applied to
> > imported transactions? Anything on the GC server?
> No, only the structures “marked dirty” and passed through a commit routine
> when changed are updated via SQL.
> GnuCash has a lock record in the database so that only one GnuCash
> instance can
> open it at a time. It doesn’t use the database-locking facility, so any
> non-GnuCash
> process could access the database. Since GnuCash only reads the database
> once, when
> it opens it, this would create obvious problems.
> GnuCash doesn’t have much in the way of data integrity checks; if a
> foreign key is
> invalid, it will usually just drop the transaction with the bad key, but
> in some
> circumstances it may crash. The former case would result in silent data
> loss, the
> second would obviously render the database unusable. Since GnuCash doesn’t
> use
> any checkpointing features nor does it make any sort of backup with the
> SQL backend,
> you’d have to rely on having some other sort of database backup that you
> could reload
> to recover any of the data at all.
> Neither the SQL backend nor the importers are well documented, so unless
> you can
> read C source code you’re not likely to be able to replicate the function
> of GnuCash’s
> internals.
> Regards,
> John Ralls
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

More information about the gnucash-devel mailing list