Data consistency after program crashes

Mark msalists at gmx.net
Fri Aug 31 17:38:50 EDT 2012


Hi Derek,

is the OFX importer the same as the HBCI importer?

Thanks,

Mark


Am 31.08.2012 23:22, schrieb Derek Atkins:
> Unfortunately that *is* possible with the OFX importer because of the way
> it uses real transaction objects for the to-be-imported data.  It's
> unclear how safe it is.  I don't think it's ever been fully tested.
>
> -derek
>
> On Fri, August 31, 2012 5:14 pm, Mark wrote:
>> Hi John,
>>
>> I really only care about integrity of the financial data. If the
>> Bayesian account matching data is not updated, that's fine.
>> If not all transactions are downloaded, I can just redo the download and
>> GnuCash would show me which ones made it and which ones are missing; so
>> that's not that bad either.
>> What would be bad is if transactions are stored "halfway" or similar
>> things, which would mean that the core financials get corrupted.
>> But it sounds like that is very unlikely...
>>
>> Thanks,
>>
>> Mark
>>
>>
>> Am 30.08.2012 01:29, schrieb John Ralls:
>>> On Aug 29, 2012, at 1:50 PM, Mark <msalists at gmx.net> wrote:
>>>
>>>> Hello,
>>>>
>>>> is it save to assume that using sqlite data format ensures data
>>>> consistency after program crashes? Are file operations usually running
>>>> within ACID transactions?
>>>> I just downloaded transactions through online banking HBCI and after
>>>> clicking OK on the import wizard, the program took a long time trying
>>>> to finish the import before it finally crashed.
>>>> How save is it to keep using this file vs going back to the last
>>>> backup?
>>> No, it is not safe to assume that. There are still changes which are not
>>> flagged correctly to the SQL backend and not saved correctly. Worse,
>>> data which affects more than one table aren't necessarily contained in
>>> only one transaction, so it's possible to
>>> get part of the data saved.
>>>
>>> That said, ordinary bank transactions *are* properly wrapped, so if one
>>> of your downloaded transactions was saved, the important parts were
>>> saved correctly. What might not have been saved is the KVP for the
>>> Bayesian account matching.  That might mean that you'll have non-matches
>>> or bad matches on some future imports, but that's true anyway. The big
>>> risk in this case, I think, is that only some of the bank transactions
>>> will have gotten imported. There's no harm in reloading the file and
>>> checking it. You were presumably pulling in transactions to reconcile
>>> your account with the bank. If it reconciles with this month, everything
>>> is OK. If it reconciles with last month, the import utterly failed and
>>> you're still OK, you just have to re-run the import. Otherwise you have
>>> to decide which is more work: Cleaning up the partial import by hand or
>>> reverting to a previous backup and re-entering or re-downloading your
>>> work since then.
>>>
>>> Regards,
>>> John Ralls
>>>
>>>
>>
>>
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
>



More information about the gnucash-user mailing list