Multi-user environment without locking entire table 3

[Paco75]

Hi,

Actually we got applications that use free tables. Up to now they were used by only one people at time and in rare cases by two at same time (and in that case the second waited for the first to finish). But it happens more often that two users want to use the same program at same time. So im looking for a good way to manage multi-user environment.

The ideal would be to be able to lock each records being used. This way allowing another user to use the other records in a table having another record locked rather than locking the entire table as it is actually doing.

any help appreciated!

 

[Olaf Doschke]

Dan,

this was the reason for this thread. Early on Paco said: But it happens more often that two users want to use the same program at same time.

So it seems his program is working with exclusive access, that needs to be turned off.

As you say yourself: There are inevitably conflicts. And it doesn't hurt doing things the right way in the first place.

Nevertheless I agree that manual locks are rather a pain than helpful. The idea, that this prevents conflicts is correct, but it causes more hassle than benefit.

If you're still interested in the buffering / locking strategy topic anyway, Paco, I always recommend Andy Kramek for that:

http://weblogs.foxite.com/andykramek/archive/2005/10/18/948.aspx

Bye, Olaf.

 

[Paco75]

Hi Mark,

please send it at lachancepascal at hotmail, ill have a look at it

thanks

 

[Paco75]

thanks all i finally got it working.

 

[Paco75]

Here is a link i found interesting that might help anyone looking to go multuser.

http://weblogs.foxite.com/andykramek/archive/2005/12/27/1077.aspx

 

[Paco75]

Andy Kramek says something on one of the links that might makes me change to optimistic buffered tables... But for now i will try optimistic row buffering.

So what mode of buffering should I use in my forms?

To us the answer is simple. You should always use table buffering with an optimistic locking strategy (i.e. Buffer Mode 5). The reason is simply that, with the exception of building an index, there is nothing you can do in any other mode that cannot be done in this mode. While row buffering can be useful in development, we do not believe it has any place in a working application. The reason is simply that there are just too many ways in which the implicit TableUpdate() (caused by moving the record pointer) can be triggered, and not all of them are under our direct control. For example, the KeyMatch() function is defined in the Help file as;

Searches an index tag or index file for an index key

Seems harmless enough - surely searching an index file cannot cause any problems. But a note (in the Remarks section right at the end of the topic) also states that:

KEYMATCH( ) returns the record pointer to the record on which it was originally positioned before KEYMATCH( ) was issued.

Hang on right there! Surely 'returns the record pointer' implies that it moves the record pointer - which indeed it does. The consequence is that if you are using row buffering and want to check for a duplicate key by using KeyMatch(), you will immediately commit any pending change. (Of course in Version 6.0 or later you can always use IndexSeek() instead.) However, the same issue arises with many of the commands and functions that operate on a table - especially the older ones that were introduced into FoxPro before the days of buffering (e.g. CALCULATE, SUM and AVERAGE).

More importantly, the fact that you have a table set up for table buffering does not prevent you from treating the table as if it were actually row buffered. Both the TableUpdate() and TableRevert() functions have the ability to on the current row only. The only practical difference, therefore, is that that no update will happen unless you explicitly call TableUpdate(). This may mean that you have to write a little more code, but it does prevent a lot of problems.