"Jay Oken" <okenconsulting@[EMAIL PROTECTED]
> wrote in message
news:OORgi6ElIHA.5080@[EMAIL PROTECTED]
>I have version 1 of a database with a split front-end and back-end. When
I
>get to version 2, how do I tell the ADE installer not to overwrite the
>back-end if it exists but to install the back-end if this is a first time
>installation of the program.
>
> Along the same lines, can someone point me to do***entation on how to
use
> the product and upgrade codes. I am not finding the general help very
> useful.
>
There are several notable limitations of the package wizard system that
make this process difficult.
The first and foremost limitation of the package wizard is that it has no
ability to overwrite existing files that you installed. Because of this
limitation, it means that you simply have to delete, or uninstall the
previous front end FIRST that you've setup. Because of this significant
limitation, I'm going to suggest that you don't bother with the package
wizard to distribute an ***updates*** to your new front ends.
Also, the pw creates quite a few files, and that makes it rather painful
to have some kind of downloadable executable that you run for the install
on
the end
user's machine. If you look at the contents and the resulting files that
produced by the package wizard, you'll see it's nothing remotely close to
that of a single file that you can download, or copy.
Once again because of this limitation, the package wizard don't allow you
to
setup a single file to download. Obviously for downloading from the
website
this becomes very problematic, and therefore once again I suggest because
this limitation you avoid using the package wizard to update the new front
end.
Furthermore if you think about this, an update to your front and is really
only a simple mde (or accDE) file copy from your web site or package
source
to overwrite the old front end (and, you are using a mde file..right???)
So, updates are just a simple file copy here. The package wizard that has
all of the above limitations and can't even produce one single file that
you
could download and unpack and then install. So, the PW is an MSI install
with all kinds of extra baggage and folders and files.
Hence, for the last 7+ years I have done the following:
I first build a runtime package and setup. This is ONLY the runtime
install.
You might only install a "readme" text file with this. No matter how you
slice this, the goal here is to get the runtime system installed on the
end
computer. Once this install is done it should stay in place for years, and
it is only a one time process. This is the only instance where I actually
use something produced by the package wizard. Once we've done this process
and I have the runtime installed, we'll never bother with this whole thing
again for the next 5 or more years from the clients point of view. For the
IT person, you might build and send them a copy of this runtime disk that
you made. (one thing the package does right is to create a standard auto
run CD).
Once you have the runtime installed on that computer, the next goal is to
setup something that allows you to install you new front end, and of
course
the many frequent updates you going to have to this front end. For a long
time I used to use a paid copy of WinZip (you can find that here
www.winzip.com). It is only a few dollars For registered copy and is well
worth it.
However I then discovered the free open source installer who called inno.
The advantage of inno over WinZip is that you can package a bunch of files
into a file for download, and it also has the ability to set up shortcuts
etc. on your desktop, something that WinZip it did not have.
You'll find the inno installer here:
http://www.jrsoftware.org/isinfo.php
Note the above link also has a good number of sup****t and very active
newsgroups that can help you with your install setups also. I highly
recommend this installer, and it is free. and, for questions, check
out the newsgroups there also.
Because the inno installer produces a single .exe file that unpacks, then
I
actually placed a copy of this file on my website. You then place ONE line
of code in my application behind a button that does the application follow
hyperlink to that .exe. I've done that for years, and it means you can
have
a one button update right inside your software menu. ( and you can do the
whole process with about one line of code in access, which is again really
terrific).
The whole process has become extremely slick, and easy from an end user's
point if view. Take a look at the following series of screen shots as to
how
my users now update their MS access software:
http://www.kallal.ca/ridestutorialp/upgrade.html
The inno script that runs after the download looks like:
[Setup]
SourceDir=c:\Do***ents and Settings\All Users\Application Data\RidesL
AppName=Rides Reservation System
AppVerName= Rides 2.0
DefaultDirName={commonappdata}\RidesL
DefaultGroupName=Rides
Compression=lzma
SolidCompression=yes
DirExistsWarning=no
DisableDirPage=yes
DisableProgramGroupPage=yes
Uninstallable=no
[Files]
Source: "RidesXP.mde"; DestDir: "{app}"
*-----------------------------------
As you can see this script to update and copy overwrite the old front end
is
very simple.
So, don't bother with PW for updates, it not worth the hassle...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@[EMAIL PROTECTED]
|
