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

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.

Steve

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?

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 ...

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

<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.

<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.

Steve