Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1225
  • Last Modified:

How to automatize a VFP exe download to the more recent version?

Hi Experts!

Currently everytime an user needs to actualize a VFP system he first need to see if  it's necessary in the site and then decide to make the update.

Do you know a process to automatize the executable (.EXE) to the more recent version by checking it via net and accordingly with the version the user have at their equipment to download the more recent?

Thanks in advance!
Eduardo Fuerte
Eduardo Fuerte
  • 7
  • 4
  • 3
  • +1
4 Solutions
Are you talking about VFP9.EXE  (means the VFP development enviroinemnt)  or some application written in this tool and compiled into YourApp.EXE ?

Let suppose YourApp.EXE

So the obvious way is to write a small YourAppLoader.EXE which is the one used on a shortcut executed by your users. This Loader.EXE can do whatever you need, e.g.:

1) check for newer YourApp.EXE version (on internet, in e-mail, in some dedicated folder etc.)
2) download/copy the new version of YourApp.EXE into the application folder. It may require user intervention or elevated access rights etc. so users should know what they are doing or what the Loader is asking for... (difficult sometimes)
3) execute the YourApp.EXE
4) exit the Loader.EXE

So if the newer version exists the Loader ensures everything to be up to date.

Many variants of this process exist.

E.g. the internet check could be slow so you may ask users if they want to check for the new version existence. Another possibility is to create another process which will check for the new version on the background and the Loader will install it next time when you start the app. etc. etc.

The downloaded application should be protected somehow. You should calculate a  checksum as a minimum to ensure its correctness before replacing the old version.

I am using VFPCOMPRESSION.FLL to ZIP/UnZIP the application delivered by automated e-mail. Checksum is calculated by SYS(2007) and stored in a separate DBF file. The app transfer goes the standard way to all off-line locations during the data transfer.
CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
1) Check for new version online via another process
2) Download the new app into user temp folder
3) Unzip and make sure the file is extracted. If yes then it's healthy
4) Tell the user that the new version is ready to install
5) If the user clicks Yes, close the old application and copy the new one on top of it and then close the updater.
6) Make sure that the updater is called update.exe or setup.exe or install.exe so Windows Vista/7 know how to handle it. Not sure about 8.
7) Check for new version once a day or when the user wishes to.

I use this to download:
Olaf DoschkeSoftware DeveloperCommented:
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Eduardo FuerteAuthor Commented:
Thanks for your interations!
I just start reading carefully and come back soon...

Just to elucidate the actualization is currently done by a installer - the users first need to check by themself if it's necessary in the site, and then if so go to this page:

Eduardo FuerteAuthor Commented:
Hello, Olaf

The solution you pointed (sweetpotato) is the simplest

One  more thing just if you could help.

I don't know if I correctly configured the .ini or I'm misconcepting something , even the  version of the instaler (.exe) is updated the appupdate.exe keep downloading the zip from the site everytime it's fired...

The .ini

;The ApplicationToUpdate entry specifies the application that appudate.exe should execute
;after it has finished checking for updates, downloading, installing, and/or running scripts


;Some applications require elevated permissions on Windows Vista.
;If the ApplicationToUpdate requires elevation set the following
;RunApplicationAsAdmin entry to TRUE


;If the ApplicationToUpdate requires parameters to be sent to it
;when running it, they can be specified in the ApplicationCommandLineParams entry


;The VersionSource entry specifies the location of the file containing the version
;number of the update that is currently available to the users. This entry can be a
;local or remote file path, an FTP URL, or an HTTP URL.



;The UpdateSource entry specifies the location of the update file that should be
;downloaded and unzipped if the users choose to update. This entry can be a
;local or remote file path, an FTP URL, or an HTTP URL.



;Sometimes it is useful or necessary for Admins to be in charge of downloading
;the updates and then redistributing them to the other users. The CopyUpdateTo entry
;will cause the appupdate.exe to copy the upgrade files (VersionSource and UpdateSource)
;to the location specifed. Presumably the other users would have their appupdate.ini
;modified so that versionsource and UpdateSource would point to the location
;specified by the Admin's CopyUpdateTo entry. The users' CopyUpdateTo would be left



;The entries in the Message section determine the text that is displayed to the
;user when the Update screen is displayed. The Caption entry is for the caption
;of the update screen that displays in the Title Bar.

caption=Update Available

Open in new window

The gecc2.txt  at net


The installer that keep being downloaded
Thanks in advance!
Olaf DoschkeSoftware DeveloperCommented:
Well, yes, you have a misconception. Look at the original INI.


This does NOT sepcify a patch or update, but the INSTALLED application. This application is what you want to update, not the update itself.

In this case the app to maintain is sampleapp.exe, and that name will stay sampleapp.exe, version independant.

The updatesource is specifying where to get the update.

Bye, Olaf.
Eduardo FuerteAuthor Commented:
Sorry the insistance

But if I decide to update the installer itself (that is also an .EXE) it must work out too, doesn't it?

Since the installer could have a set of files that must be actualized...

So in my conception AppInstaler must check if the installer is out of date
You cannot update running program by itself. You may schedule the update program replacement in Windows Registry or you may update the installer by the application installed - so the installer code is used at two places in fact...

Another option is to start the installer as a batch which can copy the installer from given place before it starts... which in turn makes the installer useless because you may start the application as a batch which will copy the app from given place/subfolder (if present) and then executes the newly copied version.
Olaf DoschkeSoftware DeveloperCommented:
Appinstaller is a simple exe only patching the main application exe, no more no less. That's how this is designed. No matter how you insist on the updater being updatable, the update mechanism is only designed to replace one exe, it's not even designed to execute a setup, which does an update. Appinstaller is the updater itself.

