HCS Consulting Group.
We make Complex Systems simple

Deploying updates to your software in a Runtime environment for Access 2007

By Albert D. Kallal
Friday, December 26,2008

How to update your Access application when deployed as a runtime.

One of the really great features for access 2007 is the developer tools and runtime system is free of charge.

While Microsoft CEO Steve Ballmer is often chided for his famous "developers developers developers" rant, it is absolute 100% true that developers are one of the main reasons for the success of Microsoft.

Left: I took this picture of Steve giving a talk to us developers during the MVP summit. What a great talk by Steve. Steve clearly understands that developers drive the software industry. Steve's talk was passionate about our industry, but he really is nothing like the developers rant video in person. Steve is a rare CEO's who tells things like they are.

 

 

 

 

 

 

Steve's speeches are packed full of great advice and vision and are very entertaining.  If you ever have a chance to attend one of his talks, I strongly suggest you don't pass up the opportunity.

What the runtime system is, and is not
Thereís often a significant amount of confusion as to what the MS Access runtime system is, and what the packaging wizard system does for you when you deploy an Access application.

Probably the most often cited misconception about the runtime system is it turns your access applications into a stand-alone executable file. I think this would be cool if we could do this, but on the other hand MS Access software simply doesnít work this way.

The runtime system
The runtime is simply a stripped down version of Microsoft Access that you install on the target computer. I canít stress this issue more strongly, and you have to stop and think about what Iím saying here. The runtime is a version of MS Access to that you install on the target computer. So you have to keep in mind that you're actually installing a version of MS Access on the target computer.

After the runtime version of Access is installed on the target computer, you can simply execute and run your application(s) that youíve built in Access. That application will remain an mdb, mde, or for access 2007, an accDB/AccDE file. Keep in mind in mind there is no special connection between the runtime and your application you developed. In other words, once that target computer has the runtime (or full version) of Access installed, then any access application can simply be copied to the target computer. That mdb/accDB file will simply launch when double clicked on. In other words to run your application, you donít modify your application, you donít change your application, or nothing special occurs to your particular application. Your accDB file remains separate from MS Access.

Ok, so you simply run your application by double clicking on that file and Access will launch that application like any other windows application. Hence, when you click on a Word document, "Word" is launched. It is the file extension that determines this action like for all Windows applications, and is the same with the Access runtime.

What this really means is that you donít really install your software on the target computer, but simply COPY your front end to that computer **after** the runtime or full edition of MS Access has been installed.

The runtime edition of access is simply a version of MS Access that you install. The runtime install size is nearly as large as the full version of Access. For access 2003 itís about a 34MB install, and for Access 2007 itís about a 54MB install. The runtime is thus inappropriate for a distributing a "little" table of data when users will not have MS Access installed. If you looking to distribute a small file with a table of information, you best use Excel as your end users are far more likely to have excel installed then MS Access. MS Access being quite a large download makes it inappropriate for shareware utility type programs. I should point out that five or six years ago, a 30 to 50MB download was considered very large. Today with most consumers and people having high speed Internet, this size issue of the runtime is much reduced but still requires consideration on your part.


Differences between the runtime and full edition of Access

In a nutshell the major difference between the full and runtime is the runtime does not allow design changes to code, forms, or reports. In fact this is pretty much where the name run-time comes from, as it allows you to run your applications, but not make design and modification changes to that application. You as a developer need to spend some extra time in providing a user interface since the runtime is limited in this regards. When your application starts up you canít expect the user to wade through a whole list of forms in a navigation pane and know which form to select. In other words the amount of work to prepare your application for runtime deployment is really going to depend on how polished up your interface is. If you as a habit already have a custom startup form, have custom menus or ribbons built in, then you are well down the road to having an application that will behave well in runtime. If your designs already hide much of the MS Access interface from the user then your application is well on its way to being deployed in the runtime system with few modifications required. Your application thus needs to run in such a way that the user never needs any of the built in menu options that a user would expect to have when running the full version of access.
 
