>
>The second solution, that works perfectly (but you won't like it), is to move the views to a separate DBC and distribute the new DBC with the app to each workstation (this is what I do). When you create a view, have the target database open as well. Then, when asked which tables to add to the view, switch databases in the combo box that appears with a list of databases.
>
>You end up with views based on SQL like this:
>
>SELECT (FIELDS) FROM database!table
>
>Then all you have to do is guarantee that the database that contains the tables is open. This eliminates the problem you are describing.
>
>Hope this helps...

I've actually come up with a similar idea - for views-only DBCs I usually cram a generating routine, using what gendbc.prg generates and trimming it from default values, stripping the fields list where I need only a "select *" and such. This routine could be run with a database path\name as a parameter, and it could as well be generated for each user upon installation or at app start time, and reside at user's local disk. This would add speed, get rid of Erik's problem, and have no maintenance at all - if it builds each time, who cares if it crashes, next time we get a new one. If it crashes, it crashes only once for one user - and all the others work just fine.

This might sound as an overkill, but maybe that's what's needed in cases like this.