Distributing Upgrades

[Robbo]

I have an MS Access 2007 application distributed to about 40 users around the
country. From time to time I need to send an upgrade to the front end and I
am looking for an efficient way of distributing given the following
constraints.
1. My users do not have the ability to run exe files
2. The front end is about 6MB which is too large to e-mail to them so I need
to zip the files.
3. The virus scanner they use will not allow them to receive zip files so I
need to rename the zip file as a txt file
4. Their virus scanner prevents me from using a FSO in my code to unzip the
file
5. They are using MS Access Version 12.0.4518.1014. My original install
discs are a later version so I cannot send them a accde file to keep the size
down


Hence at present I have to send them a zipped accdb file renamed txt and get
them to rename it and unzip it, something that about half my users find too
difficult to do. Can anyone suggest another way of distributing this
application or am I right in assuming that all my pathways have been
roadblocked.

 

[Tom van Stiphout]

On Mon, 15 Jun 2009 19:12:03 -0700, Robbo

Re 1: Yes they do. They habitually run msaccess.exe.

-Tom.
Microsoft Access MVP

 

[Arvin Meyer MVP]

I think that your present methodology is the best possible solution. You
might create a carefully made YouTube tutorial using something like
Camtasia:

http://www.techsmith.com/camtasia.asp

or BB Flashback:

http://www.bbsoftware.co.uk/

to gently walk them through the process. Or even use one of the programs
like GoToMyPC to do it for them.

 

[Albert D. Kallal]

1. My users do not have the ability to run exe files

Really, then how do they run word, excel or access then?????
(I don't believe this issue, since they then would not be able to run
anything then).

As for zipping, I use the following zipping code that is "native" to
ms-access
and does not use the fso.
http://www.members.shaw.ca/AlbertKallal/zip/index.htm

5. They are using MS Access Version 12.0.4518.1014. My original install
discs are a later version so I cannot send them a accde file to keep the
size
down

I don't think the above will prevent you from sending a accDE file.

When you're updating their software, you're simply providing a new front
end. That new front end is a standard file. I am not really convinced that
sending a accDE will be More problematic than sending an accDB. However if
this is really a problem, then you REALLY need to do a DE-compile before you
send the accDB anyway Note that if you do a de-compile, then you find that
you accDB file will likely be smaller as the accDE.

As you said, since you users can not run ,exe files, then this means they
can't launch word, they can't launch excel, and they can even launch the
browser. Keep in mind that all those files are.exec files. So realistically
you're in a situation where the people really can't use their computers??

I kind of must assume you are talking about email attachments?

In this case, just send them an inno script that is .exe re-named as a .txt
file. Have them save the .txt file, and then have your "upgrade" button
rename the file as .exe. You can then execute to that .exe, and then do a
application.Quit to exit access.

At that point, the inno screens will do the upgrade and you not be running
the access application.

Another way is 100% automated and NOT send the file via email.

