Hi Roberts,
> I found the best of both worlds is to use SQLite backend - because it is
> fastest and most portable - you just need to copy the file. It allows me to
> run quite complex reports from R using standard SQL approach. Even more - I
> made some bash scripts with SQL queries utilizing regexp support, that
> allowed me to quickly get some vital information on terminal - even without
> firing up gnucash.
I had already come to the same conclusion. And I have also already posed
questions to myself:
* Does SQLite support transactions? -- Yes.
* Are transactions implemented? -- Let's assume, "Yes."
So, this raises more questions, on the assumption of transactional database
updates in SQLite.
* 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?
* 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?
I hope I have not strayed into an acrimoniously controversial area, but I would
like to hear the debate.
Thanks for the help,
--
Chris.
V:916.799.9461
F:916.974.0428
A: Because we read from top to bottom, left to right.
Q: > Why should I start my reply below the quoted text?
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
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.
