>Well, Walter, I STILL think that NOUPDATE could help (performance and app integrity) and sure can't "cost" any extra...
>
>1) It's gotta help cache management, both local and (file) server.
>2) Related, its gotta help RAM resources too.
>3) Reduced locking sure can't hurt.


Hi Jim,

BTW, I'm doing fine in SF.

Regarding this issue. At least there was some documentation on MSDN. I don't have it with me so I could not give yu a link, but if you search the UT on oplocking or opportunistic locking you'll find some references and explanation in some messages I wrote in the past.

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.

Walter,