>>>The trouble will appear the first time there's a change in the structure - an exe containing the dbc with the new structure will error out when run while the tables' structure don't match. Also, opening any of the tables apart from the .exe (as in „something's fucked up, let's open this in VFP6 to fix the index“ or some such intervention) will be impossible if the dbc can't be found, it being inside the exe.
>
>>It wasn't asked to write to the tables or the DBC. It was just will the table find the related dbc.
>
>Ouch, I didn't think of that from the standpoint of the exe itself. Perhaps it would, if the dbc was explicitly open before the table, or perhaps fox would find it the way it finds other stuff within the exe... but honestly, I wouldn't bother to be the one to try that. Why bother, really.
>
>If it's a matter of having dbc absent when the app isn't running, I'd include it (probably zipped) inside the exe, then unpack it on app start. Or, what I did 20+ years ago in the case of a views-only dbc, create it in %temp% from code on app launch, kill on quit.

There is only - the environment is able to deal with DBC/VFP data or there is a SQL server. Anything else is very odd.