On 11/24/21 07:54, Chris Green wrote:
On Wed, Nov 24, 2021 at 11:24:21AM -0400, Chris Mitchell wrote:
Hi all,
For reasons that are complicated but not especially interesting, I
would like to run Gnucash on one machine, with the data file located on
a remote machine — with the added challenge that the network access
available to the Gnucash "client" machine is a terrible cellular data
connection that sometimes drops without warning.
I have daily backups, so I don't need strong guarantees against data
loss, but if it's possible, I'd like to set things up so there's
reasonable resilience against a network dropout corrupting the remote
Gnucash data. I'm not the only user with access to the data, so (given
that multi-user is still a long way off), I need file locking to work.
Having to manually delete an orphaned lock file after a network dropout
is acceptable.
I assume that any of the database server backends would include this
kind of resilience "out of the box", and I'm not entirely unwilling to
try my hand at setting that up, but I am by no means a qualified
database administrator. If I can get sufficient resilience by easier
means, I'd prefer to stay away from the whole database server thing.
What about Sqlite over sshfs? I realize Sqlite is not designed for
access to a database residing on a different machine, but my inexpert
impression is that its "atomic commit" implementation should protect
against sudden disconnection between the program and the storage medium
just like it protects against sudden power loss. (IE the transaction
that's in the midst of being written will be lost, but the database
should be fine.)
Can anyone confirm whether it's reasonable to expect that Gnucash with
Sqlite backend over sshfs would have working locking and decent
resilience against data corruption in this scenario? Or point out any
obvious "gotcha" I'm missing?
I think a better approach might be to simply copy the database to the
machine you're working on when you start GnuCash and then copy the
database back again afterwards.
Go so far as to create a script that would check for your own lock file
before making the copy. If lock file not present, then create it and
copy the database. Lock file could be as simple as renaming file with
an extension of "xxx.IhaveIT".
Then the reverse script would remove the lock after copying the updated
file back to the original name.
That way anybody else trying to update the file would know it was
already "checked out".
--
Stephen M Butler, PMP, PSM
[email protected]
[email protected]
253-350-0166
-------------------------------------------
GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
