Rosemary said:
Larry,
Please clarify.
1. After creating the application, I split the database into a front-end
and
a back-end. Then I package only the front-end but also include the
back-end
as a separate file. Is that correct?
Actually the suggest being made is that you don't use the package system
once you installed the runtime. Keep in mind that the runtime is not any
different than the full version of MS access (of course the only exception
being that the design tools are removed). Once they've download and install
the runtime you can simply e-mail them the front end file. In other words
if you have two machines running access in your office now, how do you move
the application from one machine to the other? You might burn the front end
file to a CD, you might zip it up and send via email. You might place it
on a usb jump drive.
So the only problem here is to get a file to the end user. This problem is
no different than if you have to send them an excel sheet, or PowerPoint
presentation or anything else. You simply need to get them a copy of this
file. Some people do attempt to use the package wizard to just update the
front end file, but I found it to be very problematic in that regards, and
I think it's overkill for just the simple sending of a client a little
file.
2. When the user installs the package, it creates an ACCDR file. How does
the user link the front-end to the back-end at this point?
Well now that we clarified that we're really just copying a file to the
target computer, the problem and solution still remains the same:
You will need to write some code that links the front end to the back end.
Every single access developer on the planet who runs a split database will
have some soltuion in their bag of tools. Most if not all this is taken the
code to re-link from here:
You can use the code here to re-link.
http://www.mvps.org/access/tables/tbl0009.htm
Furthermore, what we often do is pop up a file dialog box and let the user
browse to the back end. You can use the built in file dialog in access
2007 or you can use the API code here:
http://www.mvps.org/access/api/api0001.htm
So between the above to routines you can cobble together in a short time a
set of routines that will run when your application launches. If the back
end is not found, then you can pop up the file dialog browse.
What I usually
do is attempt to open a table and if it errors is out (then the link is
bad). I simply then run my re-link code that's based on the above.
Furthermore I think it's way too much work and training to get "end" users
to browse to the back end. Therefore what I do is save the location of a
backend in a text file that's in the same location as the folder for the
front end. What happens is that in my re-link code I look for this text file
and open it up to read the location of the back end (if you don't want it or
the trouble of using a text file, you can create a table that stays in the
front end of your application with one reocrd that holds the path name to
the back end).
Whatever solution you use is really up to you, and there is
thousands of different scenarios in which one soluton for me might not be
the best for you. Only you can best decide if you want users to browse to
the back end location, or you want it put that location in a table or
some such.
For example in my access applications the following set of screen shots is
how they upgrade their software:
http://www.kallal.ca/ridestutorialp/upgrade.html
How sophisticated and fancy one gets is really up to you. In the above I
am using Inno + a ftp code library to download the front end. (the code
for that can be found at the access web).
http://www.mvps.org/access/
At the end of the
day you are simply going to give the end user a file (the new front end). so
the problem we are actually solving here is how can we get a file to another
user. This file could be PowerPoint, excel, or this case an access front
and. This is not a hard hard problem to solve but one can get pretty darn
fancy in solving the problem of "here is a file". It goes without saying
that if we can't get a simple file to a end user then one has to start
questioning what kind of computer skills we have.
3. If I make changes to some forms, macros, etc., wouldn't I have to
repackage the front-end again? If not, how would they replace the ACCDR
front-end file?
What do you do when you update a word document? How do you get that
new word document to the users? As I said above the problem is exactly
the same of giving the user a new front end. The packaging wizard does
absolutely nothing special to your particular accDB file that you're using.
Once the users install the runtime, you can drag and drop as many access
database files onto that users computer and they can simply double click on
any mdb or accdb and it will as if you had access installed (minus a course
most of the interface bits that you have to build yourself and are missign
in the runtime).
4. If I do have to repackage the application, is there a way to
automatically delete the prior version without the user having to manually
access the control panel and remove the package?
This is exactly one good reason why I'm suggesting to avoid using the
package wizard for updates to your software (it is a pain and most of us
don't know how to get around that the issue of having the user having to
remove the package first). Even worse if you to get around the install
issue I don't know of a way to have the wizard overwrites existing files
(on the other hand since the wizard doesn't overwrite files, you'll never
accidentally overwrite their database back end, and that could be a
horrifying disaster with serious liability and consequences).
So, probably at the end of the day is likely a good thing that the package
wizard is very difficult if not next to impossible to get it to overwrite
files. I can only imagine the droves of people here telling the stories
about how the stupid package wizard over wrote their clients data. what
would happen if you actively ran the package wizard install again a few days
later after having a bunch users enter all the data? What happens if the
client runs the wrong update (say the original when you sent them with both
the front and back end). In fact the more I think about this it makes sense
to the package wizard don't let you do this easy at all.
For the most part I used to use the commercial version of winzip which you
often see for shareware applications when you download softwaer from the
net.
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. And, it free.
You'll find the inno installer here:
http://www.jrsoftware.org/isinfo.php
Note the above link also has a good number of support 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.
Again I can't stress that the other way is to simply e-mail them the
file zipped up and give them instructions to unzip it into a correct folder.
However i do use Inno in place of the package wizard for additional updates
because then they don't have to remove the previous version, and they don't
have to "copy" the front end to a location (inno unzips it to the location
I want).
I would also suggest that you consider getting a copy of virtual PC, as you
need to do a significant amount of testing of the runtime and your
re-link code in a true runtime environment. Remember, you REALLY
need to spend a lot of time testing this since too many frustrations
from your client and they will quickly lose faith in your software.
It's kinda like when you have serious problems with a car, you tend to lose
faith in that car and want a differnt one (you don't know if that cars
reliable to make the trip for you anymore) What this means now's you have to
think of your end users and their frustrations, and in a sense put on a
developer's hat.
