Missing References in Access when using DB on different user's machines

Hello, I'd be interested in hearing from some of the experts here who manage databases on a topic that has been frustrating me a little bit.  In many of the databases I'm using, VBA coding requires that I create references to different .dll files.  However, on some user's machines they will not have the appropriate dll available (such as msoutls.dll).  These usually just requires a small amount of tweaking and removing these references to get the database to run smoothly, albeit without that feature.
My question is, aside from having identical workstations, what steps can I take to prevent these types of errors, if any?  What sort of practices do you advanced users go through when setting up a database that could be used on a variety of user's machines?

Thanks so much as always for the comments,
Bevo
BevosAsked:
Who is Participating?
 
danishaniCommented:
Hi there,

You can try to do your coding as much as in Late binding, so no references needed.
See below links on how to apply Late binding;
http://www.granite.ab.ca/access/latebinding.htm

In case you need references, see below thread on how to deal with this, in case of missing and in case when deploying an Access database.
http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

Hope this give some ideas and pointers for avoiding missing references and how to deal with them when deploying your Access applications.

HTH,
Daniel
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
In most cases you should code to the "lowest common denominator" - that is, if you know that all users will be using at least Outlook 10.0, then make your reference and compile the app on a machine running Outlook 10.0. Access can "upsize" references (from 10 to 11, for example) but cannot downsize.

However, as danishani suggest, late Binding is often a better choice. Using Late Binding, you can remove the reference entirely and Access/VBA will use whatever version is available on the machine. The only real issue with late binding is that you must be SURE to only use features/methods that are available in all supported versions of the library.

there's also some performace issues associated with late binding, but in general those aren't too impactful on modern machines.
0
 
Nick67Commented:
As @LSMConsulting noted, you do your developing on the machine with the earliest version of Office on it.
My environment has Access 2003/2007/2010 and Windows XP-32bit and Windows 7-32 bit and 64 bit.
I do my developing on an Access 2003 / Windows 7 Pro-64 bit box, and I generally don't have reference grief.

I had to learn that lesson the hard way, though.
I tried to lead the organization in moving to Access 2007.
4 months of busted references and corrupted forms, I gave up.
It was way too much hassle to open a db in a virtual machine, fix the references, and compile it--and remember to do so each and every time.

The Ribbon and the Nav Pain aren't my things anyhow :)
0
 
BevosAuthor Commented:
Thank you all for responding. Those were wonderful tips!

Best wishes,
Bevo
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.