>>A "multi-user application" can have local exes and local dbcs. The DBFs need to be shared, not the DBC.
>
>While I totally agree on having local dbc's for views I don't think the dbc's describing normal tables ought to be *always* local. While "alter table" is not the typical command inside an app it might be dangerous to assume it never will be run. As long as you don't use "select *" in your view-definition you won't always have to recreate the local dbc's, but it might happen if you need the new fields. Here I am a solid believer of "it depends" <g>.

First off, Naomi is the one saying that a multi-user app MUST have a shared DBC. I'm saying that it may be local, not that it must always be.

Think over what is required to support having a local DBC. Never alter the main tables programmatically - sounds like a maintenance function. If the code programmatically alters tables, what's to say the screens will function? That's dangerous. Sending a new EXE when a DBC changes? Seems good to me.

What about the shared DBC? 100,000 loop to try to connect? Does that seem reasonable? Workarounds to break out the views just to avoid a potential deadlocks when several users try to run one query?