Access 2002 references

[Scott McDaniel]

I've developed an application in Access XP using the Access 2000 format.
This app was tested using vmWare under a Windows 2000 OS, on which Access
2000 had been installed. After installing the app on the vmWare virtual
machine, I checked the references and found that my reference to the
msacc.olb type library from Access XP had changed to the msacc9.olb (which,
of course, ships with Access 2000).

How did this happen? Does Access change this internally? I found one small
issue (the use of a constant - acCurViewDesign - in a code module that was
supported in XP but was NOT found in Access 2000) and was wondering if I
there were other time bombs waiting? For the most part, the userbase for
this app will NOT have XP installed.

Of course I'll ship an .mde which will pick up the correct references ...
this was more a quest for understanding than a request for assistance.
However, it is worth noting to those who build apps in XP using the A2000
format, and then ship an .mdb file to their customers who are running Access
2000.

 

[Albert D. Kallal]

I will say that right now I have some fairly extensive a2000 applications,
but actually develop with a2002. So, I am in your exact same situation.

However, I have experienced NO problems when moving my application to a
another "mule" pc with a2000 to create the final mde. (and, your use of
vmWare is a fabulous solution to not have to have that "test" mule).

Just looking at the default refs for a2002 (but creating a a2000 mdb), I
get:

Visual Basic for Applications
Microsoft Access 10.0 object Library
OLE Automation
Microsoft ActiveX Data Objects 2.1 Library

Creating a blank mdb in a2000, I get:

Visual Basic for Applications
Microsoft Access 9.0 object Library
OLE Automation
Microsoft ActiveX Data Objects 2.1 Library

So, looking at the above, if you do a compile,a nave all in a2000, or create
a mde, I see no reason why any refs should break.

Do you have any additional refs set that you don't need? If you have
additional refs set, then that would be a souce of possbile breakage.

As mentioned, I currently writing with a2002, but deploying to some
customers with a2000, and am experience no problems what so ever.

 

[Scott McDaniel]

Thanks for the reply Albert. My references are exactly the same as yours,
and when I move my app to the vmWare Windows 2000 instance, they change as
you indicated. I always compile and make my .mde in vmWare in a clean
Windows 2K OS with only Access 2000 installed, and since doing this my
reference support issues have dropped drastically ...

I was curious as to how Access "fixes" references, and if it does so with
..mde files? In another post I found, Tony Toews opined that Access can
internally "fix" the standard references in an .mde file.

I do ship 3 ocx/dll files with this particular application (FMS Total Memo,
Mabry Treex, and CSMail), but I have complete control over where they are
installed and whether or not the install fails, etc and thus have code in my
install routine to guarantee that they are, indeed, installed and properly
registered.

vmWare was probably the best $400 I've spent in a looooong time ... I can
now test all my applications on any combination of OS\Service Pack\Office
Version ... it has certainly gone a long way towards helping me troubleshoot
remote deployed installations and find the issues with each.

 

[Douglas J. Steele]

You have no real alternative but to code it yourself (or find a way of doing
it with the commands which are part of Access 2000)

AFAIK, it isn't legal to copy the olb file from one machine to another, and
even if it were, I don't believe a given version of Access will work with
the olb file for another version.