cmd line: import of transactions and invoice data

John Ralls jralls at
Tue Dec 31 16:42:14 EST 2013

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

John Ralls

More information about the gnucash-devel mailing list