What's the best way to distribute a runtime MDE?

Posted on 2004-10-12
Last Modified: 2013-12-05
I've nearly finished writing an application in Access with the intention of marketing it commercially to targetted (but unvisited) users as a runtime MDE. I started out with Access97 Developer, but part way through the project upgraded to XP Developer - because it seemed best to be using a newer version, and it also had "compact on exit" to keep things running smoothly.

However, having recently joined this EE group, and seen the various problems people are reporting integrating runtime on end user machines (particularly if they already have Office/Access/other runtime installed), and other problems with differing operating systems and environments - I'm beginning to wonder if this is going to be a good solution.

I'm seeing products like Wise and SageKey being suggested (at huge cost!) as better than Developer, and also a tendancy for some authors to prefer 97 over XP?

I've also read somewhere that if you distribute in XP, than you need to provide two CDs?

So, this is my 500 point question:

What is the best way (as in compatible, successful, reliable) to distribute an Access application out to the masses, and what limitations would apply?


Question by:pauldownham
  • 6
  • 5
  • 2
  • +2
LVL 32

Expert Comment

ID: 12293273
Hi pauldownham,
  You need to have a serious look at your market.
  MSAccess in the MDE form is NOT an executable.

  Your runtime needs to be VERY SPECIFIC about what libraries are scheduled to install with it.  The first time you over-write the MSOffice Libraries on a corporate production platform machine for about 15 users, and you get that call from the IT department about the complaints they are getting...... you'll see what I mean.

  This is the reason that packages like Wise an SageKey can charge what they do.  These packages are designed to help eliminate errors.

  You need to have a good look at your market to understand that MDE's only work well on a limited basis.  This is why you don't see very many of them out there.  I've seen ONE in 12 years of working with MSAccess and it was an extreme niche market app.   (bird watching app)

LVL 16

Expert Comment

ID: 12293524
Use the package and deployment add-in that comes with access's developer edition to minimise version conflicts with your references.  Make sure that needed dll's and such are stored in the app directory, and do not overwrite those in win.
Even with P&D, access databases are definitely not mass marketable.  The headaches I've had in deploying to mutiple sites within just one organisation show that it can be very finiky.  Keeping the references down to a bare minimum by using late binding on objects helps - but causes its own share of problems.  Then there's the need to supply runtime for sites that don't have access, or incompatible access versions....
I suggest you switch to using Visual Basic and deploy full executables.

Access is very good at building and maintaining hand-crafted databases for niche markets however.
LVL 26

Expert Comment

by:Alan Warren
ID: 12294417
This might be worth a read:

Deploying Complex Microsoft Office Access Runtime-Based Solutions

It's acc2003, but the  principles are fundamentaly the same.

Ransomware-A Revenue Bonanza for Service Providers

Ransomware – malware that gets on your customers’ computers, encrypts their data, and extorts a hefty ransom for the decryption keys – is a surging new threat.  The purpose of this eBook is to educate the reader about ransomware attacks.


Author Comment

ID: 12295892
Thank you experts for suggestions to date ...

The application I'm planning is very niche (so distributing to the masses might be optimistic!), but nonetheless I would have no control over the status of the PC it was being loaded on - so I'm naturally concerned about clashing with or upsetting existing Office/Access/Runtime products that might be pre-installed.

I am also a bit confused now that 2 out 3 experts are implying I shouldn't even be thinking about distributing the package as a runtime MDE ... because I thought that this was the whole point of Developer?

Jadedata mentions being specific about included libraries - where are these chosen? In the XP Packaging Wizard you seem to have virtually no choice ... it says it puts the MDE and OWC10.DLL files in AppPath and thats about it.

LVL 84
ID: 12296506
First and foremost, I agree completely with GreyManSC - if you're going to distribute this to a userbase over which you have no control, you'd certainly be wise to consider switching to Visual Basic or VB.NET ... your database could remain in Access, of course, but your frontend would be migrated to some other platform which is more easily distributed.

If, however, you stick to Access, then read on ...

