another multi-user "solution"?

[MisterX]

Dan said...

> Rob....
> 
> Ah, good point. It would appear that there is not a simple 
> way to solve this problem using text files as locking semaphores.
> 
> Back to the ol' drawing board!

I just wrote the solution and you didn't get it or understand me...

In a server-client - the client doesn't touch the database. Only sends
updates to the server to queue up changes. This way, you have no locks, no
problems. Everyone accesses it. You can't do this with stacks - without
damaging them. So you work with a client front-end (or stack replica but
inneficient) that receives (collects) the data you browse and sends the data
you change... 

Data can be send in mini-stacks, text files, sql queries or sockets... 

Oh yes, a server can lock the record for you more reliably than counting on
a client's poor connection to do it... If you lost the connection to the
server when you edit the databse, then what? You corrupt the database
probably (trust me, i do this at work all the time)... The server cannot
lose that connection.

cheers
Xavier

> On Apr 25, 2005, at 11:59 AM, Rob Cozens wrote:
> 
> > Hi Dan,
> >
> >> Second, using the semaphore file approach that Jacque suggested is 
> >> eminently doable and quite simple to implement. It would be pretty 
> >> easy, e.g., to have a single file that just contained a 
> list of all 
> >> the card numbers currently open for editing and checking it before 
> >> allowing a user to edit a card's contents. Equally easy 
> and perhaps a 
> >> little better from a robustness perspective would be to 
> create a text 
> >> file called, e.g., card.lok, where card is the name or ID of the 
> >> card, for a card when it's opened for editing and then 
> deleting that 
> >> file when the user's done. In either case, a pretty simple command 
> >> could check to ensure the card the user asks to edit isn't already 
> >> being edited and take some appropriate action.
> >
> > Question:
> >
> > How do changes on individual cards in different copies of a 
> stack in 
> > each user's RAM get made to the copy resident on disk?  
> There is not, 
> > to my knowledge, a way to save changes on one card of a 
> stack without 
> > overwriting the entire stack.  So if I open a stack before you, 
> > Jacque, and Kurt do, wait until you all close the stack, 
> and then save 
> > it, the only changes to the original stack will be mine.  
> You need to 
> > take it the extra step the Rob Eppich took EPSI-Talk, and have each 
> > users' copy of the stack updated whenever anyone else makes 
> a change.
> > This was more feasible in HyperTalk than Transcript, me thinks.
> >
> > One advantage of a client-server design is record locking 
> tables can 
> > reside in the server's RAM; so no disk files are necessary and all 
> > records are automatically unlocked when the server shuts down.
> >
> > Rob Cozens CCW
> > Serendipity Software Company
> >
> > "And I, which was two fooles, do so grow three;  Who are a little 
> > wise, the best fooles bee."
> >
> >  from "The Triple Foole" by John Donne (1572-1631) 
> > _______________________________________________
> > use-revolution mailing list
> > use-revolution at lists.runrev.com
> > http://lists.runrev.com/mailman/listinfo/use-revolution
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Shafer, Co-Chair
> RevConWest '05
> June 17-18, 2005, Monterey, California
> http://www.altuit.com/webs/altuit/RevConWest
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>