VBA References
I have been developing in VBA for Access and Excel for some time now. I have a question about references and older versions of Office. I just installed Office XP on my machine and have started to do some development. If I send the database to someone with Office 2000, the reference does not downgrade to say Excel 2000. It says the reference to Excel 10.0 library is missing.
Now the other way works fine. If I develop in Access 2000 and have a reference to Excel 9.0 library, and someone with Office XP opens it, the VBA will automatically upgrade the reference to 10.0.
Is there any way to make sure the correct references are used, or do I have to install both Office 2000 and Office XP on my machine and add just use the older references so that it works on all machines? Thanks.
Now the other way works fine. If I develop in Access 2000 and have a reference to Excel 9.0 library, and someone with Office XP opens it, the VBA will automatically upgrade the reference to 10.0.
Is there any way to make sure the correct references are used, or do I have to install both Office 2000 and Office XP on my machine and add just use the older references so that it works on all machines? Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I have a different version of this problem with ADO references differing in version between machines and have not found a sure-fire fix. I'll be watching to see if anyone else has.
Hello ingenito,
There is no way to force the non-Access references to downdate.
The solution to this sort of problem is to use 'late binding'.
This is a technique where you do not use any Excel reference library at all and declare the excel objects as datatype 'Object'.
Look at the CreateObject function in VBA Help.
Pete
There is no way to force the non-Access references to downdate.
The solution to this sort of problem is to use 'late binding'.
This is a technique where you do not use any Excel reference library at all and declare the excel objects as datatype 'Object'.
Look at the CreateObject function in VBA Help.
Pete
<vent>
Yuck. "The only solution to this problem is to program in a way generally recognized as a bit shoddy." LOL What a brilliant Microsoft-ish solution!
</vent>
Yuck. "The only solution to this problem is to program in a way generally recognized as a bit shoddy." LOL What a brilliant Microsoft-ish solution!
</vent>
ASKER
I agree with pique_tech in that its a pretty inefficient way to go about things. I don't want to have to write extra code and then worry about commenting everything when I take out the references. Also, if I don't use references to begin with then the very helpful property dialog popups and such will not work. I guess the best way would be to write a function that starts when either when the database or worksheet is opened and then check for and add references there. Any other suggestions?
You can attempt to programmatically manage the references, but that could get ugly once your app gets to a machine with several dozen custom references added. Late binding, while a little inconvenient, is the easiest solution you have to this issue.
>> Also, if I don't use references to begin with then the very helpful property dialog popups and such will not work
I generally code using Early binding, then change the Dim and Set statements to use Late binding.
I generally code using Early binding, then change the Dim and Set statements to use Late binding.
>> "The only solution to this problem is to program in a way generally recognized as a bit shoddy."
I'd certainly not call Late Binding "shoddy" ... it's simply another programming tool.
Generally speaking you should ALWAYS program to the lowest common denominator - it your user base is using a mixture of Excel 97 and greater, then it is incumbent on you to insure that your code will work (and compile) on that platform, and you do that by either (a) doing all your development work on a machine with Excel 97 installed and referenced or (b) using late binding or (c) setting minimum requirements and enforcing them using your installation tool.
Regarding ADO references, generally speaking you should use your installer to determine file versions, and require your end user to have version xxx or greater before allowing installation to continue. Or, of course, developing on a machine with the lowest common denominator (as above) and therefore not worrying about other references. Of course, ADO (actually you're talking about MDAC here) references are notoriously difficult to deal with; mis-matched versions of any of the hundreds of files installed by MDAC can cause you no end of trouble. The solution for this is the same as above: Make sure your end user has the correct version OR make sure your dev machine has the lowest common version.
I'd certainly not call Late Binding "shoddy" ... it's simply another programming tool.
Generally speaking you should ALWAYS program to the lowest common denominator - it your user base is using a mixture of Excel 97 and greater, then it is incumbent on you to insure that your code will work (and compile) on that platform, and you do that by either (a) doing all your development work on a machine with Excel 97 installed and referenced or (b) using late binding or (c) setting minimum requirements and enforcing them using your installation tool.
Regarding ADO references, generally speaking you should use your installer to determine file versions, and require your end user to have version xxx or greater before allowing installation to continue. Or, of course, developing on a machine with the lowest common denominator (as above) and therefore not worrying about other references. Of course, ADO (actually you're talking about MDAC here) references are notoriously difficult to deal with; mis-matched versions of any of the hundreds of files installed by MDAC can cause you no end of trouble. The solution for this is the same as above: Make sure your end user has the correct version OR make sure your dev machine has the lowest common version.
Fair enough, I'm actually an empirical pragmatist with theoretical purist tendencies... (but not a poseur...lol)
I meant no offense.
I meant no offense.
empirical - theoretical - in the same mind? Probably is offensive but none taken. ;))