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

I'm not sure why the developer put this loop there. Our main application doesn't alter the tables. So what exactly you're proposing? The application should be able to work with different databases. The database path is specified in a special table...