AUDIT: r23164 - gnucash/trunk/src/engine - Bug 684670 - Interest amount calculation is wrong in Sqllite3 format

[Wm Tarr]

On 17/09/2013 14:59, John Ralls wrote:
> On Sep 17, 2013, at 12:14 AM, Wm Tarr <wm.tarr at gmail.com> wrote:
>
>> On 13/09/2013 15:11, Derek Atkins wrote:
>>> John Ralls <jralls at code.gnucash.org> writes:
>>>
>>>> Yet another corner where forgetting to run a edit-commit cycle when
>>>> changing state breaks database save.
>>> And people wonder why I still recommend against using the SQL backend
>>> for real data..  ;)
>>>
>>> -derek
>>>
>> Would someone be kind enough to point out the beginning of this thread?  TIA
> The beginning of this thread is a change-mail from gnucash-patches or gnucash-changes. You can subscribe to one of those lists if you want to track all of the changes committed to the repository.
>
> Since you're not already subscribed--otherwise you'd know--you can see the change in question at [1].
>> There is no reason why the SQL back-end should be failing other than someone didn't code something correctly, surely?
>
> Well, yes. That's what bugs are all about, right?
>
> The fundamental problem with the SQL backend is that while Gnucash has a facility for marking changed data structures as needing to be saved ("dirty"), the XML backend just uses it to light up the save button in the toolbar. An actual save saves *all* state to a new file, so as long as *something* gets marked dirty, everything's fine. The SQL backend doesn't work that way, of course: That's not how you use databases. Only objects marked dirty get updated in the database. Over the years, we were not as disciplined as we should have been about making sure that every object got marked dirty when changing its state.
OK; minor comment I see there was discussion over in gnc-user about 
multiuser gnc and how easy / difficult it might be.  Ho hum.
> Some of those problems have been noticed and reported like the bug [2] I fixed with r23164; others haven't. Fixing that is my project for the next few weeks. I'd like to have the SQL backend working fully for 2.6.0.
Thanks for the refs.  I have been using the SQLite b/e (main personal 
type accounts not business) for some years without problems so could do 
some testing separate to my own install.   Reason I enquired is that I 
am setting up gnc for a charity / non-profit that does have business 
accounts and I don't want to set them on the wrong path as this is their 
first exploration outside of spreadsheets.  I'll set them on the xml 
path for now as they are used to spreadsheets and documents being saved 
occasionally.

See my project post here, I am pissed off with gnc's imports, next 
instalment soon, don't reply to this line :)
-- 
Wm