syncing two pcs
Mike or Penny Novack
stepbystepfarm at mtdata.com
Sat Aug 16 11:28:47 EDT 2008
>
>This makes it plain that the gnucash database needs to be in a file
>format that can reliably be processed by a revision cotrol system,
>preferably a distributed one, probably a special-purpose one.
>
>All reliable miltoway sync operations need to have, in addition to the
>two files to be merged, a previous version that was the ancestor to
>both. This means either multiple copies of the gnucash database, or
>having the database itself contain its history.
>
>
>
.........
This refers to a very different sort of issue --- not keeping sequential
use of the database in synch but synching concurrent use changes.
Not nearly as simple a matter as you describe. There is nothing to
prevent concurrent users from making incompatible changes (that cannot
be synched by some sort of "version control" -- by which I don't mean
that a version control process can't come up with a "solution" but that
this might not be what EITHER updater of the database intended).
If you are going to have an application that allows concurrent changes
to a database then you need a full blown "database manager". That allows
all users to read the database but only one at a time to update it.
During the moment of the update operation all other users "locked out"
until the operation completes, after which all users "see" the change
made and so cannot accidentally make a chanage incosistent with that --
obviously the second could intentionally undue/upset the other's change
The issues around the logic of "concurrent processing" are really too
complex for a "user" discussion group. Leave this to "pros". In any
case, when the accounting chores become too onerous for one bookkeeper,
what's normal is to segment the work assignenments (so different
bookkeepers aren't handling the same sorts of transactions, only some of
them authorized to make changes affecting the chart of accounts, etc.).
In other words, the problems to which I am alluding would be partially
handled by "work flow" rules preventing inconsistent changes, etc.
More information about the gnucash-user
mailing list