MS Access references
Hi
I have an Access db which is installed on a number of PC's in an office. It requires reasonably frequent updates but I am having a problem with the references. For example on my PC I have to have it set to Outlook 14.0 Object Library. However on some (but not all) of the PC's where it is installed it only works with Outlook 12.0 Object Library. I have also noticed that one of the PC's that does have Outlook 14.0 Object Library seems to have it installed in a different place.
At present the references are having to be reset manually every time there is an update but is there a more automated way of resolving this?
Man thanks
I have an Access db which is installed on a number of PC's in an office. It requires reasonably frequent updates but I am having a problem with the references. For example on my PC I have to have it set to Outlook 14.0 Object Library. However on some (but not all) of the PC's where it is installed it only works with Outlook 12.0 Object Library. I have also noticed that one of the PC's that does have Outlook 14.0 Object Library seems to have it installed in a different place.
At present the references are having to be reset manually every time there is an update but is there a more automated way of resolving this?
Man thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I agree with capricorn1, late binding is the solution for this.
It will require some work to identify all of the Outlook constants you have used, but that is really just a matter of removing the Outlook reference, then debug-compile.
Identify the Outlook constant names and their values, then declare them in your code. Then debug->compile again, to find the next one. It is an iterative process, but once it is done, you will not have any problems.
BTW, you should be developing for the lowest level of Office, to ensure that you don't use a method or property that is only available on the later versions.
It will require some work to identify all of the Outlook constants you have used, but that is really just a matter of removing the Outlook reference, then debug-compile.
Identify the Outlook constant names and their values, then declare them in your code. Then debug->compile again, to find the next one. It is an iterative process, but once it is done, you will not have any problems.
BTW, you should be developing for the lowest level of Office, to ensure that you don't use a method or property that is only available on the later versions.
+1 for late binding. Trying to reset references, or add them, to a running application is never a good solution.
you should be developing for the lowest level of Office,If you do this, then you really don't have to worry about late binding, although it's still a good idea. If you code in the lowest version of Office you must support Access will upgrade the references when you move to the newer platform (it cannot downgrade them, however).
Scott, great info. I didn't realize that Access would automatically upgrade the reference. I've just always (ever since I started coding for multiple Office versions) just done the late binding.
Late Binding is the best way to handle this, without a doubt, but I have always made it a point to build to the "lowest common denomintor", and in my early days I never used Late Binding, and had no reference issues caused by incorrect versioning. I do extensively use Late Binding now.
So when you declare the Outlook objects, you'll obly have to declare As Object and when you create the instance you can use CreateObject using the object ProgID.
This way you could remove the Outlook reference from Access.
This solution supose you don't have a very complex interaction between Access and Outlook and also the ProgId for OutlookObjects remained the same between version 12 and 14 of Outlook