Data consistency after program crashes

John Ralls jralls at ceridwen.us
Wed Aug 29 19:29:02 EDT 2012


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




More information about the gnucash-user mailing list