>Hi Dragan,
>
>
>>And just to pacify the worm which was biting me about this - I've tried to see whether there's one FCB (file control block - remember CP/M? - or whatever is the construct where the file handle is) per session per table, or just per table. IOW, the situation that Fabio started this thread with: if the first opening of the table is read-only, all subsequent uses of that table will also be read-only until all aliases of that table are closed.
>>
>>This holds only within the same datasession. If all your forms have private datasessions, it makes sense to open any lookups read-only, or tables to just report from. The lookups would be read-write in the forms where they are edited.
>>
>>Now imagine a scenario where 50 workstations have the customer table open - the network has to check for record locking for all of them, even though only one is doing any updates to this table. But if 49 are using the customer table readonly, the network knows the locking may come from one workstation only, ergo its overhead is reduced drastically, at least as far as record locking goes.
>
>It does not quite work this way. the locks are administered on the server, not on the clients, so it is no big big deal no matter how many clients have opnened the table.
>
>The server normally uses a opportunitic locking scheme to enable write caching data on the client if the client is the only client that openened the table. Also, it enables read chaching as long as no other client writes to the table.

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.

Unfortunately, in my reading of as much detail as I could find regarding "opportunistic locking" and the "Redirector" and related, it is more a fictional account of what should happen than it is an actual account of what DOES HAPPEN. In fact it leaves more questions than it provides answers.

It was MikeY who kept my part of this alive... the same guy who wants to save the picoseconds relevant to Mdot, so I was surprised at his question!

cheers

>
>Walter
>
>>So your intuition may have some realistic foundation, if I'm right.