Programming 'Check for Updates' Functionality

[Mike]

Hello,

I just started working for a company which sells an Access 2007 to retail
customers across the country. I've been tasked with building a 'Check for
Updates' function within the new production version. Basically it should
work as most 'check for updates' functions do - It should check a web URL and
identify whether or not a new product version exists. Could someone give me
some general direction on how to accomplish this via Access...is it even
possible at all? At this point I'm just looking for a high-level conceptual
idea of how to do this, as I've never done this type of thing before.

Thanks

 

[Stefan Hoffmann]

hi Mike,

It should check a web URL and
identify whether or not a new product version exists. Could someone give me
some general direction on how to accomplish this via Access...is it even
possible at all? At this point I'm just looking for a high-level conceptual
idea of how to do this, as I've never done this type of thing before.

hmm, you have already your "high-level conceptual idea". Just code it.


mfG
--> stefan <--

 

[Tony Toews [MVP]]

I just started working for a company which sells an Access 2007 to retail
customers across the country. I've been tasked with building a 'Check for
Updates' function within the new production version. Basically it should
work as most 'check for updates' functions do - It should check a web URL and
identify whether or not a new product version exists. Could someone give me
some general direction on how to accomplish this via Access...is it even
possible at all? At this point I'm just looking for a high-level conceptual
idea of how to do this, as I've never done this type of thing before.

I plan on setting up a very small, several hundred byte, INI file with
the latest version number, file size, zipped file name and description
of update in it.

Whenever the system does the Check for Updates it will download the
INI file and compare versions. If a new version it will use the
appropriate code to download the file. I will then use the free
Infozip DLLs to unzip the file and process.

Compression DLLs, OCXs, etc
http://www.granite.ab.ca/access/compression.htm

I also keep the version number of the front end and the back end in
tables in the two MDE/MDBs respectively. Thus I can ensure that the
two are in synch.

Now one problem is what if you are on a network. And one system has
the latest version and another doesn't. Do you force the other system
to check for updates? Do you put the downloaded zip file on the
server in a subfolder off the BE MDB or similar so only one user does
the check for updates? What if two users are simultaneously doing the
check for updates?

There are a few interesting problems here but all solvable with a
bunch of work.

Note that I plan on adding this functionality to users of the Auto FE
Updater sometime soon. Although this will be on a fee basis.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[David C. Holley]

If you're dealing with customers and giving them the ability to check for
updates then...
I would go with a custom database property that captures the version number
of the local application and then download a simple text file with the
version number of the most recent version available. Then open the text file
and compare it to the value in the custom property.

If its an internal application where all users and developers have access to
the same network, depending on the nature of the application you have a
couple of options...

1) If its just a Front End .mde file, create a vbscript which copies the MDE
from the server to the users local machine and then launches it. Train the
users that the VBscript is the means by which to launch the application.
This ensures that they're always running the most recent MDE file. The
VBScript can be designed to use IE to create a browswer window in which
status updates are provided to the user such as 'Please wait...', 'Checking
files...' etc.

2) If its more than a Front End, still go with the vbscript, but modify it
to check a custom property on the local Front End to the a custom property
on the server Front End and if they don't match then execute the code to
copy the new Front End to the local machine and make any changes, install
any additional files needed.

 

[Tony Toews [MVP]]

If its an internal application where all users and developers have access to
the same network, depending on the nature of the application you have a
couple of options...

1) If its just a Front End .mde file, create a vbscript which copies the MDE
from the server to the users local machine and then launches it. Train the
users that the VBscript is the means by which to launch the application.
This ensures that they're always running the most recent MDE file. The
VBScript can be designed to use IE to create a browswer window in which
status updates are provided to the user such as 'Please wait...', 'Checking
files...' etc.

Or use the AutoFEUpdater which does all these things for you and more
without involving IE.

2) If its more than a Front End, still go with the vbscript, but modify it
to check a custom property on the local Front End to the a custom property
on the server Front End and if they don't match then execute the code to
copy the new Front End to the local machine and make any changes, install
any additional files needed.

The AutoFEUpdater can copy multiple files as well. More functionality
on that coming soon.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/