And no matter how you think about this in detail, the INI variable is not meant for the updater, it's meant for the main app. That's how it's designed.

If you don't like that, the design is too simple for you, then roll your own. You may start with this and change it as you wish. It was just a recommendation.

Bye, Olaf.
Eduardo FuerteAuthor Commented:
Thank you for the interactions.

I think to put 'Appinstaller' itself inside the current installer package could be interesting to install it with the other files (system itself/ manual/ etc...)

No matter by now if it doesn't check if it's necessary to update or not the installer package when it's fired.

Every time a user decides to fire 'Appinstaller' (that was installed at their PC as an app) the most recent 'installer package' (with the most recent files and even a more complete AppInstaller version inside it) is downloaded and the local files updated (no matter if it's really necessary or not doing that, by now...).

In meanwhile I'm going to study how to develop the feature of download the package installer only if it's necessary.
Olaf DoschkeSoftware DeveloperCommented:
First of all: The updater only downloads, if the sampleapp.exe.txt on the server side contains a version number higher then the current version.

Aside of that, you can do what you say, but be aware the process is designed to overwrite files right away, and the updater can't replace itself while it runs.

You would rather update the updater from the main app. But what does change in the update process from version to version? If you want to put database updates in the updater, then that's a reason it changes from version to version. But as the database is separate files, your main application could also update the database before starting up in normal usage mode.

The mechanism by Craig simply does the minimum thing, it does only, what an exe itself cannot do. That's all you need, as everything else can also be done by the app.exe in it's new version. The app.exe can update it's database, install ocxes etc. Some of these actions then might require admin rights, but that's needed anyway.

You're thinking too complicated, the only thing the app.exe can't update is itself. And that problem is taken away by this updater, Everything else can be updated as you like from the main application, including a new updater. But the updater doesn't need to change, as it's only job is replacing the main app exe.

You're free to do anything you want inside your main app.exe. Don't think about the update process as a standalone thing doing ALL things related to the update. You separate the update into 1. update the main app.exe 2. do anything else from inside app.exe

You rather want to put anything related to the update into the download and start it to do it. Why? This kind of full setup is just needed initially. Craigs updater in the simple case can even work without admin privileges, so it simplifies the update process.

Also it's not bad, if the app.exe can create and update it's own database. That's self contained and you can offer a new database menu item in your app.

Bye, Olaf.
CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
This is what I do:

Updater checks for new version and downloads it. When the main application is closed it updates it. Inside the new version is a database version. If it's great than the current versions it self-updates the database using CREATE TABLE, ALTER TABLE AND DELETE TABLE.

Also the updater downloads the new updater version and the main application installs it. So in total there are two exes: Application.exe and Updater.exe.
Eduardo FuerteAuthor Commented:

Finally, I made it simple closer to your initial suggestions

1. Created a table called Version in MySQL DB at net provider with the columns: System/ Version Number/ date

2. When the user logs VFP app a connection with the remote DB is done  and a query to the Version table is made obtaining the current version for the app in use.

3. If a more recente version exists the user is asked to make an upgrade, if it's desired the user is directed to the actualization page via  


Open in new window

and the VFP app is closed.

4. Then the user actualize the app in the known way.

I tested, it works well.
CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
Eduardo FuerteAuthor Commented:

I was pretty happy with this solution until I realized it Works only at my machine.... since I couldn't expect the other users have ODBC configured at their stations.

So I've changed a little:

*-- Current app version

*-- download a file with the net most recente version
Local loRequest, lcUrl, lcFilename
LOCAL lnFileHandle && numeric file handle
LOCAL lcLine && define a variable to hold each line
LOCAL m.versao_rede, m.versao_atual
lcUrl = "http://www.espiriplug.com.br/finan2.txt"

*-- Clear the browser cache avoiding to use the last downloaded file 

DECLARE INTEGER DeleteUrlCacheEntry IN wininet STRING lpszUrlName
= DeleteUrlCacheEntry(m.lcURL)

lcFilename = m.DRV_LOCAL+"\finan2.txt"

loRequest = Createobject('MsXml2.XmlHttp')

*-- Open this file

lnFileHandle = FOPEN( m.DRV_LOCAL+"\finan2.txt")

IF lnFileHandle <> -1

	DO WHILE NOT FEOF( lnFileHandle) && loop through the file
		lcLine = FGETS( lnFileHandle) && store each line in lcLine
		m.versao_rede = VAL(ALLTRIM(lcLine))

	FCLOSE( lnFileHandle) && don't forget to close the file

*-- Current app version without "."
	m.versao_atual =VAL(ALLTRIM(CHRTRAN(m.versao, CHRTRAN(m.versao, 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ',''),'')))

*-- Compare the versions and if needed ask if the upgrade is desired.
	IF m.versao_rede > m.versao_atual

		IF ALERT("CUIDADO","SN ",10,10,"Há uma versão mais atualizada, deseja atualizar o sistema ?")="S"
			=ALERT("PARE", "OK", 10, 10, "Atenção: Nesse momento o sistema irá sair do ar e vc será conduzido à pagina de atualização do site.;
			                             Simplesmente siga as instruções na página do site para atualizar o sistema")

			= executeshell("http://www.espiriplug.com.br/Corrige_Financeiro_v2.php")



Open in new window

I used Olaf's code posted at  Tek-tip fórum

Now I'm waiting how it Works at users stations...

An user just told me it Works fine...
Eduardo FuerteAuthor Commented:
After interact and reflect I found a solution that Works well

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 7
  • 4
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now