>If you have reference to a stored procedure elsewhere, you have to have the database to avoid compilation errors. The EXE will still build, however.
>The build process won't look anywhere else except the project (or files in the project) for a stored procedure.

Building is decidedly unfriendly regarding file resolution when compiling. It sounds like the builder and 'compiler' (interpreter? pre-interpreter?...who knows what evil lurks?) may not resolve things consistently with respect to each other.

I have not done as you suggested (in a past thread) and made my local development folder hierarcy look exactly like the live folder hierarchy and I've really paid the price. Problem is, I'm kinda committed to the way I've got things structured and I'm a little leery about 'fixing' things....if you know what I mean.

File resolution stuff can really break your head if you are not careful. I wonder if there is a way to investigate an .exe file to see exactly where all of the sources came from (including symbol sources like .h files)...that would be really cool.

I sure wish VFP had a concept of a 'logical name' and a 'compound search path' (these concepts come from my DEC TOPS20 days ... I suspect UNIX has something like this too)

then you have mylogname = 'c:\dir1;f:\dir2;myotherlogname:;e:\dir3'

and mylogname:myfile.ext gets resolved by running down the path.

The DEFAULT and the PATH are very limited proxies for the more general capability.