>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.
I don't think you've considered the range of things that may require some handling for the upgade process; as I mentioned, I've written this before, and my guess is the update engine, used to implement each version update, required several hundred hours to actually design and write. At the very least, the set of things which might change from version to version is considerably more diverse than you indicate. I'd suggest that you consider how the sequence of processing affects the update operation, and how each type of individual update can be reversed if something following it fails to complete.
>
>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!
Good luck; it's your responsibility. If nothing else, at least be sure to thoroughly test the upadte app fully in all installation environments; what works in Win9x might break under Win2K, or network installations don't behave like standalone setups. Test the probable failures - inadequate disk space, unable to get exclusive access to files, file damage, user-customization of files (always fun finding a new field, or perhaps one with a different size or type than expected), various user rights (especially significant regarding updates to system files, the registry, shortcuts from the AllUsers Desktop/StartMenu, or which need to be updated for each user). There's lots more to this than you seem to think, but it's up to you what you deal with. I'd definitely expect far more issues than you mention.
