Ambiguity in file handling from Digest, Vol 157, Issue 23

[John Angelico]

On 14/04/16 21:56, gnucash-user-request at gnucash.org wrote:
> No, though I see a possible ambiguity.
>
>> >
>> >First, "As Colin already writes" the database backend will write each change
>> >immediately, not at the end of the session.
>> >
>> >Then "the other part of Colin's reply is also correct" gnucash reads the
>> >entire database into memory, and works there until the end of the session,
>> >leading to the risk of data conflicts and corruption.
> Gnucash does work in memory*and*  it writes out changes to the db as
> they are entered.  The working is still in memory.  The key point is
> that it does not see any changes made by other users (if that were
> allowed), which could mean that the changes it later writes back could
> make the db inconsistent.
>
>> >
>> >Is there already a difference between the file handling under XML vs SQL?
> Yes, as described, when it comes to the saving algorithm
>
> Colin
>

Thanks Colin.

Ambiguity resolved, but the risk of data corruption or loss by 
overwriting should only occur if multiple users of one set of data files 
forget that fact.

So when GC asks later users to confirm opening the files despite the 
lock file being in place, they respond incorrectly to open them for 
writing anyway. Thus the problem is one of user discipline.

However, it remains true that if GC used a DB backend with the relevant 
features, data clashes could be reduced or eliminated.

Regards,
John Angelico
talldad