>>How 2 make a TCP/IP connection to certain site to check the newest version and
>>update it if found the version is old.
>>
>>This may be huge task as the table structure may charge!
>
>I suggest that you should maintain a database of versions on the remote site describing what's the current version. This hould be downloaded from the remote site. It can then be compared to the items actually found on the local system; if differences are found, you'll have to either download a newer version or download a program that will convert from an older format to a newer format; you'll have to write the conversions between various versions to operate serially, or to deal with each possible older format to convert to the new format. SDT is a commercial tool that makes revising database, table and view related items considerably easier; you provide metadata describing the current format, and SDT manages most conversion and update issues automatically. Obviously, things that involve populating or restructuring exisitng fields will have to be hand-written in most cases.
>
>it's a tremendous undertaking; I've written systems to do this before for clients, and it represents a considerable investment in developing a suitable scripting and data conversion capability. The communications issue of using TCP/IP is insignificant compared to the data maintenance task. My experience is that developing the necessary toolset represents several hundred hours of time, and then for each update, someone has to create the necessary conversion apps to work with the update scheme.

---

Well, I consider the updater prg task to do:
- Check version if different, d/l the patch#.zip
- unzip them to some folder
- run the self-written converter
- quit all current application, most likely the exe file need to overwrite!

Now, Consider the self-written converter on handling change on data structure.
The patch#.zip should give ALL dbc files and the Empty dbf with new structure.
So, whatever Old version of application data can most likely import into the new one.
Generally, most data can be transfer into new structure unless drop fields or rename fields..

If really there are some fields are rename, make a universal table with all fields,
import all data, use replace cmd to fill in new fields value..
If there are some new candidate key checking, use SQL to filter them and use another tmp file
to carry the filter out data.

Put them back into final Correct structure table, (Of cos, empty table included in zip files.)

After those import code, the new folder should carry the newest fresh data
with newest data structure include views. Final action is to Overwrite ALL files to old directory.

---

In my view, using prg to compare all different version of table and
use coding to resize table as newest structure is NOT suitable at all.

Even in my Local LAN update, I never never do this.
Reasons:
1. if you need to change the PRIMARY KEY field length, you lose everything on dbc!
i.e. all the cross link from table to table will be auto-deleted
you need extra code to maintain them.
2. if you add some new field to a table, you need to adjustment all Views in dbc..
but the way to do is delete all corresponding view and add back by: CREATE SQL View...
(if this is done by coding automatically)
3. Time consuming and it may be some missing change.
Some time cannot be shorten, import data time from existing data VS chg structure on existing table
Accuately, the front is more shorten time, no need do reindex!


Anyway, my thought is from the easiest way, if you found a problem that can't use that method,
highlight me.

Currently, I think using IMPORT method with providing all final newest data structure.
the time on both writting converter and "update" at client side may be 1/3 or less.

Recently, I use this method with about 1 hr to convert 20+ the Dbase IV table in old system
into workable VFP new structure table, some of the table date using text format!