Hi Jim

SNIP

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

No problem! You're right though, that overall, noupdate would reduce the chances of unplanned updates.

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

It's possible. That's true. However, isn't it funny their trusted to update more important tables? <g>

SNIP

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

Agreed, but you brought up my penchant for performance. <g> So, if all tables were opened noupdate, that should be faster than opening them all for update. That's assuming that we open them all at the beginning. In recent years, I've been tending away from that.

Am I wrong that the tables can be updated if opened in a private datasession after they were opened in the initial datasession noupdate? If not, it seems we'd be able to further control the unplanned updates, by planning them to occur in a private datasession.