[GNC] Using Gnucash to access file over flaky network

Thomas Forrester tlforrester at gmail.com
Wed Nov 24 11:40:21 EST 2021


Or, if the situation allows (perhaps because the only reason to do this in
the first pace is to keep that kind of data off the GnuCash machine), use a
NAS device connected directly to the router your GnuCash machine is
connected to.  It may not be as "remote" as you're doing now, but it's not
on the same machine anyway.


On Wed, Nov 24, 2021 at 9:58 AM Chris Green <cl at isbd.net> 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.
>
> --
> Chris Green
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> 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.
>


-- 
Tom
Thomas L. Forrester
3211 Patty Lane
Middleton, WI 53562-1652 USA
608-831-0769


More information about the gnucash-user mailing list