Jim & Jim, PMFYI,

Though at this point in time you seem to have settled somewhat, I think I can add some interesting stuff to the debate.

First
Exclusive use is different from FLock for obvious reasons already :
An exclusively opened file (table) can't be opened elsewhere, whereas an Flocked table can (possibly for read only, which Fox doesn't determine).
A table opened for share can't be zapped, whereas a exclusively opened table can.

Second
An exclusively opened table "sets" the whole environment around the table, as if it really were not possible that another interferes with the table. That is, not for writing, but also not for reading. This implies that all around re-fetching of records from the PC that exclusively opened the table, isn't applied. Also, it all allows for writing back to the server the updated (or new) records, whenever it's "handy". So really no multi user aspects are involved here. And it is right that that slows down the whole operation on shared files to a degree you hardly can imagine. Note that this is not so much about the server having to to a lot around locking and presenting statuses of it, but merely the network (speed, not capacity) that's holding all up. Please look at this :

I have a loop creating records on a simple one-field table with an index on that field. I add 5,000 records (table is empty from starters). It doesn't apply explicit locks or flushes or whatever. It's about an append and replace (hence no INSERT - SQL) :

Exclusive  Flock   Nothing
1.6 sec    29 sec  52 sec

What does it say ? first that the above is "proved". But secondly that an Flocked situation improves speed. Why ? because nothing with record locks have to be checked. Why is Flocked slower than Exclusive ? because it'll need to apply my changes as fast as reasonable (remember, other users are allowed to open and read the file).

Note : This was performed on a 5.x Novell, which really can make a difference opposed to e.g. NT.

Third
FLock sucks. For logical reasons already, but also for technical reasons (VFP 5). I won't tell all the anomalies around this, but let's abbreviate it all to the unclearness around all :

RLock('0',cTableName) will lock the header. My idea : same as FLock() but it's not. When the header is locked with RLock the other user can still RLock any record;

FLock() locks the header too. However, the other user can't apply any RLock() for records.

I didn't try, but it's my guess that this works the other way around too : when a user has records locked, the other just can lock the header by means of RLock('0',...). Presumeably this "feature" is for preventing the adding of records only ? possibly, but I can't see the advises on this in (VFP5) Help.

At least in VFP5 there is this simple bug in the FLock area :
When the file is FLocked, and implicit locking is implied by means of a Replace without preceeding RLock, at the second Replace, an intenal Unlock is allpied and ... the table is free from the FLock. What about that ?
Don't say this can be done with explicit RLock(), because you will find yourself in trouble at applying the Unlock of it : Unlock is used to free the FLock just as well as any RLock.
Okay, one solution : SET MULTILOCKS ON and have explicit RLocks. It sucks.

When MULTILOCKS is switched from ON to OF, there goes the FLock again. BTW, not from OFF to ON.

Based on the mechanisms of MULTILOCKS = ON, I assume a subsequent FLock and Rlock from a record, followed by an Unlock, would let the FLock remain. But it does not.

When good logic is applied, using FLock (in combanation with RLock('0' ...)) I think all can be made fool proof. But I didn't even start look for these kind of bull, assuming that freeing the header with the UNLOCK RECORD 0 might release the FLock again etc. etc.

Again, It's VFP5 here ...

Regards,
Peter


>Jim,
>>Jim,
>>
>>>1) The table of "Commands that Automatically Lock Records and Tables" should mention...
>>>--- that tables opened after SET EXCLUSIVE ON is in effect will cause a lock of the table(s);
>>>--- that tables opened with the "EXCLUSIVE" clause of the USE command cause a lock of the table.
>>
>>I would disagree with this as EXCLIUSIVE use is NOT the same as a File Lock. I don't believe that exclusive use secures a file lock.
>
>I would certainly agree with you if I was sure of exactly what a "file lock" is. My GUESS on the subject is that a "file lock" is a totally different mechanism than a record lock and that there is a good likelihood that it is the same mechanism that the operating system (file system) uses across all applications when it wants to prevent access of the file by others.
>Can you please clarify the situation?
>
>>
>>>3) The table under the "Unlocking Data" section lists "SET MULTILOCKS OFF" and describes its effect as "Enables automatic release of the current lock as a new lock is secured" and the Command Reference for SET MULTILOCKS states "Switching SET MULTILOCKS from ON to OFF or from OFF to ON implicitly issues UNLOCK ALL — all record locks in all work areas are released.". I see a contradiction between the two entries. In fact I can't really understand what the first quotation is actually telling me.
>>
>>This one is pretty clear to me, SET MULTILOCKS OFF sets up a situation where securing a record lock automatically relaeses any other record lock that may have been in place on the table. Also flipping the value of SET MULTILOCKS will release all record locks that are in place at the time the value is flipped.
>
>I realized after re-reading my message that the documentation is really telling us about two different aspects of MULTILOCKS.
>But the issue still stands - the documentation section titled "Unlocking Data" really MUST mention the consequences of 'flipping' the set value of MULTILOCKS.
>In fact it is highly misleading as currently written, because it says (in other words) that when I issue SET MULTILOCKS OFF nothing really happens at that time but when I next request a lock it will automatically release the lock that was previously in place and then place the lock on the new record.
>
>Thanks
>
>>
>>For example if I have three record locks in place and I then SET MULTILOCKS OFF the three locsk will be released. If I have a record locked and I SET MULTILOCKS ON that record lock will be released.