Data consistency after program crashes

Derek Atkins derek at ihtfp.com
Fri Aug 31 18:07:05 EDT 2012


Yes.

-d

On Fri, August 31, 2012 5:38 pm, Mark wrote:
> 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.
>>>
>>
>
>


-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant



More information about the gnucash-user mailing list