Which Reference library's are installed with MS Access 2003 Runtime

Hi there experts
We have developed an application using MS Access 2003.  It uses the following reference libraries:
MS Windows Common Controls (comctl32.ocx)
MS Office Library (MSO.dll).  
Visual Basic for Apps (Vbe6.dll)
Microsoft Access 11.0 Object Library (Msacc.dll)
OLE Automation (stdole2.tlb)
Microsoft ActiveX Data Objects 2.8 (Msado21.tlb)
Microsoft DAO 3.6 Object Library (DAO360.dll)

We wish to distribute the application with the MS Access Runtime files using SageKey's Access 2003 MSI Wizard.

Which of the above libraries, if any are included in the standard MS Access Runtime installation and which ones should I provide with the installation

Carl SudholzManaging DirectorAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
None of these are included with the Runtime, or with Sagekey's wizard. YOu must determine which, if any, of these libraries/files etc you will include in your package, and how your install will handle them.

I doubt you need the VBE6.dll library, since that deals entirely with the VBA programming interface (at least to my knowledge) and you wouldn't be able to utilize that with the ART.

You cannot distribute either the Office library or the Access Library ... those are not distributable, and you must instead require that your end user have these installed before you being your application installation. Since you're installing the ART, then the Access reference will be taken care of, but again, your install would probably need to search for the correct version of Office and verify that it was installed BEFORE continuing installation. Generally this is done by searching the registry in the HKLM\Software\Microsoft\Office key, and verifying that the correct subkeys are installed, have a value in the InstallPath key, and that the value there "points" to a valid file. I'm sure you could find a script that does this for the MSI, or Sagekey probably has a script which does this for you.

ComCtl32.ocx is tricky - it's really not meant to be used with Access (those are VB controls), but it's also almost always installed on the enduser machine. The trick is to make sure that they have the correct version. This is normally done with OS version checks (i.e. you require your endusers to have at least Windows XP SP2 or something), or you can examine the comctl32.ocx file directly and see what version it is and match it to your required version. If they don't match, then you could either (a) include them in the install file or (b) alert the user and provide them with a link where they can download them (directly from the MS site, typically).

STDOLE2.dll should, again, be installed with the OS, and you would check the OS version to insure that you have the correct one. YOu should NOT overwrite stdole2.dll unless you're absolutely certain you should do so.

ActiveX 2.8 is installed with the full MDAC library, and you must NOT attempt to install portions of that library. Either install the full MDAC package, or instruct the user where to go to get this package. Again, you can check the OS version to see if that version installed originally with MDAC 2.8