While I said at the start of this article you donít have to modify any existing code in your application, you most certainly have to make some extra effort to provide an interface for your end users. This kind of makes sense because the person will not have purchased MS Access nor likely have training in using MS Access. Hence as a developer you have to make extra effort to build a startup form and a user interface for that application. For example if you need to export some data with the full version you likely use the wizard and answer a bunch of questions. For runtime you don't have wizards and thus you must provide a button and interface that does all the export steps in code. In other words you need to make your application "easy" to use.  For exporting data you thus need to provide that menu item + some code. Thankfully most built in options from Access menus have equivalents in code that work in the runtime. So you don't have to write the export routine in code but you have to provide the menu + button + some code  that "calls" the access features that allow you to export that data. So most features are available but the user interface to that feature must be coded by you.


In summary (runtime)
You can download a copy of the Access runtime from the Microsoft site. After you install this runtime on the target computer, you can now simply copy your access applications to the target computer. You then can double click on those access files as you always done in the past.

The link to the free runtime for MS Access can be found here:
http://msdn.microsoft.com/en-us/office/bb229700.aspx

 

The above has some additional links that point out considerations as to how your application will look and run in a runtime environment.


The Package Wizard
 

Package wizard: the bad

Using the package wizard to update your software is difficult, and in fact not really recommended.

Package wizard: the good

The package wizard and runtime is now free. Ok, that is about the end of the good part too!

If you been reading the above, and following along with me, at this point you just realized that is not necessary or even a requirement for you to use the package wizard with MS Access to deploy your applications. In other words ask yourself how you been deploying and updating your applications to existing users before you even started using the runtime? (answer: You simply were giving them a copy of your new updated front end).

The main purpose of the package wizard is to allow you to build what is called a Windows install package. This simply means that you can take your MS application and produce a standard "MSI" install. The PW has provisions for creating folders on the target computer and for creating a shortcut on the users desktop. So the PW eliminates having to write out a whole bunch of instructions to your users as to where to place your application on the target computer. The PW system that takes your application (mde or accDE) and wraps it into a Windows install package. The resulting standard Windows install package can then be burned to a CD or DVD for distribution to your end users. You end users can then use that CD or DVD to install your Access application. Remember the install process is still simply the copying of your application to the target computer "after" the runtime been installed. In other words were using a pretty complex and heavy system to simply copy a file to the target computer.

There are some advantages to using the PW system. You may want the user to place your front end accDB/mdb file in a particular folder. Using the PW means you don't have to email a whole bunch of instructions on how to do this. For the most part the PW is used to reduce the pain of users who have go through a series of steps to get their application running on their computer.

Another useful feature the PW is to include the runtime system as part of the install. However this means youíre talking about that large runtime system which is in the 50MB range size wise.

There are really not a lot of advantages to using the PW since any subsequent or future updates to your software can be accomplished by a simple file copy of your new front end onto the target computer.

I recommend you stay away from the package wizard for deploying updates to your software. A major limitation of the PW is the difficulty to overwrite files during an install. This limitation is likely a good thing since overwriting existing database files on your target computer would be a nightmare of liability of you having destroyed or overwritten customers EXISTING data. We should stop and take a breather here. Think very carefully when youíre going to use something that messes with someone's computer. This is NOT your're computer you messing with! You have to exercise far more caution and consideration when running some kind of update process that can overwrite things on a customerís computer. I really cannot think of anything much worse than an install system that overwrites your customerís data files. So youíre messing with someone elseís computer, and that means you have to be careful.

Any time we need to update our software, we are required to overwrite files on the target computer. Even worse is that the PW usually requires you to un-install the previous version of your software. If that previous version was just some code then we not really too worried here. However is it common in Access that we are dealing with code + a data file. If that previous version of your software has both a front end part + the back end part (data) then MAJOR caution here. If you successfully un-install your previous version of software you wind up DELETING the customers data file. Keep in mind that a new install can potential OVERWRITE clients data and an uninstall of the previous version could also DELETE the clients data file! Because of limitations of the package wizard in this regards I suggest that the package wizard should only be used to install your initial application.

