>The following I'm doing from the top of my head, so there might be some minor errors in here, but the general idea should be correct.
>
>My take on this that opening files is on the avarage not helping performance. The deal is that when a file is opened in readwrite mode and the client is the only client that has openened th file so far, the client both chaches reads and write. I believe this the oplockmode 0. When a second client want's to open the file, the fileserver requests the first client to flush its writebuffers. So the writes are not going to be cached locally (oplock mode 1). When any of the both client is going to write changes to the file, the file server is requesting to eliminate the readbuffer at any client and get the row directly from the server (oplock mode 2)
>
>Of course at the OS level some further optimization is happening regarding buffering, but I do not know many details about that.
>
>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.

In the second scenario, for any write, the file server not only has to check who else has that block cached, but also has to check whether any other workstation's locked blocks may overlap with it.

Also, if we open the lookup tables readwrite only in their editing forms, chances are that they will be open readonly on all workstations most of the time (how many times do we add a new member, customer etc? how long does it take to do?), so in that case there's no locking at all. None of the opportunistic locking schemes apply when there's no locking - and there's probably a much simpler mechanism at work on the server.