(you can the mail them to inform them that a upgrade is available, and
that's exactly what I do)

I would place a upgrade button in your access software. You would click on
this, and this would exit the current accDE file, and run one called
"upgrade.ACCDE" on your computer. You can then launch this by going
application.FollowHyperLink path name to upgrade.accDE.

The access application can then do a http download of your new front end. As
you mentioned, the file extension could be anything you want in case of
virus scanning issues. You then un-zip the file to the correct location and
copy it over the existing front end....

If you look at the series a screen shots I have, to upgrade my software I do
almost exactly the above:
http://www.kallal.ca/ridestutorialp/upgrade.html

Hence at present I have to send them a zipped accdb file renamed txt and
get
them to rename it and unzip it, something that about half my users find
too
difficult to do. Can anyone suggest another way of distributing this
application or am I right in assuming that all my pathways have been
roadblocked.

Well,if they can't run .exe files, then you have a problem.

For a ftp download, you can use:
http://www.mvps.org/access/modules/mdl0015.htm

And, for a integrated http download, you can use:
http://www.mvps.org/access/modules/mdl0037.htm

(I using a version similar to the above).

So, doing a download from a web site would be a possible solution here.

You can use any web space you have....most Internet providers have some free
web space that is provided with your e-mail account, so you could use that
for hosting this upgrade file.

You might want to clarify what the restrictions are on running a .exe file?
Perhaps you email a inno.exe file (named as a .txt file), and have them save
it. You then have your "upgrade" code rename this .txt to an .exe and
execute it. (I suppose you could also have your users rename the.text file
when they say that, and then simply click on it, and the upgrade would show
series a screen shot just like my example that follows below:
(if you look at the series a screen shot, the standard windows looking
install panels are actually generated by the inno system, however the first
part with the download progress bar is from my custom progress bar and
custom download code that I use).

I give a sample upgrade script for inno in the following article on
upgrading access 2007 runtime applications here:
http://www.members.shaw.ca/AlbertKallal//RunTime/Index.html
--

So, I do think you can automate this whole process right down to a on-click
upgrade affair, and not even use email....


Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(e-mail address removed)

 

[Robbo]

Hi Tom,
Of course you're right. I must get my users to try that option again.

 

[Rick Brandt]

I have an MS Access 2007 application distributed to about 40 users
around the country. From time to time I need to send an upgrade to the
front end and I am looking for an efficient way of distributing given
the following constraints.
1. My users do not have the ability to run exe files 2. The front end is
about 6MB which is too large to e-mail to them so I need to zip the
files.
3. The virus scanner they use will not allow them to receive zip files
so I need to rename the zip file as a txt file 4. Their virus scanner
prevents me from using a FSO in my code to unzip the file
5. They are using MS Access Version 12.0.4518.1014. My original install
discs are a later version so I cannot send them a accde file to keep the
size down


Hence at present I have to send them a zipped accdb file renamed txt and
get them to rename it and unzip it, something that about half my users
find too difficult to do. Can anyone suggest another way of distributing
this application or am I right in assuming that all my pathways have
been roadblocked.

Assuming the others are correct and they really can run exe files here is
what I just set up on my latest distributed app.

I use an HTTPRequest (MSXML library) to ask a web service what the latest
version of my app is. That is compared to the local version and when a
newer version is available I ask if the user wants to download the update.

If they indicate that they do, then I call a URL to download the file and
quit the app. The file is a self-extracting zip file that is
automatically set up by default to unzip to the correct folder (assuming
they used the default install location). The self-extracting zip file is
executed, they press the unzip files button, and then relaunch my
application.

I set this up because as you are seeing, Emailing attachments is becoming
difficult and explaining how to save to disk and then change file names
is just not worth the trouble for many users. Especially with the
totally retarded Windows default setting to hide file extensions.

 

[David W. Fenton]

if
this is really a problem, then you REALLY need to do a DE-compile
before you send the accDB anyway Note that if you do a de-compile,
then you find that you accDB file will likely be smaller as the
accDE.

Well, to get the size reduction, you need to decompile and then
compact. I would never send out an uncompiled front end, so I'd
compile and compact before sending it out. This would not be as
small as the compacted decompiled database, but it should be more or
less the same size as the MDE.

 

[Tony Toews [MVP]]

I use an HTTPRequest (MSXML library) to ask a web service what the latest
version of my app is. That is compared to the local version and when a
newer version is available I ask if the user wants to download the update.

I'd do the above but have a small INI file they can download which has
the latest version in it. If newer, etc, etc. No web service
involved. This doesn't require anything other than some kind of web
site updating.

Tony

 

[Robbo]

Thanks for the tips. I will make use of these suggestions for training.
However I think some of the other solutions have solved my problem. Thanks
for your input
--
Cheers
Rob

I think that your present methodology is the best possible solution. You
might create a carefully made YouTube tutorial using something like
Camtasia:

http://www.techsmith.com/camtasia.asp

or BB Flashback:

http://www.bbsoftware.co.uk/

to gently walk them through the process. Or even use one of the programs
like GoToMyPC to do it for them.

 

[Robbo]

Thanks for the tips. I always compile and compact before I send out my app,
though I don't always decompile first. However it is still too big. These
users have a very low speed broadband setup with a very small download limit.
Zipping the files makes a substantial improvement. Now I have a workable
solution

 

[Robbo]

Thanks for the tip.
--
Cheers
Rob

Assuming the others are correct and they really can run exe files here is
what I just set up on my latest distributed app.

I use an HTTPRequest (MSXML library) to ask a web service what the latest
version of my app is. That is compared to the local version and when a
newer version is available I ask if the user wants to download the update.

If they indicate that they do, then I call a URL to download the file and
quit the app. The file is a self-extracting zip file that is
automatically set up by default to unzip to the correct folder (assuming
they used the default install location). The self-extracting zip file is
executed, they press the unzip files button, and then relaunch my
application.

I set this up because as you are seeing, Emailing attachments is becoming
difficult and explaining how to save to disk and then change file names
is just not worth the trouble for many users. Especially with the
totally retarded Windows default setting to hide file extensions.

 

[Robbo]

Thanks for the suggestion. Actually my code already downloads an ini file but
at this stage it just reminds them to install the update I have sent them.
Now I will be able to automate the whole process

 

[Rick Brandt]

I'd do the above but have a small INI file they can download which has
the latest version in it. If newer, etc, etc. No web service involved.
This doesn't require anything other than some kind of web site updating.

Tony

In my case the application makes heavy use of my web service for data
exchange anyway so adding to that a version check was pretty simple.

 

[Tony Toews [MVP]]

Thanks for the suggestion. Actually my code already downloads an ini file but
at this stage it just reminds them to install the update I have sent them.
Now I will be able to automate the whole process

Ok, then download the zip file containing the updated FE. Then use
the free, open source InfoZip DLLs to unzip the files. Links to VB
source and the DLLs are in the first paragraph at Compression DLLs,
OCXs, etc
http://www.granite.ab.ca/access/compression.htm

Tony

 

[Robbo]

Thanks Tony. That's exactly what I am in the process of doing. Thanks for
your solution