Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Updating EXE and Data Without Disruption
Message
De
06/12/2001 11:57:43
 
 
À
06/12/2001 11:11:32
Jay Johengen
Altamahaw-Ossipee, Caroline du Nord, États-Unis
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00590579
Message ID:
00590605
Vues:
36
This message has been marked as the solution to the initial question of the thread.
>I know I've seen this addressed before, but what would be the cleanest way to do the following without disrupting the running of the application:
>
>1. Update the EXE if it exists on the PC
>2. Update the EXE if it exists on the server
>3. Update the DBC if table structures have changed
>
>I have looked at the many loader programs available, but it's hard to decide which is best, or if it is actually better to write my own process. Thanks!

You've missed some potential major steps, such as updating components, runtimes and the like, and not looked at platform-specific issues. I've used a combination of loaders written in WSH and InstallShield-based transactional installs to do most of my work; the obvious thing is that I have to insist that the platform supports WSH at the version I require or later, and that it is capable of using the Windows Installer technology. I use SDT to handle most of the issues of updating the DBC and table structures, indexes and the like, because Doug did a great job with the tool and it is applicable in a wide range of situations that I can control programmatically.

I invested a great deal of time designing and implementing a metadata system to describe system states, to handle some of the issues for upgrade/update; once I went to using the Windows Installer technology, a great deal of that had to change, but the basic philosophy of pull distribution using a loader to initiate the status verification and update remains the same. I use WSH because it's deployable immediately; if I wrote the loader in VFP, then the VFP runtime would have to be present before the loader could run, which meant I'd need a selgf-installing cross-platform executable to support the runtime for my loader, which needed a pull-based installer...you get the picture. I've handed off a lot of the component responsibility to the Windows Installer, which knows when to use things like deployment to a system directory vs side-by-side component installs, etc. I think the combination of WSH and the Windows Installer technology, whoever's implementation you select, is a good one, and leave the VFP table and metadata maintenance to SDT.

>
>Regards, Renoir
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform