Database locked after crash - python bindings

[John Ralls]

On Nov 6, 2010, at 5:07 AM, Mike Evans wrote:

> On Saturday November 6 2010 10:50:53 Christoph Holtermann wrote:
>> Hello !
>> 
>>> With regard to Python bindings: The error (7,) is the same if you try to
>>> open a locked xml file.
>> 
>> Is there a description of possible error codes somewhere (in the bindings
>> source for example) ? The latter seem on a auick glance just to pass them
>> through.
>> Are the exceptions coming from the c-code and then translated to python, so
>> that I would find them in the gnucash-c-source ?
> Looking at src/optional/python-bindings/gnucash_core.c most of the exceptions 
> are dealt with; except for this one.   The function at line 14119 does indeed 
> appear to just pass the error through.  I'm not up to the task of doing 
> anything about it though.
>> 
>>> I'd think the python script would need to be amended to
>>> trap the error and ask the user whether to continue or not.  There'd then
>>> need to be some SQL to remove the lock.  It would seem to be correct
>>> behaviour to stop on encountering a locked database.
>> 
>> Would that be an external call - like yesterday I just wrote a "script"
>> echo "TRUNCATE GNCLOCK;" | mysql -u XXX --password=XXX gnucash - or is
>> there or would it be useful to have a python function that does that via
>> gnucash - taken that there is a function which handles that situation in
>> the source ? The latter would be the code that is called by that dialogue
>> which is opened by gnucash and asks you to force open. To put it in other
>> words : Can that c-code be called by python ? For to me it seems more
>> elegant to not have "external" calls from my skript but to have all
>> commands running through the python-bindings.
> I agree, it can be done by manipulating the database directly but via GnuCash 
> would be better.
> 
> The bindings are maintained by Mark Jenkins, perhaps a bug needs to be opened 
> if this is an issue?  


The "right" way to do this is to call qof_session_begin( session, book, FALSE, TRUE) the first time,
and if you get a QOF_ERROR_LOCKED and want to break the lock, call qof_session_begin( session, book, TRUE, FALSE). It's very risky indeed for any external code to muck around underneath libqof: The architecture of libqof is a bit byzantine, and all of the data checking and referential integrity (referential everything, in fact) are implemented in the engine, not in the backends, so you need qof to retrieve the data, run it through the engine, and present it to your code.

Note that the doxygen documentation needs some work; a lot of the documentation is reachable only from the files tab, not from Modules. That includes qofsession.

Regards,
John Ralls