[GNC] Database storage

[Mark at Lorimark]

~mark petryk
~w:http://www.lorimarksolutions.com

On 9/19/24 11:27, Chris Miller via gnucash-user wrote:
> Hi Roberts,
> 
>      * Transactional database updates implies multiple user concurrency, but everywhere I hear that multiple users is "problematic". Certainly this is true with the XML storage because the file is single-use locked, so less "problematic" than "impossible". (-: But is it still true with SQLite?

*guessing a little* I think the issue with SQLITE is that while updates 
~can~ be written to the SQL file throughout the user experience, and 
another instance of gnucash ~can~ simultaneously open that same file, 
the 'issue' is because that 2nd instance of gnucash accessing the same 
file would "not be aware" of updates that are written to the file from 
the 1st instance.

It would be a little similar if you were to open a .txt file with 
notepad, and have your cohort open that same file.  While you both can 
see the file, and you both can even change it, and even save it, what 
you don't get is notification that someone else updated the file while 
you had it open.  You'd have to close it, and re-open it to see their 
changes.

 From the SQL perspective, special effort has to be made in the 
application to constantly monitor the database underneath.

Also, SQLITE suffers from "two users opening a file" but that is 
somewhat manageable.


>      * If SQLite is supporting transactions, and I then have to assume SQLite is "talking" SQL, then what is the complexity with doing the same for other back-end databases?

It's hard to tell which 'transactions' we're talking about here. 
Database 'servers' support transactions, whereby you can queue up a 
bunch of SQL commands and wrap them in a 'transaction' and if any one of 
those SQL steps fails the whole transaction will fail.

But, of course, 'transactions' within GnuCash is just the concept of 
'financial transactions'.


> 
> Thanks for the help,