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

What do you mean the application should be able to work with different databases? .DBC or .DBF?

Regardless, each .DBC and .DBF must have the same structures for all copies of the exe that share them. If the .DBC is copied to the local machines (as the exe should also be copied to the local machine) performance will improve.

Obviously the developer put that loop there because there was or may be some problem opening that SHARED database.

If the DBC was local, and the DBFs shared, there would not be any need for the loop.

Try this:

*Local DBC
CREATE DATABASE C:\TEST
*Shared table.
CREATE TABLE M:\TEST1.DBF (CFIELD1 C(10))

I guarantee you'll be able to access that DBC because it won't be shared.