>>When you look at how this mechanism works, there is not much room for optimization in opening file readonly (the client prohibits changes, but does not have anything to do with the server). I do know that if the files' attributes is set to readonly, the client chaches larger amounts of data on the client, slowing down the opening of the file.

>OK, this sounds reasonable - and if we get back to my scenario of 49 workstations having opened a lookup table readonly and one readwrite versus the other scenario where all 50 have opened it readwrite - there will surely be difference in performance.

In the first scenario only one WS can have dirty write buffers, so it's the only one where there has to be a two-way communication of data blocks to and from the server. The others will just be notified when a block they have cached became dirty on the server, and will have to refresh that block.

I have to appologize for not reading the entire thread as I'm a bit of short of time (I'm in a hotelroom in San fransisco right now). I did some research on these kind of issues a few years ago, and what I can tell is than only one workstation can have dirty writebuffers and only in a situation where that workstation is the only workstation that has opened the file. So in effect there is not a big difference between having 49 workstations openened a file readonly and one readwrite as oposed to 50 workstations opened the file read/write. The oplocking mechanism at the server treats the opening of a file in readwrite modus exactly the same as readonly until one workstation writes to that file. Then the fileserver is going to notify all other 49 workstations that they need to clear all readbuffers to avoid dirty readbuffers whether they opened the file readonly or not.

I'm sure there are a few more details to it how this is optimized in regards to a VFP application with VFP bufferings mechanism on its own.

Walter,