CODEWITHSUNDEEP
ms-access
Nita
Nita

Reputation: 205

How to update front-end for MS Access 2007

I was able to split the database and used packaging solution to distribute the front-end. I tested it the exe file and it worked fine. Now I am updating the forms and I cannot figure out a way of updating just the front-end (backend is on the server) wihtout going through the new installation of the new package. I did create the template file while going through the process of packaging the database.

I found this website but was afraid the unzip the file. Have any of you use this tool? http://www.btabdevelopment.com/ts/freetools Thank you

Upvotes: 3

Views: 9529

Answers (1)

Renaud Bompuis
Renaud Bompuis

Reputation: 16806

Some existing tools

Here is a list of deployment tools for Access front ends:

The one you listed could also help.

More information on deployment

The issue is that there is no single way to update an Access application.
As you discovered, the packaging tools are nice, but they don't really take care of the most important, and complex, part of deploying software: how do you update an existing installation?

Access doesn't have a good story here, so there are many custom solutions, each with its flaws and advantages.

You were right that in any case, you must separate the backend database, containing only the tables, from the front-end, containing the code, forms and reports. The front-end must be deployed to each user: the rule being that a front-end is meant to be used by a single user only.

What's in a good updater

So, what are the characteristics that you want in a good update story:

  • User should not have to do anything: you want the user to get the new version of the front-end as soon as it is made available, automatically.
    This could mean that your front-end could check if there is a new version available on a remote folder before it allows the user to login or star any work.
    If a version is available, it is then fetched and deployed.

  • Sometimes, because your development environment may be different from the user's environment (different server names, different shared folders, etc), you may also need to re-link the tables in the front-end to the correct path of the back-end after deployment.

What I am using for my deployments

For a few years now, I have perfected my own system that works without a stitch.

  • Instead of launching the application directly, when the user click the application icon, a small launcher application is started.
    The launcher I use is a simple Click-Once application (so it can auto-update) written in .Net.

  • The launcher is responsible for ensuring that the main application is only running once, and also for checking and deploying new versions (or downgrading them) when updates are made available.

  • Updates are simply packaged into zip files that contain all the files necessary for a new update.
    The name of the file contains the version number, like myAppFE-2013-08-01.zip so that sorting the list of clients packages by name would make it easy to pick the most up-to-date package.
    All these front-end packages are stored on a shared folder on a server, for instance if my backend database is in \\myServer\myApp\DB, the front-end packages could be kept in \\myServer\myApp\FE.

  • When the launcher detects that a new package is available, it deletes the existing folder of the front-end on the user's machine and unzip the new package there instead.

  • Once the launcher has finished its tasks, it just launches the application frontend.

  • When the application front-end is started for the first time, it can do more checks to re-link tables if they point to the wrong location.

Notes

  • An alternative for detecting a new package would be to keep a small text file on the server that would contain the filename of the most current package.
    Whenever a frontend is started it could check if the package name it is running is the same as the package name listed in the file. If not, then an upgrade/downgrade is necessary.

  • One of the advantages of this solution is that once the Access Runtime is installed, users can run in normal user session on the machine, without ever requiring administrator rights: the click-once launcher doesn't require any admin rights and if you deploy your access front-end under the user's %APPDATA% folder, you do not need elevated rights to update your front-end at all.

  • The first time you deploy, your launcher should also be responsible for registering the location of front-end folder as a Trusted Location so that Access allows it to run without VBA/Macros being disabled.
    These are just a set of registry keys you can easily add under HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Access\Security\Trusted Locations\ (the exact registry key depends on your version of Office and whether you are on a 32 bit or 64 bit system).

Upvotes: 5

Related Questions