If you keep the tables as free tables you can do a lot, but there is one problem that will bite you every time: if you have memo fields! When VFP writes to a memo field, the older version(s) will not like it. We had this situation where I worked. We used FoxProWin 2.6 and there was an application written in VFP 6.0 that accessed the tables. Some code errantly wrote the the memo field and then errors kept coming up. I tracked it down to the memo. When I cleared the field in that record, the error didn't kick any more. As far as I know, the memo field format keeps changing. I've been told that memo fields have always been a problem between versions.

Dana
>>I'm working on converting an application from FoxPro 2.6 to VFP 7.0 However, the tables are used by (at the present time) and indeterminate number of other systems and applications. As a result, I want to insure that the tables are NOT changed from 2.6 to 7.0 format. As far as I can tell, the version is identified by the first byte in the table header record. I've identified the following possible solutions, any input on these or other solutions would be appreciated.
>>
>>1) Have the VFP app switcheroo copy all the tables to a 2.6 version when the user exits.
>>
>>2) Create a function or the like that, when 2.6 fails to open the table, will rewrite the header record to identify the table as a 2.6 beast.
>>
>>Respectfully,
>>
>>John
>
>I have an old Clipper application rewritten to VFP 7, but the files must remain available for another Clipper applicaiton still in use.
>
>I created a utility to set the code page on the Clipper DBF files to 437 before the application even runs. Poke around in the CPCONVERT, CPZERO, CPCURRENT and related functions in the VFP Help section.
>
>And look at any command in VFP that makes a new file to add a parameter to make it FoxPro compatible. Like Copy To or PACK.
>
>And warn the clients to pick 437 as code page if anything slips by you.
>
>dennis