Solved

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

Posted on 2007-03-26
10
709 Views
Last Modified: 2008-01-09
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

Thanks
0
Comment
Question by:Carl Sudholz
  • 4
  • 4
  • 2
10 Comments
 
LVL 84

Accepted Solution

by:
Scott McDaniel (Microsoft Access MVP - EE MVE ) earned 125 total points
ID: 18798979
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:
http://support.microsoft.com/kb/233002/

Here's info on distributing DAO and ADO. This was written with the PDW in mind, but it should provide useful information:
http://support.microsoft.com/kb/213846/

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.

0
 
LVL 39

Expert Comment

by:stevbe
ID: 18800585
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).
0
 
LVL 39

Expert Comment

by:stevbe
ID: 18800593
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.

Steve
0
 

Author Comment

by:Carl Sudholz
ID: 18804846
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?
0
 
LVL 84
ID: 18805076
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 ...

0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 

Author Comment

by:Carl Sudholz
ID: 18805176
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.

Thanks
0
 
LVL 84
ID: 18806709
<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!!

0
 
LVL 39

Expert Comment

by:stevbe
ID: 18809148
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.
0
 
LVL 84
ID: 18811313
<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.
0
 
LVL 39

Expert Comment

by:stevbe
ID: 18811494
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.

Steve
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

In Debugging – Part 1, you learned the basics of the debugging process. You learned how to avoid bugs, as well as how to utilize the Immediate window in the debugging process. This article takes things to the next level by showing you how you can us…
Introduction The Visual Basic for Applications (VBA) language is at the heart of every application that you write. It is your key to taking Access beyond the world of wizards into a world where anything is possible. This article introduces you to…
Show developers how to use a criteria form to limit the data that appears on an Access report. It is a common requirement that users can specify the criteria for a report at runtime. The easiest way to accomplish this is using a criteria form that a…
Basics of query design. Shows you how to construct a simple query by adding tables, perform joins, defining output columns, perform sorting, and apply criteria.

744 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

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now