IMO, you should distribute your file as an .MDE ... some people distribute as an .MDB (those who make changes to the forms/reports in design view via code must distribute as an .MDB, for example).  However, an .mde is far less likely to corrupt, and it can't decompile thus removing one headache for you. Also, an .mde arguably runs a bit faster since all canonical code has been stripped. The drawback is, IMO, you MUST deal with references and ensure that all references are installed PROPERLY on your target machine. This is really a non-issue, as you should deal with references properly, but many first-time developers have real issues with refs.

Whether you distribute the Runtime along with your MDE (the runtime is basically the full Access progarm without the design-time features) is up to you ... if your user has Access installed on their machine (a good installer can check for this, BTW), then you don't really need to distribute the runtime. You can poll your intended userbase and determine what most of them are running and tailor you development to this (if almost all are running 2000, it makes little sense to attempt to support a handful of users who are running 97). And, installing the runtime on a machine with the full version of Access can "break" existing applications (note: the Sagekey scripts are designed to avoid this issue) and result in extremely angry phone calls from IT persons!!!

If you're going to distribute this, then purchase a commercial installer. The PDW is lame at best and in some cases (like when it picks up and attempts to install msado.dll, which you CANNOT do unless it's part of MDAC) it's just plain wrong.  As mentioned above I'd also invest in the SageKey scripts if you plent to distribute the runtime. Sagekey (along with your choice of an installer) allows you to safely install your application along with the Runtime without overwriting or otherwise disturbing the retail version of Access or other runtimes. The first time you get that call from the IT department demanding to know why their exisiting apps won't run immediately after installing yours, you'll wish you'd spent the money. I use the Wise Installer; it's a little cheaper than Installshield, and if you're going to use Sagekey, those two (plus the MSI from Microsoft) are the only two supported, and Wise is a widely used program, which means there are a lot of forums and user groups. I'm sure Installshield is the same, however it's a bit more pricey.

Also, have you tested your application on ALL versions of the OS you're going to support (and all OS SP Levels) with a minimal configuration? I use vmWare (~$400) to do this; it allows me to boot a "virtual machine" using any Windows OS I own (I've got everything from 98 on up) (note: MS offers VirtualPC, a program similar to vmWare, is available for around $150 - some have said they ran into freezeup issues with VirtualPC, but I have no knowledge of this). I also have the most bare minimum configuration of Office I'll support (Office 2000, SP1) installed. You'd be amazed at the problems you find on a "perfectly running application" that's run on a machine with minimal configuration. Your development machine is, I'm sure, the latest/greatest, most up-to-date machine around; you can bet your users will NOT have this luxury, and you can bet there will be some issues.

RE: Dll files ... well, they don't call it "DLL Hell" for nothing <g>. This can be your worst nightmare. As GreyManSC suggests, install any non-system DLL's to your applications directory and register them there ... this way, you won't overwrite or otherwise disturb any running programs. As for system dll's, well, you really shouldn't be installing those (like Jet updates, etc) ... instead, you should alert the user if their configuration is below minimal standards (a good commercial installer will do this for you automatically), let them know that their configuration isn't correct, and allow them the option of installing those updates or not (obviously, if they don't install the updates, you must also warn them that your progarm will not work - but that's all you're obligated to do). The object here is to get your application running with the "oldest, safest" configuration ... this means that if you can safely support MDAC 2.1, then do so ... if you require MDAC 2.8, you'll likely receive some calls complaining about users having to update in order to get your program to run.

Be selective in what references you use ... you mention the OWC10.DLL (which I believe is the Office Web Components). Many libraries/dlls are known to have severe versioning and distribution issues (Web Components is one of them) ... if you distribute these files, you'll end up with lots of support calls. How do you determine what files are buggy? Easiest way is to post your lists of references here ... someone here will certainly share negative experiences (if any) and hopefully avoid headaches for you down the road. Are you using any ActiveX files? Many are very, very buggy with Access (unless they've been designed to work with Access) and should be avoided like the plague.

