>>Michelle,
>>First off, you could put the config.fpw in the project - it will then look at this instead of any others. Also, I always try to put as much in the project as possible - in the case of data, if it is constant and will not be altered, put it in. Temporary file structures (or even empty databases to create others from), put it in. You can use a database (use filename) if it is included in the project and then copy structure to ..., etc. You cannot issue copy file [filename] to ... if filename is within the project (I found this today). Sometimes, you can fit quite a bit in the exe. Only problem would be if structures need changing - fortunately, mine have never needed changing (YET).
>
>If I put the config.fpw in the project, what happens when I distribute the executable? I want it to use the config.fpw in the directory with the executables. Not everyone has the same path to the data. Will it use the built-in one or the one in the directory?
>
>As to the other, are you saying if I put the tables in the project that they will become part of the executable? I don't want that. I'm changing those suckers too much. Besides that, I frequently update clients' executables and don't want to be overwriting their data.
>
>
VFP has file locations for everything else imaginable. Why doesn't it have one that tells it where to find the data?
>
>If it would just use the config.fpw that's in the directory, all would be well. But it seems to ignore it when run from within VFP.
>
>Thanks,
What I suggest is to put a copy of config.fpw (the same as in the directory with exe) in the project - this will ensure that the same config.fpw will always be used (the one in the exe). As for putting tables in the project, ONLY put tables in which WILL NOT be altered (fixed reference tables, fixed lookup tables, etc). I just re-read the bit about config.fpw - use SYS(3) to identify where you are and then you (hopefully) should be able to find the data from there (or at least open a file there to tell you where the data is). Regards,
