Data consistency after program crashes

[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