I'll say this - my biggest clients are governmental and R&D Aerospace companies - the former hates to upgrade equipment (I found a few machines still runnin Windows 95), the latter LOVES the best and brightest equipment (Windows 2000 and above ONLY). When I first deployed to them, I was flooded with install issues (and I was no virgin to this, having deployed dozens of other apps to other, smaller companies), so much so that I ended up flying to DC and providing on-site assistance ... and even then we had some machines that were just too finicky to be considered stable (we ended up finding several issues with these machines, and on several instances found that users had installed software which was incompatible, beta, etc etc which was causing the problem). We ended up moving to a Terminal Server environment (which eliminated the install issues and provided much better performance), but the initial rollout was a nightmare (and tarnishes your image with your client ... if they can't even get your app to install, how can they trust it)? All I'm saying is this - consider the advice of those who have come before you ... I wouldn't DREAM of rolling out an app (Access, VB, et al) without first running it in vmWare (all OS level I wish to support) and thoroughly testing it (don't forget to test with NO data in the tables), and I would never again consider distributing with the PDW which comes packaged with Developer (it's far too restrictive). I also use and highly recommend Total Access Analyzer ( - a great tool which can find a variety of issues with your forms/reports/tables, etc ... IMO, worth the money.
LVL 32

Expert Comment

ID: 12297531
... canonical ...  god, I love it when you talk technical like that!!

Total Access Analyzer - ditto on the recommendation
LVL 84
ID: 12297720
I did that just for you Jack ... <g>

Author Comment

ID: 12299345
LSMConsulting ... thanks for your generous advice.

I seem to remember reading somewhere on MSDN that you can change the settings in one of the setup files (after running the developer wizard) that had the effect of renaming the location of the msaccess runtime version, so that it wouldn't interfere with updates etc to any pre-existing Access full versions. In this way, I envisaged that I could distribute an application that always used the runtime msaccess I supplied (tucked away in its own bespoke folder), regardless of whether a full version of Access existed. This I thought would then be sufficient not to have to worry about existing version (97, 2000, XP etc.) because my application would only use its own matching runtime? Prehaps I'm being simple/hopeful?!

My application is for a fixed standalone purpose, is relatively simple, and the only references are the four default(?) ones of VBA, Access10.0 Object Lib, OLE automation and ActiveX Object 2.1 Lib. How can these be "checked"?

I was doing all this in Access97 (where testing the Developer generated setup disc on clean PC's with 98, 2000 and XP o/s's all seemed OK), but have recently moved on to XP Developer, where the 98 PC asks for an Office components update disc ... which was why I asked whether experts thought keeping it in 97 might have been better (more widely usable)?

The application seems pretty bullet proof within itself, with loads of deliberately awkward testing  being done to make sure theres an appropriate response to every possible user action (including missing data etc.) - so my worries are really all to do with these issues of distribution.

Thanks again for your time and patience everyone!
LVL 84
ID: 12299712
Your refs should be fine, those are pretty standard libraries ... I'd think the only one which may cause you troubles is the ActiveX library, if the enduser has an older version. I don't know how you'd check that with the PDW (not even sure you could), but a commercial installer can do this pretty easily. To that end, even the Inno installer (which is free) can do this ... before I started using Wise, I use Inno ... I'd first build a deploy with PDW, determine the files I needed to distribute (taking into account the utter ignorance of some files, as with the aforementioned msado.dll file) and then transfer those settings to Inno ... there are several forums devoted to Inno and there's quite a few articles in their FAQs devoted to Access (although not many devoted to delivering the Runtime). I'd trust Inno before I'd send my stuff out with the PDW ... google on "Inno setup" for the website.

RE: keeping it in 97 - You can certainly keep your application in 97, however this does lead to some "raised eyebrows" - people think it's an "old" application (even though you and I know it's not) or one that's just been "prettied up" ... other than those issues, I see no reason why you couldn't keep it in 97. Of course, you'll still run into the Runtime issues discussed elsewhere ...

