>>Terry,
>>
>>Have not done it myself, but I guess the simplest for you, unless you did some very heavy use of the .DBC, is to keep your scheme, but use the create table instruction to create the tables in the new form, while the database is open.
>>
>>You could also look at Alter Table, but I get a headache when I see the Help page about it. :)
>>
>>HTH,
>>
>>Marc
>>
>>
>>>I periodically ship updates to my systems to the field. These updates can contain structural changes to the tables. In the past (foxpro2.6 Dos) I stored the new updated (empty) tables in an update directory. I then renamed the existing (full of data) files, copied the update table to the active directory and performed an append from to get the existing data into the new table format. VFP5 and its database (DBC) has roadblocked me from doing this.
>>>
>>>How do the rest of you handle updates in the field?
>>>
>>>Thanks in advance
>>>
>>>Terry
>
>===========
>
>Hi Terry Hobart,
>
> I copy the DBF to a TEMP FOLDER and then "FREE TABLE"
>for all of the DBFs that are in a DBC. Next, I copy a
>complete set of empty DBFs with matching DBCs into the
>main APP folder and APPEND FROM the TEMP DBFs into the
>new main APP DBFs. Works for me...
>
>Hope this helps,
>Terry Harris
Take a look at Stonefield's Database Kit. Has methods for NeedUpdate('') Update('') tables on the fly at the customers site. No need to copy/free/delete any things. Tables updates/reindex/created as needed. Base on DBCX and the SDT Metadata tables... Also will repair/reindex tables with single method calls. Doug has pack A LOT of DBC put/get property intelligence in this kit. Worth every penny as a tool and learning engine -- you get the source!
HTH