Client--Server Implementation Model.

[Mike or Penny Novack]

I'm going to jump in here.

Need to first take a closer look at the "business need" before jumping 
to "simultaneous access". The latter would "solve" the perceived need 
but in a way that may not be really appropriate. Let me explain.

As businesses grow larger, transaction handling tends to become 
specialized. Might have an "accounts receivable" clerk who handles those 
transactions, sales clerks who enter that kind of transactions, etc. 
Normally you DON'T want people to be able to enter transactions of a 
sort not their area of responsibility, though of course a single person 
might be wearing more than one of these "hats". Using "simultaneous 
multiple access" would allow everybody to enter their assigned sorts of 
transactions to the main books BUT it would also permit them to enter 
unauthorized sorts of transactions.

In really large systems this is handled by "feeds" to "general ledger". 
That might be the model we should consider. Not multiple simultaneous 
access to the main books but some way by which data might be moved from 
subsidiary (specialized) books to the main books and THAT doesn't 
require simultaneous access as can be a "batch" process. And yes, right 
now Gnucash would support "subsidiary books" (books that represent only 
a portion of the business). What we don't have is any way to automate 
"feeds" and transfers between these books. All well and good to have 
that a manual process when you are talking about once a month 
transactions between "petty cash" and "general ledger" with likely only 
a few accounts affected. Another thing were that A/R to general ledger 
on a daily basis with scads of customer accounts involved.

Understand what I am saying? Were I the owner of a medium size business 
I probably wouldn't want the employees entering A/R or sales 
transactions to be able to even SEE the main books. Just their part of them.

Michael D. Novack