RE: installing the runtime - do what you wish but you can't say you weren't warned. The newsgroups are loaded with horror stories (from developers AND IT guys) who do exactly what you are intending ... simply relocating the Runtime will not do what you want ... my SageKey "main" install script is about 650 lines in length, and the Sagekey runtime install is around 350 lines in length ... it writes custom profiles that are used when loading your program so as not to interfere with the retail version(s) of Access which may be installed on the machine. It goes to great lengths to ensure compatibility with existing applications - and there's a reason an entire "cottage" industry has grown around deploying Access apps (because it's needed). Again, if you can get around deploying the Runtime and deploy ONLY your application you'll be a lot better off ... the runtime isn't strictly needed anyway, and if you can deploy your 2002 app in 2000 format and require your users to maintain that minimum level, you'll be much, much better off (IMO) ...

Author Comment

ID: 12299951
LSMConsulting ... thanks again!

I'll take a look at Inno, and obviously Wise with SageKey too, and I'm certainly not comtemplating going against expert advice ... its just a bit puzzling to us newbies that having bought what you thought was neccessary (MS Developer x 2!) that its considered to be useless for the purpose intended!

The application is not overtly an Access product, I just used it because I know Access fairly well and I needed a database to store and manipulate the data. I also suspect that most of my target audience wouldn't have Access, or only as an accidental part of Office Pro, so I'm guessing that providing runtime will be essential - and having gone this route for them, would like to keep the application and its runtime locked together for everyone to avoid Access version issues ... presumably something I can do with SageKey?

Back to the refs: these items I assume are already going to be on the end users PC whether they've got Office or not, as part of Windows? If so, then just by stipulating a version (say 98SE or newer) won't I be sure that the ones I need are in place? And if I do revert to Access 97, where the refs list is only three items (VBA, Access Obj 8, and DAO 3.5) will I be better off (allows older PCs) or worse off (excludes latest PCs)?

Thanks again ...  
LVL 84
ID: 12300930
The Developer packages do leave a lot to be desired, IMO ... they are really geared more to corporate distribution (i.e. where you have a lot of control of the machines, etc) as opposed to commercial ...

Sagekey allows you to install your app, files, and the runtime and do so without causing issues with existing applications. Sagekey is nothing more than customized scripts built for the particular installer you use (and they only support Wise, Installshield, and MSI); these scripts have been tweaked over hundreds - if not thousands - of installations on every conceivable platform. If you must deploy to remote users with unknown machine configurations, Sagekey is certainly an option to consider.

References will be your biggest headache. Making assumptions about whether a library is available is guaranteed to bite you - your installer should determine what files/libraries/controls/platform are required and check those things for you ... you cannot be reasonably assured that your references will be available on end user machines ...

Regarding A97, you won't exclude newer PCs if you deploy this platform. If you deploy a newer version (say 2002), you may "exclude" older machines in that you may require users to upgrade their software in order to run your software (and some users will not do this) ... so you don't really exclude them, you simply set minimum requirements. FWIW, if it were me, I'd deploy 2002 with the 2000 format and be done with it.

Author Comment

ID: 12306151
LSMConsulting - your 500 points are nearly ready!

Just to put this into perspective, my app is not going to be anyone's main product or reason to have a PC - its a piece of software that collects and manipulates data from an external logger, so very much an accessory item. Also, because my app is aimed at the mid/low end market, I suspect most users would only have moderate spec PCs, and many of these would be without Access installed (this is in the UK, where the Pro version of Office is rarer than Standard or SBE), so that's why the runtime provision is critical.    

So, if I'm compelled to provide runtime for say half the users, shouldn't I make all the installations use the matching runtime provided, rather than introduce the complication of letting users with full Access run it in their own version?

In summary, I think I'm then looking at reverting to A97 (to maximise potential customers, bearing in mind its unlikely people would carry out any upgrades just to use this product), and then install this using Wise & SageKey (to avoid clashes) and configure this so that everyone uses the runtime.

Does that make sense?

If so, do I need to purchase Wise & SageKey as new products, or would someone who has moved on to 2002/3 versions be able to supply me with their old copies, or are there people/companies out there offering to make up the install as a service? I only ask this last point because it seems expensive to buy these products only to use them once.

