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

I think there are two kinds of lookups - those under applications control, and those under users' control. The first kind would be tables with internal names (metadata, object factory lookups etc), the others would be users' names for things (customers, inventory items, locations etc).

While I'd never trust them to fill the first type without my supervision (or at least one control in the end), we, unfortunately, have to have let them populate the other type. And they invariably manage to put all sorts of things there. Their level of general (and computer) literacy can be seen from their customer list.


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

I've tried that several messages upstream from this, and yes, the status of the first use of a table is inherited in subsequent "use again"s only as long as you're in the same datasession. So if we keep the lookups readonly in forms where they're used as lookups, and open them readwrite in forms where they are edited, they will be readonly most of the time - and safe from occasional inadvertent updates.