On 21 May 2010, at 6:04 PM, Derek Atkins wrote:
Because a situation arises when both of you need to make writes.
Which
copy is the authoritative copy? Using svn alleviates this somewhat,
but isn't ideal.
The authoritative copy belongs to whomever has the write token.
Otherwise known as
Graham Leggett minf...@sharp.fm writes:
Why not?
Because a situation arises when both of you need to make writes. Which
copy is the authoritative copy? Using svn alleviates this somewhat,
but isn't ideal.
The authoritative copy belongs to whomever has the write token.
It is really easy to
z33...@gmail.com writes:
I think I understand at least some of the reasons for GC being single-user,
but I'm curious if there's been any more thought lately to building
multi-user functionality into GnuCash in future?
I believe there is an unstated goal of getting minimal multi-user
support
Graham Leggett minf...@sharp.fm writes:
On 19 May 2010, at 11:47 PM, Per Kjeldaas wrote:
Your solution to block the whole database is good enough for me.
It's a real shame that a system fundamentally designed to offer multi
user access to data should be crippled in such a fashion. In the
Valdis Vītoliņš valdis.vitol...@odo.lv writes:
I vote for not over-engineered solution and, I suppose simple lock for
all database (only one can write) is OK.
My clients/partners will not use SQL backend. They use Gnucash because
it can be installed and used as many other standalone
On 20 May 2010, at 6:32 PM, Derek Atkins wrote:
Your solution to block the whole database is good enough for me.
It's a real shame that a system fundamentally designed to offer multi
user access to data should be crippled in such a fashion. In the
process, virtually all reasons to use a SQL
Graham Leggett minf...@sharp.fm writes:
On 20 May 2010, at 6:32 PM, Derek Atkins wrote:
Your solution to block the whole database is good enough for me.
It's a real shame that a system fundamentally designed to offer multi
user access to data should be crippled in such a fashion. In the
On 20 May 2010, at 6:55 PM, Derek Atkins wrote:
Well, over time one would hope that we can slowly rearchitect
gnucash to
be more aware of multi-user situations.
I'm keen to do some of that work, as I need it directly.
In any practical usage, even in it's simplest form, you start off
small
Thanks, Herbert, for the link.
The article raises one valid serious concern: The database backend
does nothing to prevent multiple user access. This is bad because
simultaneous access to the SQL database from multiple users will
almost surely cause data loss. On the other hand, the
I think I understand at least some of the reasons for GC being single-user,
but I'm curious if there's been any more thought lately to building
multi-user functionality into GnuCash in future?
Cheers,
-- Erik Anderson
On Wed, May 19, 2010 at 1:58 AM, Christian Stimming stimm...@tuhh.dewrote:
I think there is a big difference between concurrent multi use and serial multi
use. I would like to be able to use GnuCash with the same remote database, but
from different computers at different times. This would be serial multi use.
The system should ideally protect against any use that
On Wed, May 19, 2010 at 6:58 PM, Christian Stimming stimm...@tuhh.de wrote:
The article raises one valid serious concern: The database backend does
nothing to prevent multiple user access. This is bad because simultaneous
access to the SQL database from multiple users will almost surely cause
I vote for not over-engineered solution and, I suppose simple lock for
all database (only one can write) is OK.
My clients/partners will not use SQL backend. They use Gnucash because
it can be installed and used as many other standalone applications.
It is important, that Gnucash save data in
Tao,
Your solution to block the whole database is good enough for me.
Thanks,
Per.
On May 19, 2010, at 2:26 PM, Tao Wang wrote:
On Wed, May 19, 2010 at 6:58 PM, Christian Stimming stimm...@tuhh.de wrote:
The article raises one valid serious concern: The database backend does
nothing to
On 19 May 2010, at 11:47 PM, Per Kjeldaas wrote:
Your solution to block the whole database is good enough for me.
It's a real shame that a system fundamentally designed to offer multi
user access to data should be crippled in such a fashion. In the
process, virtually all reasons to use a
15 matches
Mail list logo