Thanks again

LVL 84

Accepted Solution

Scott McDaniel (Microsoft Access MVP - EE MVE ) earned 500 total points
ID: 12306660
Makes sense to me, now that you fleshed it out with a few more details.

Regarding reverting to A97 - if you use SageKey and Wise to distribute your app, you really won't have to worry about that. Sagekey/Wise will allow you to determine  what config your user machine has and upgrade as necessary (Wise will automatically include the packages needed to, say, upgrade the Jet or MDAC, Sage will include packages to upgrade other items, so you're covered for any install if using these two products). Still, I see your reasoning - if your application works fine in 97 I see little reason to upgrade to a newer version.

There may be some people who no longer use their 97 Sagekey scripts, but you'll be hard pressed to find them. I believe Sagekey supports changing owners (note: you'll likely need the support of Sagekey when you're learning to implement their scripts, and their Support forum is password protected - IOW, if you do find someone willing to sell their 97 Sagekey scripts, contact SAgekey and make sure those scripts can be legally transferred to you - otherwise, you may find yourself without support resources for Sagekey, which would be a bad thing). Note also that you can't "upgrade" Sagekey scripts; the 97 scripts cost ~$400, and if you wish to "upgrade" to the 2000 scripts, you'll have to shell out another ~$400. Regarding Wise, I'm sure you'll have to purchase a new version of this ... I purchased the more expensive version which allows me to perform Web-based updates and am really glad I did. It ended up around $1000 USD but it's certainly made my distribution life easier!

Check the Sagekey site in regards to having someone build an install for you ... they offer this service, but I have no idea  what it costs. I'm sure others offer this service (I'm betting you could hit some of the newsgroups with this question and receive more than a few offers <g>) but remember - caveat emptor - these services will require that you transfer all your files to the builder, and they in return will supply you with a compiled .exe file to distribute. If changes have to be made to your application, or you need to customize each install, you'd almost certainly have to go back to that person to have them rebuild your install (and they'll almost certainly charge a fee for this!).

Author Comment

ID: 12308818
LSMConsulting ... looks like we finally converged!

I will no doubt be purchasing new SageKey and Wise very soon.  Final point (although I'm giving you the points straightaway!), are we concluding its going to make no difference to end users with older PCs whether I stick with A2002 or revert to A97? Because with the price of SageKay being the same for any version, I may as well staywith 2002 and be more up-to-date for any future projects?

Thanks for all your help.

LVL 84
ID: 12308902
The only "issue" I see is that users with Win 98 will almost certainly have to update their MDAC and Jet installs in order to run the 2002 runtimes you'll distribute (again, Sagekey and Wise should handle this for you pretty easily) ... I don't really see this as a problem and if it were my money I'd purchase the 2002 scripts, as this will certainly help you to be more future-proof.

The final step I'd take in regards to this would be to ask Sagekey about issues surround deploying your app with their scripts to the Win98 machines ... as I've said earlier, they've got a heckuva lot more experience in this area than do I, and they could certainly counsel you better in regards to this specific config ... good luck!!

Featured Post

Simplifying Server Workload Migrations

This use case outlines the migration challenges that organizations face and how the Acronis AnyData Engine supports physical-to-physical (P2P), physical-to-virtual (P2V), virtual to physical (V2P), and cross-virtual (V2V) migration scenarios to address these challenges.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

QuickBooks® has a great invoice interface that we were happy with for a while but that changed in 2001 through no fault of Intuit®. Our industry's unit names are dictated by RUS: the Rural Utilities Services division of USDA. Contracts contain un…
It’s been over a month into 2017, and there is already a sophisticated Gmail phishing email making it rounds. New techniques and tactics, have given hackers a way to authentically impersonate your contacts.How it Works The attack works by targeti…
Familiarize people with the process of utilizing SQL Server views from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Access…
Get people started with the utilization of class modules. Class modules can be a powerful tool in Microsoft Access. They allow you to create self-contained objects that encapsulate functionality. They can easily hide the complexity of a process from…

831 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question