Kevin,

I have 2 uses for the include-DBF's:

I have a set of common tools/modules for all my applications. But some tools/modules are not supported or implemented in an app. All tools/modules supported in this app are stored in a .DBF included in the .EXE.
Because the calls are generic, I look if it is included in that .DBF, so I know it the call is valid or not. If a new version includes the new tool/module, I put it in the .DBF and build the .EXE. This way I don't have to change the generic code and get the new functionality. Because the .DBF is included in the .EXE, you can't (accidently) put the not-suported stuff in the .DBF.

The other use is that I have some data that must be imported into the current (live) dataset. Because I use surrogate keys, I can't do a simple APPEND FROM, so I have created a little program that creates temporary tables (with the imported data), generates new surrogate keys and put those values in the foreign keys for the right relations. Those temporary tables can be used with APPEND FROM to put thim in the live dataset. Afterwards I delete those temporary tables from the (local) temp-dir.
I use included .DBFs in this .APP because I find it easier to do USE xxx and COPY TO, then to use CREATE TABLE and (lots of) INSERT INTO statements.
Because the .DBF's are included in the APP, the contents of the .DBF's cannot be altered (at least in a easy way) and you don't have to worry that those IMPORT-DBF's are confused with the .DBF's that are used in the live-dataset.

Regards,