>David,
>We have two projects - identical except that one has the database in it (for everyday programming, review, etc.) and the other does not have the database. Compiling is a breeze, and because the projects are O3 and O3b the compiling always results in a file O3b.exe which we can test without overwriting the 'working' file. When we're sure of the changes, we do a 'hot swap' renaming O3.exe to O3_yymmdd.exe and O3b.exe to O3.exe. The next time each user opens the program our 'wrapper' copies the new version onto his local drive.

I'm sure responsible project managers have come up with all sorts of codified methods for working around the limitations of the project manager. You're method sounds like a good one but on the surface has the classic parallel sources pathology...which you no doubt have mitigated with some standardized maintenance procedures.

Writing your own builder could help, but AFAICT, the real limitation lies in the limited resolution control one has over the 'compiler'.

And, as I said to Trey, it sure would be nice, after you get a build, to be able to get feedback about all of the resolution results so you can easily detect when sources didn't come in from where you expected.

Sure would save me a lot of time. 'H' file resolution has been especially problematic for me vis-a-vis FORMS and the fact that it's tedious to see how DEFINES have been resolved at debug time.

I wonder if any of this has been improved in VFP7?