If you re-create your package then you find the install will inform you the application is already installed. You will now be asked to un-install the "previous" application first. This message the PW throws up is confusing to your users. Worse, often users will not have that original CD/DVD used to install this package. However do you really want customers to un-install the previous version and in the process also delete possible data files? Again, stop and think about this! So both installing can overwrite data and uninstall can delete previous data.

I should point out that if you donít include the runtime in your PW install, then users are not asked for the previous (original) install disk. This is a possible work around if you are going to use the PW in place of what I suggest in later in this article to update your software.

I will not stand here and try to sugarcoat that the PW is limited. I think the PW should have more options and it falls short for developer requirements. In fact you really can't use the PW except in those cases where you have near total control over the target computer where the install is to occur. Lack of easy options to overwrite existing files from a previous install is a real shortcoming. Prompts for un-installing previous versions is also a a pain for your users. We canít really complain too much about the PW since this system used to cost about $600-$700 dollars and now itís completely free. So the runtime system is a nice gift to us developers despite the PW limitations.

There is a real nice silver lining here because the problem before was obtaining the runtime and package tools. Now that the tools are free, with just a few hours of your time you can setup and build something that overcomes most of the above PW limitations with relative ease.


Example install

I have an example install here: click here

The above install is how I update users software.

As I suggested you should not include the runtime as part of the Access package for your installs. The reason for this is twofold. The first reason is that the Access runtime is quite large of an application to install on your users computer (54 megs in size). If you try the above sample install, you note how fast the download time was. On high speed internet the above only takes a few seconds since we did not include the runtime. The second reason and advantage of NOT using the PW is the sample install was a SINGLE file. This makes your installs and updates rather easy as you can simply e-mail this single file or use a simple web page to support your application as I have done above.

In the future when I issue bug fixes and updates it is a simple matter to have users run the above install again. Hence we use this simple install over and over for each update issued. Keep in mind the above example will overwrite your existing application each time it is run. However the data part is un-touched because the above is a split application.

Above install is a single file

If you been following along with me here, another limitation of the package wizard is the resulting package is NOT a single file, but contains several directories. The package wizard thus does not create a single file. The PW requires you to give your end user several files on a disk or some type of shared folder for those installs. If you use a cd or DVD then this is not a problem and the package wizard does a decent job in this regards. Problem is today with internet and a simple web page like above why bother with creating and sending out a cd/dvd each time for an update when the above system works so well?

You application must be split

This entire article assumes that your application has been split. If you don't split your database then it is next to impossible to offer upgrades to your users because the data part and the application part are one and the same. With a non split application it means that deploying your application again would actually overwrite your users existing data. I think overwriting userís data has some VERY serious ramifications here.

I explain in detail all about splitting a database here:

..\Articles\split\index.htm

You could probably spend some time and play around with the package wizard and cajole it into being able to overwrite some of your files but I really don't think it is worth your time. The PW simply opens up too many potential problems for deleting or damaging your clientís data files.
 
I think it far simpler to use something like WinZip and send them the new
 program part (front end) and avoid the package wizard all but for the very first
 install. I used a paid version of WinZip zip for a good number of years to deploy new versions of my applications until I discovered the Inno installer used above.
 
Multiple versions of MS Access are a problem on the same computer.

It would be wrong to ignore the significant number of compatibility issues when you attempt to run different versions of MS Access on a target computer. Keep in mind because since we now realize that the runtime is a real version of Access, then ALL OF those same problems and incompatibilities continue to exist and will plague your users. If youíre looking for large distribution and commercial grade installations with trouble free results then about the only solution is a commercial installer with install scripts designed for this purpose. For installing MS Access thereís nobody better than business than the people at SageKey, you can find out about their MS Access install products here:

www.sagekey.com

Deploying software updates is easy if you limit yourself to only updating the front end and not using a complex packaging system.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

kallal@msn.com

 

Home