I swear when I saved this link there it was probably 10 pages long if printed
and explained how to (programmatically) go through and verify all references
and reset them to what you needed. Now I pull it up, I don't see much of
what I thought was here... maybe it got updated, maybe it never was and I'm
losing it.
But anyway, there is some helpful information for Mike Kaplin on how to
handle reference issues. You may find some answers, if not all.
http://www.trigeminal.com/usenet/usenet026.asp
--
Jack Leach
www.tristatemachine.com
- "First, get your information. Then, you can distort it at your leisure."
- Mark Twain
"CrazyAccessProgrammer" wrote:
> After I've finished building a database for someone, I use the Access 2007
> packaging wizard (including the Access 2007 runtime) as the method of
> deployment of the database to the user.
>
> One problem I routinely run into is when the user installs the database they
> get an error that a VBA reference library is not installed on their machine
> and that the situation must be resolved before the database will function.
>
> This message is often very cryptic to an end user. As a result I have the
> following questions related to VBA Library References:
>
> 1) Is there an easy way to detect if any VBA Code in my database utilizes an
> active VBA Library Reference? If I could determine that a certain active VBA
> Library Reference isn't even needed, I could simply uncheck it before I
> package the database.
>
> 2) If a VBA Library Reference is needed by my database, but not available on
> the end user's machine, what steps can I take beforehand to ensure that the
> database will install and 'just work' for the end user? Is there a way to
> ensure that all VBA Library References will be packaged using the Access 2007
> Package Wizard? Or is there some other kind of solution I'm not even thinking
> about that results in a deployed database 'just working' after the user
> installs it?