>> Only problem, and it is a biggie, IMO, is that you loose the
>> related information stored in the DBC.
>
>
>precisamundo Nancy -
>converting to free tables would also clobber all my nice long
>field names too, rendering the table useless.
>
>with distributed systems such as this one, i shy away from
>using permanent relationships, stored procedures, etc. because
>the client machine can truly be considered a hostile environment
>and if (when) something happens to the DBC or a DBF i usually have
>to restore data as of the last synchronize as well as table
>structures. use of transactions has gone a long way to avoid those
>problems, however.

While I agree with all that, I am totally confused as to the point. You can only link a table to 1 DBC. If you remove the table from a DBC what is the problem with the information about that table being removed from the DBC as well? That info is now irrelevant with respect to that DBC. Before you remove the table from the DBC, you could do a CREATE TABLE while the new DBC is the current one, then an append from the old table so your data gets appended into the correct long field names.

You can then use DBCGetProps() and Alter Table on the rest to recreate PK, FK, Indexes and other properties. You can get all the relevant code just by running GENDBC and incorporating the resultant code in some utility program [or, with VFP6SP3, a MEMO field in a table to be compiled] and run under runtime.