Multiple MS Access Versions References

Hi Experts;

What is the best way to handle environments where there are multiple versions of Office/Access and Windows (7/8)?

I have managed to fix the 32/64 bit OS issues but am still having VBA reference issues. All versions of Office are 32 bit.

Is it best to put all the required reference files in a central network location and reference them there? Can I reference MSOUTL.OLB version 14.0 from this central location and have that work with the 2013 version of Office/Access?

I've had this issue in the past but cannot recall how I resolved this. I use a batch file to copy the front-end to the user's local machine each time they invoke the application.

Should I put some code in the batch file to copy these appropriate files to the user's local machines?

I would appreciate any direction/assistance you can provide.

Thanks a lot!

Eileen MurphyIndependent Application DeveloperAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Complain to Microsoft.  If Access can promote references (move to higher version), it can demote references.  If the app doesn't work, it is MY problem.  This problem is never going to be resolved if people don't complain about the issues it causes.

There are two recommended solutions.
1. Always develop in the lowest version.  That way when the app is distributed, Access will promote the reverences to the newer version.
2. Always develop using late binding.  I personally hate this solution because it prevents the use of VBA constants in code and prevents the use of intellisense.  It is also slower to execute since all references must be resolved at run time.  Not to mention the fact that you end up transferring what would be easily corrected compile errors to much harder to find (and potentially embarrassing) run time errors.

With early binding, you declare specific objects such as a word document but to do that, you need to include a reference to some Word library and unless you have multiple versions of Word installed, then your only option is the installed version.  Early binding allows you to reference constants defined by the declared reference library.  It gives you intellisense when referencing objects and it gives you compile errors when you make typos or misuse an object.  With late binding, you declare indeterminate objects, you must define your own constants since you can't use the ones from the object model's reference library and errors that would be caught with a compile won't show up until some hapless user executes the bad code.  So, your error handling better be robust.
Eileen MurphyIndependent Application DeveloperAuthor Commented:
Hi Pat!!! Thank you for responding. This is not a distributed product so that may simplify this issue.  Since the network environment is static and all users have read/write access to a share -- do you think that moving these references to a share and reference them there would stabilize the situation?

Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:

<<do you think that moving these references to a share and reference them there would stabilize the situation?>>

That's not something you want to do.  Some Dll's may be shareable like that, but all the main ones dealing with Office and Access are not.  Each set of DLLs is specific to the version and even more specifically to the build each user is running.  You'd break a lot of things if you did that.

The best setup is a distribution package with Sage Key installer so that you have an isolated install of the Access version.

Next best is what Pat suggested and most do; develop in the lowest common version and let things run in whatever the user has.

Note two things:

1. References cannot be demoted, so you don't want someone opening a DB with a later version, and then someone trying to open the same one with an earlier version.  You should not be sharing FE's anyway, so this is not so mcuh of an issue.

2. With late binding, what many do is develop with early binding, then switch to late for release.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Eileen MurphyIndependent Application DeveloperAuthor Commented:
Thanks for the advice! I appreciate it!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.