Multi-user strategy

Multi-user strategy

Post by Michael Nuge » Sat, 16 Dec 1995 04:00:00



Hi All;

Although I've been using FPW 2.6 since Feb. of this year (which means I
pretty much have absolutely no idea what I'm doing:-), I have'nt had to
create a multi-user app until now (lucky me:-)  Just wondering if anyone
can point out a good append, edit (etc...) stategy for me to follow.  

For example - to append a record; I know the file has to be locked (but I
can't lock it if someone is editing a record in that file - do I append
to a temp file and add to master file later?)  How about delete?

I have an edit routine that seems to work - when user presses edit the
record locks until it is saved or cancelled <- another user can look at
that record but cannot edit it (message pops up saying someone else is
using it <- is there any way to get the name of the person who is editing
that record so my message can say "miken is editing this record" or
something to that affect <- would I use the GETENV() function?

I've read the manuals on this subject and also articles from FP Advisor
but would appreciate some ideas or other resources to look into.

m.helpme = "TIA" + CHR(10) + "Have a good day!"
Mike

***  The opinions expressed here probably make no sense;->  ***

 
 
 

Multi-user strategy

Post by Darwin Perki » Sat, 16 Dec 1995 04:00:00


Quote:>Just wondering if anyone
> can point out a good append, edit (etc...) stategy for me to follow.  
> For example - to append a record; I know the file has to be locked
(but I
> can't lock it if someone is editing a record in that file - do I
append
> to a temp file and add to master file later?)  How about delete?
> I have an edit routine that seems to work - when user presses edit the
> record locks until it is saved or cancelled <- another user can look
at
> that record but cannot edit it (message pops up saying someone else is
> using it <- is there any way to get the name of the person who is

editing

Mike,
Here's a quick list.

First, don't append. use insert-sql (look it up in help) That way you
don't need to worry about locking the file. It's a one-step insert,
updates indexes...

open your dbf's shared so that everyone can get to them.

When you are actually going to edit the record, do an RLOCK() and make
sure the return is .t.  If it is not, you can use whatever error routine
you like. I generally put up a window that says the record is in use and
they can browse, but not save changes. Then I disable the save button.

That's a quick tutorial. There are more detailed ones in the on-line
help and in the manual.

------------============*************===========------------
Darwin Perkins                         Opinions expressed are
New Technology                      mine, not those of Boeing
President's Technical staff      Nuclear Energy is the single
Boeing, Richland                   most environmentally sound
Washington State              solution to future energy needs

------------============*************===========------------

 
 
 

Multi-user strategy

Post by Luis Gomez-Almei » Sun, 17 Dec 1995 04:00:00


No, the file does not have to be locked, but the record has.
In general it is better not to lock records when people is
editing them. The strategy that I use, and that it is recommended
by the biggest geeks (regardless of computer, language, or opera
tive system) is to put the fields in variables (scatter memvar
in FoxPro, or just painstakenly store them one by one) when you
"read" the record. Then, when the user hits the key to update,
then, and only then you read the record again (without scatter,
or without moving your dbf's fields to the variables), RLOCK()
the record, move the variables that the user entered to the
dbf fields, and finally unlock the record. The advantag of this
is that if a user decides to go for lunch in the middle of an
editing, you do not have the record locked for everybody else
for 2 hours (we take long lunchs around here).
Hope that this explanation is somehow readable.
Thanks for a good question
--
Let a man call a cab, and let a cab be called; and let the man
who calls it be the caller; and let the caller call nothing in
his call but: "Taxi...taxi... Oh, for Olympus sake... taxi!!!"
 
 
 

Multi-user strategy

Post by Mike Cha » Tue, 19 Dec 1995 04:00:00




>>No, the file does not have to be locked, but the record has.
>>In general it is better not to lock records when people is
>>editing them. The strategy that I use, and that it is recommended
>>by the biggest geeks (regardless of computer, language, or opera
>>tive system) is to put the fields in variables (scatter memvar
>>in FoxPro, or just painstakenly store them one by one) when you
>>"read" the record. Then, when the user hits the key to update,
>>then, and only then you read the record again (without scatter,
>>or without moving your dbf's fields to the variables), RLOCK()
>>the record, move the variables that the user entered to the
>>dbf fields, and finally unlock the record. The advantag of this
>>is that if a user decides to go for lunch in the middle of an
>>editing, you do not have the record locked for everybody else
>>for 2 hours (we take long lunchs around here).
>Ok Give me a solid way to check if the record is not changed in the
>meanwhile? What do you let the User do if the record is changed?

Assuming that you know that the record has been changed, the classic
technique is to offer the user the choice of cancelling his changes
and accepting the new version and canceling his changes or of overwriting
with his own new version of the record.  You can check for a
changed record by scattering the record to an array when you first
pick up the record for amendment.  Then, just before you commit the
users updates, check the record in the file to see it has changed
(field by field comparison with your saved snapshot of the record).
There is a snag here. The change that has occured could have been
an essential change (decided as essential by someone else) or a flag
set by some sort of system process).  In any case you would not want
a junior user who is changing a clients telephone number overwriting
a new credit limit set by the boss.

You can minimise the problem dramatically.  In reality, if there is a
collision of changes - a record has been changed in two places in the
same time span - the collision occurs at record level not at field level.
In other words, two people might be changing data in a record at the
same time but rarely are both changing the client telephone number at
the same time.  The solution is to be a bit cunning while you are
checking the record for change collision.  Say user A has changed a
field or two while user B is entering his or her changes. Before
commiting B's version of the record, lock the record, check field by
field. If a field has been changed by A but not by B then accept A's
version and overwrite B's old version.  If a field has been changed
by B and not by A then of course accept B's version.  If a field has
been changed by both (change collision) then dump all changes by B
*AND* inform B that what has happened. I have found this method works
well in practice for all versions of foxpro.  

Hope that made sense Willy :-)

Mike

 
 
 

Multi-user strategy

Post by Willy De la Cou » Tue, 19 Dec 1995 04:00:00



>No, the file does not have to be locked, but the record has.
>In general it is better not to lock records when people is
>editing them. The strategy that I use, and that it is recommended
>by the biggest geeks (regardless of computer, language, or opera
>tive system) is to put the fields in variables (scatter memvar
>in FoxPro, or just painstakenly store them one by one) when you
>"read" the record. Then, when the user hits the key to update,
>then, and only then you read the record again (without scatter,
>or without moving your dbf's fields to the variables), RLOCK()
>the record, move the variables that the user entered to the
>dbf fields, and finally unlock the record. The advantag of this
>is that if a user decides to go for lunch in the middle of an
>editing, you do not have the record locked for everybody else
>for 2 hours (we take long lunchs around here).

Ok Give me a solid way to check if the record is not changed in the
meanwhile? What do you let the User do if the record is changed?


 
 
 

Multi-user strategy

Post by Luis Gomez-Almei » Thu, 21 Dec 1995 04:00:00


I suggested to read the record, show it to the user, and when
the user hits the key to update the record, then read the record
again, lock it and update it. Someone wants to know of some way
to make sure that the record has not been changed by another user
between the two reads.
That is a very intersting point. I presume that we are interested
in knowing if the record has been updated or not. In cases when
you are updating stock in on order entry system, you only care
if there is still enough stock to fill the order. So, you check
for available quantities, and if there are not enough you do
what is the standard in your company (issue messages, back order,
etc). But you can always check (in the second input from the file)
if the any of the fields in the record are different than those
that you have in memory. What you do then depends of the
application, company policies, standards in your shop, etc.
But in general it is a good idea not to lock a record and send
it to a display and wait for the user to update it. If you are
trying to update a record that has a lot of frequent updates,
and you lock it, and the user gets a phone call in the middle
you will probably have other users screaming when they cannot
proceed with their transactions.
As I said, this is a methodology used in any on-line multi-user
environment regardless of machine, language, and/or operative
system. With two reads you have the record locked for mili-
seconds rather than several minutes, and that will greatly
improve the productivity of the data entry people.
I hope that my explanation is not too obscure.
Regards,
--
Let a man call a cab, and let a cab be called; and let the man
who calls it be the caller; and let the caller call nothing in
his call but: "Taxi...taxi... Oh, for Olympus sake... taxi!!!"
 
 
 

1. Multiuser strategy.

It seems we have some problems w/ mulitiuserness in our database.

Does anyone a strategy to attack the problem against potential pitfalls.

I already set SET EXCLUSIVE OFF, SET REPROCESS TO AUTOMATIC.
I try hard not to open any tables exclusively. But sometimes I have to.
(ex when I pack). What is the best way to handle this situation.

Also are there any other situations (other than EXCLUSIVE access) that I
should think about.

Thanx a lot for any info.

Dan Akselrod
------------
http://menger.eecs.stevens-tech.edu/~danax

2. Anyone converting Oracle SQL*Forms 3.0 -->> Java

3. Multi-user FoxPro vs. Multi-user RBase

4. Blank table names (was unable to delete table)

5. Strategies for minimizing multiuser conflicts?

6. Sources for UniVerse BASIC De-compilers?

7. Best strategy, multi-tier?

8. Appeal for RDBMS Algorithms (and other Information)..

9. large multi-byte char column strategies

10. Please HELP - multi-developer class management strategy... (reposted)

11. single user/multi user mode error messages

12. Single User/Multi User

13. Converting Single user version to Multi user (network) version