>I thought my 'explanation' was informative as-is, Mike.
>
>My typical apps., all written for in-shop usage, tend to have several tables where read only is fine. Why would I open them some other way in such a case?... especially when there is a **chance** that resources usage/performance COULD be improved by using them NOUPDATE????
>
>I don't feel that this would be a simple thing to prove, one way or the other, so I go with my instinct. And my instinct tells me that it is a smarter thing to do. Of course this involves yet another decision to be made while designing/coding and I know that many (most?) look for 'rules' they can apply whole-hog without variation. I've never been fond of such rules and tend to enjoy thinking a bit for myself.

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.

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