With MS Access Runtime, users can run Access applications without buying a license.
Microsoft Access has always been a powerful tool that is easy to use for users of almost any skill. It can store relational data, interact with other Office applications such as Word and Excel, and present users with attractive forms and reports. For IBM i shops, it can even import and export data from other databases such as DB2 for i using ODBC. It can also be used programmatically using Visual Basic for Applications (VBA). However, in spite of it being a useful tool, several major things have hindered widespread adoption of Access:
- The combination of its power and ease of use gives untrained users the ability to create "monsters."
- The price is prohibitive.
- It's a (very) "fat client," requiring quite a few resources.
- Installation and deployment create headaches.
Well, we can now kiss goodbye some of those Access woes—namely, price and part of the deployment issues. Starting with Access 2007, Microsoft has made a free end-user runtime edition that will allow users to use an existing database without having an Access license. Users of the Runtime edition can run forms and modify data but can't create a new database or make a design change to an existing one (which prevents them from creating monsters!). This is similar in concept to the free Word viewer or PowerPoint viewer applications; users who don't own Microsoft Office can download the viewer to "view" (but not modify) an Office document.
Unlike the other Office viewers, the Access runtime is a large download. It must be installed on every machine that will run an Access application. Although this is an inconvenience, this is similar to installing a Windows or browser add-in such as Adobe Reader, the .NET Framework, Silverlight, or Flash. While not ideal, it is better than installing a full-blown copy of Office Professional or Access.
If you've been involved in the Access world for a long time, you may remember that the "run time" edition of Access was a pain in the neck. Prior to Access 2007, there was a cost to acquire the "run time" tool, learning the tool required time, you'd need to create an EXE tool to distribute the application to the users, and finally, at least in early editions, the run time didn't always behave the same as the regular edition. The new run time has eliminated these problems.
Shown in Figure 1 below is a copy of a sample Access application running in the Access 2010 Runtime on Windows XP.
Figure 1: This Access application looks and acts the same in both environments. (Click image to enlarge.)
One other benefit worth mentioning is that this Runtime edition will allow IT departments to easily keep users on the latest version of Access without having to purchase the latest version for everyone. After just doing some recent Access 2.0- and Access 97-to-Access 2010 upgrade projects, this is a splendid development! I've known several companies that have kept their MS Office licenses back-leveled because of the cost or upgrade headaches. But as we all know, staying back-leveled will eventually present a large cost as well.
Two Potential Caveats with the Runtime Product
If you're going to use the Access runtime, there are a couple things to beware.
1. If you choose to deploy an Access database to users using the Runtime edition, bear in mind that the database window will not be available. So, if you're used to having users run a query or report directly from the database window, that approach will no longer work. Everything needs to be presented to the user from a form or menu.
Further, you will need to make sure that there is a menu or start-up form of some kind to present to your users. If this is not done (and without the database Window), the user will be faced with an empty Access Runtime window.
2. If the Access application is on a network drive, you will be plagued with the "trusted" dialog prompt, forcing users to confirm they'd like to continue. I had a database that used linked tables that wouldn't even run because the linked database couldn't be "trusted." In case you're unfamiliar with it, Office applications have a security concept called "trusted" sites. By default, Access databases located on a network drive are considered untrusted (due to potential security risks.) When a user requests to open a networked database, Access will prompt a user to confirm that he or she really wants to open a database from a non-trusted location, which gets annoying fast. However, there is an option in Access where you can define "trusted" network locations so that users aren't continually pestered by this behavior.
Inexplicably, Microsoft did not include a utility or even the original Access option in the Access Runtime to configure trusted locations. So how does one indicate for the Access Runtime trusted local and network locations? Fortunately, this problem can be fixed with a few registry entries. The text below shows a sample registry (.reg) file used to define a trusted location to drive X:\MyApp.
Windows Registry Editor Version 5.00
"Description"="My Access Application"
Registry files are plain text files, so you can use Notepad to create one. All you need to do is paste the registry entries into a text-based registry (.reg) file, save it ,and double-click to modify the registry on each user's machine. When these entries are placed in the registry, your application will be able to open the network databases without the annoying message.
The sample registry keys in the text above are shown for the Access 2010 Runtime (aka Access 14). For Access 2007 (aka Access 12), substitute 12.0 instead of 14.0 in the path references. The date reference in the registry file is in dd.mm.yyyy format. If I remember correctly, you cannot identify the root of a network drive as a trusted site.
Providing Easy Access to Access
With the Access Runtime, you can cheaply and easily keep your users on the latest version of Access. Also, there is an inherent "protection" built in because the run time edition keeps nosy users from peeping into the internals or modifying a database. One of the few drawbacks is that all functionality must be accessible via a menu or form because the database Window is no longer available. For more info on how the IBM i can interact with Access, see the references section.
Links for Using Access and i/OS
"More AS/400 Client/Server Programming with ADO and VBA"
"Links, Imports, Exports: Using ODBC to Share OS/400 Data with Microsoft Access"
"Launching SQL Statements Through Microsoft Access Pass-through Queries"
"Invasion of the BLOBs"
as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1