Hi Mike,

SNIP
>>
>>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.

First, I seem to have misread your please explain. My apology for that.

I agree that my statement regarding helpful with the Mdot problem was over the top and should not have been made. It occurred to me as I was writing that the 'safety' feature of NOUPDATE could help that issue and I typed away without giving it another thought. It was dumb to do so!

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

That's fine - we all have our variations on these kinds of things. I have had the odd occasion where users can update lookup tables. My experience is that they get crap in them real fast that way.

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

I think you're jumping to conclusions here... why on earth would someone who opens their tables at the start open them all with NOUPDATE???... surely their design would inform them which they will be updating and which not and they would open them accordingly, wouldn't they.
I would say that, in the general case, it is best to open any table with the minimum of 'rights' required by the design. It just seems like a sensible thing to do.

cheers