DAO 3.6 itself is not redistributable, but instead would be redistributed as part of DCOM or one of the older MDAC packages (it's not been included in MDAC packages since MDAC 2.5 SP1). See the link below for more info:

How to redistribute DAO:

Here's info on distributing DAO and ADO. This was written with the PDW in mind, but it should provide useful information:

That said: The very FIRST thing your potential client sees is your installation. I can tell you from personal experience that if the install fouls up, your potential client will have a very sour taste in their mouth in regards to your app. Using the Sagekey scripts is a wise choice, and they have a very good support department (which can also help with questions such as these).

You MUST insure that you (a) have a minimum set of requirements for the enduser machines and (b) test your install THOROUGHLY on a machine with ONLY those programs installed. If your product was designed, built, and tested on Windows XP SP2/Office 2003 machines and your customer is still using Windows 98/Office 2000 machines (happens ALL the time) then you can pretty much be insured of some really, um, enlightening support calls. You're far better off to insist on a minimum requirement and stick to it, even if it means losing the occasional client. Your installer can typically check for OS and Office versions and abort the install if they don't meet minimum standards.

TEST THOROUGHLY!! I can't stress this enough. I use vmWare for testbed purposes, but you can setup an older machine with the OS and minimum programs needed to run your software, then test on that machine THOROUGHLY. It's easier, however to use the (now FREE) VirtualPC program from Microsoft: http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx. You'll still need licensing for the various OS and Office programs you need for testing, of course, but you'd need that for machine testing anyway.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
LSM <--- the MAN !!!

ok ... but I have a couple of questions ... are you really using all of those libraries ... why both DAO and ADO? What are you using the Office lib for?
If you are not having other apps control your Access app you do not need the ref to OLE Automation (stdole2.tlb).
what controls are you using from MS Windows Common Controls (comctl32.ocx)?
If you are unsure about any of these then you can remove the reference and see if you can still compile.

Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Carl SudholzManaging DirectorAuthor Commented:
Thanks LSM & Steve,

Turns out I don't need library's
- OLE Automation
- Microsoft ActiveX Data Objects 2.8

I am using the sagekey Access 2003 MSI Wizard to manage
- Visual Basic for Apps (Installed with Runtime)
- MS Windows Common Controls
- Microsoft DAO 3.6 (Sagekey wizard installs MDAC 2.8 & Jet 4.0 SP8)

Thus libraries that may potentially incur issues are:
- MS Office 11.0 Object Library -> Required for Toolbar alterations by app
- Microsoft Acces 11.0 Object Library

Can I add these refences to the Sagekey wizard to manage during installation?  What are your throughs about doing this?
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Again: You CANNOT distribute the Office Libraries (it's illegal to do so, and MS makes no merge modules or installers to do this), so the ONLY thing you can do is check the target machine to make sure that the correct version of Office is installed. I'm not overyly familiar with the Sagekey wizard so I can't tell you how to do this, but the support team at Sagekey can likely take care of this for you quickly (I'm betting they have canned scripts that do this easily). Note that you're referencing Office 11 (2003) so your users will need to have 2003 or 2007 installed. If all you're doing is manipulating toolbars and menus with this library, you can normally do all you need with a reference to Office 2000 (of course you'll have to have the correct files to reference on your dev machine to do this). As I stated earlier - you MUST make sure that your enduser machines have the SAME or NEWER versions of the files that you are referencing. Access can upgrade references (like upgrading the Office reference from Office 2000 to Office 2002, 2003, or 2007) but it cannot go the other way. Your best bet is to (a) determine your minimum requirements and (b) make your final build on a machine which matches those requirements strictly.

One option is this: If you are confident that your enduser will have some version of Office installed you can always use Late Binding in your code, in which case you could remove the reference and not worry with the version installed, but at this late date I imagine that would involve quite a bit of rework.

Access will use the Runtime (which you're distributing and installing) as the Access 11.0 Object Library, so in effect you're "distributing" this as the Runtime ...

And again: Be VERY careful with the MS Common Controls library ... it wasn't designed to be used with Access and can cause you no end of trouble. As Steve asked: What controls are you using from the library? There are several, common among them are the Treeview, Listview, etc etc.

Technically speaking, you DO need the ADO 2.8 library, it's just being distributed as the MDAC 2.8 library (which has absolutely nothing to do with DAO, BTW). I know I keep harping on this, but it's critical that you understand exactly what is being put on your enduser machines ESPECIALLY with these data access libraries. Installing MDAC 2.8 installs, among many, many, many other things, the ADO 2.8 libraries ... so you are deploying ADO 2.8, you're just doing it the correct way by installing MDAC.

Also, I'm assuming that when you say "Jet 4.0 SP8" that you're deploying that package and not just the MSJET40.dll file ...

Carl SudholzManaging DirectorAuthor Commented:
LSM, Thanks again,

I got your point on the Office Library.  I'll remove the dynamic aspect of the menu control and remove the need for the office library.  That's probably the most universal solution here.

I need the MS Common Controls for node and treeview elements used in a table link help file system.  I'm confident that the Sagekey wizard will handle this. Unless you have any other suggestions.

Otherwise I think you have cleared up my issues.

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
<I'm confident that the Sagekey wizard will handle this.>

Sagekey has nothing to do with compatibility between Access and ActiveX controls. Access is notorious for it's inability to properly deal with ActiveX controls (has to do with very restrictive interfaces and such, at least to my knowledge), and the Treeview is one of the big culprits here. Don't get me wrong, it'll probably work okay, especially if you're only using basic properties and methods of the control, but don't be surprised when you get a call from a user that your Treeview isn't showing up. The newsgroups are full of postings on this subject specifically on this control.

Good luck and let us know how it turns out!!

LSM: curiosity sake only ...
<Technically speaking, you DO need the ADO 2.8 library>
Why? I thought Jet and DAO was now being distributed with the OS but I suppose if you have a Win98 user you night want to distribute MDAC.
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
<Why? I thought Jet and DAO was now being distributed with the OS but I suppose if you have a Win98 user you night want to distribute MDAC.>

I meant that this particular installation needed the MDAC 2.8 install, since it was called in the reference list ... guess I should have been more clear on that point.

You are correct in that MDAC in some flavor is distributed with the OS (and with MANY other MS products, most notably Internet Explorer), but the version is the sticking point in this one. Many older OSs (like 2000 PRO) may not have the 2.8 library, as it may or may not be included in an update.

I'm not sure which version of DAO is being shipped with the newer OS (i.e. XP SP2 and Vista) ... be interesting to find out.
Ok ... I'll stop with the theoretical and leave it to you folks who are actually distributing Access apps into the wild :-) I only used an mdb file once as a datastore of a VB app we sold and then I used InstallShield which did all the fancy footwork for me in regards to building a package that would handle from 95 ( they even had a merge module for the 95 DCom issue) through XP. Of course I was not deploying an Access FE so I did not need to use SageKey.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.