<snip>

>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!

First, I wanted you to explain how noupdate can have anything to do with the mdot problem. If anything happens in code that is attempting to update a table and an error is triggered because the table was opened noupdate, that's indicative of a design problem, not an mdot problem. Mdot is a problem when accessing variables, not when updating tables.

Second, the mdot problem is not so much a performance issue as it is a debugging nightmare. Even seasoned developers can be bitten by it. As Peter D showed recently. The slight performance increase is a side effect.

Third, in thinking about this since the thread started, I can see situations where users would not be able to add / edit lookup tables, leaving this to some administrator type. The typical user might have noupdate. The "cost" of this design decision would come when the user can't complete their work because something is missing from the lookup table. I want the users to be able to update the lookup tables, preferably on the fly. It's better than my having to update them.

However, if the client insists, and I can't convince them otherwise, I think I'd implement this by using a security feature to decide how the tables would be opened, as well as disabling the add/edit on the UI.

I know it was a common suggestion at one time to open all tables when an app starts. If they were opened noupdate, and all subsequent writing was done in private datasessions, can anyone show a performance improvement during startup?