Missing ADOX Library & Vista

[scott]

A while back I posted a message concerning an Access app I have that
requires the "Microsoft ADO Ext. 2.8 for DDL and Security" library. I
created this app running on XP and have had no problems.

However, the user of this app recently bought a new Vista pc and this app
always caused a problem after I made changes to it and then deployed it on
his Vista pc. Both my pc and his are running Office 2003 pro. This is the
problem:

1. When I'm developing on my XP pc, I'm using the "Microsoft ADO Ext. 2.8
for DDL and Security" library.

2. When I copy my working version to his Vista pc, vba code errors prevent
opening the app. Vista gives a "Microsoft Office Access has stopped working"
error. It then displays another error alert stating that it can't find the
access mdb file that I originally clicked. This happens because the
"Microsoft ADO Ext. 2.8 for DDL and Security" library is missing on Vista.

3. The fix is to create a blank access database, import all objects from the
failed mdb version. Then sets the reference to "Microsoft ADO Ext. 2.6 for
DDL and Security" library.

4. Even worse, when the Vista-working mdb file is copied to the XP machine,
XP won't open it because Access on XP no longer has a "Microsoft ADO Ext.
2.6 for DDL and Security" library. Another strange thing is once back on XP,
I'm allowed to hold the SHIFT-key and click OPEN to get the failing mdb
open, but when I go to REFERENCES, the "Microsoft ADO Ext. 2.8 for DDL and
Security" isn't in the list any longer!

5. The fix on XP is to repeat STEP 3, except select the "Microsoft ADO Ext.
2.8 for DDL and Security" library which will show in a new blank database.


So now, after explaining the problem, is there a way to detech which OS is
running within my Access app and then dynamically load either the ADOX 2.8
library for XP or the ADOX 2.6 library for Vista?

 

[Douglas J. Steele]

Far better than detecting which OS is being used would be to use Late
Binding instead of setting a reference to ADOX at all.

Tony Toews has an introduction to the topic at
http://www.granite.ab.ca/access/latebinding.htm

 

[scott]

Thanks for the link. However, I went ahead and added a couple of functions
to load/unload the reference from a file. It turns out that both XP and
Vista use the same msadox.dll file, just different version numbers.

I don't need it because the code is the same for both, but is there any API
calls that can detech the OS?

 

[Douglas J. Steele]

While I believe you're setting yourself up for disaster, there's code to
detect the operation system at http://www.mvps.org/access/api/api0055.htm at
"The Access Web". Unfortunately, that code's a little out of date. See what
Randy Birch has at http://vbnet.mvps.org/code/helpers/iswinversion.htm for
Vista-related values.

Seriously, though, Late Binding is definitely the way to go in this case. I
work in a very controlled environment, where I can be assured that every
user has exactly the same basic desktop, and I still use Late Binding for
everything I do. I'd suggest you read
http://www.trigeminal.com/usenet/usenet026.asp and
http://www.accessmvp.com/DJSteele/AccessReferenceErrors.html for information
about what problems you can expect to run into with your approach.

 

[Tony Toews [MVP]]

Seriously, though, Late Binding is definitely the way to go in this case. I
work in a very controlled environment, where I can be assured that every
user has exactly the same basic desktop, and I still use Late Binding for
everything I do.

Even that environment can cause troubles. What if some of the users
of your app have migrated to a new version of Office and others
haven't? References to Word, Outlook and Excel would be exceedingly
troublesome.

Now I know you know that Doug, I'm just pointing it out for others.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/