[AccessD] Set references via automation

 > I read the article as saying the same thing I was saying.

Yep.

What I am after is actually storing the references outside of the container, opening the container 
with C# code and deleting / (re)creating the references "on-the-fly".  The reason I want to do this 
is simply that the whole "use the reference if it is found otherwise search and recreate the 
reference" causes me (as the developer) immense problems.  I carefully set up references to specific 
paths on the C:\xyz\ directory, store the database container on the network and then... my client 
opens the file in place and the file "fixes" the broken file automagically.  Except I wanted the 
reference I had, not the reference it fixed it to.  He didn't even know that this "fix" was 
occurring and neither did I.

So my objective is to download the files and the libs, open the FE, delete specific references (to 
these libs) and rebuild them, referencing the lib files in the directory that I just downloaded the 
libs to.

This is a different task, though similar to just "fixing broken references".  I mean to delete the 
references and recreate them entirely, at a location of my own choosing.  And notice that I am only 
discussing just the references to my libs, I am not discussing various and sundry issues with things 
like versions of excel etc.  However it occurs to me that if I copied the excel lib to a specific 
location as well, I could fix the reference to that as well.  The whole "what version of office is 
on your machine / early / late bind" issue would suddenly become a non-issue.

I just spent a looooong few days battling what turned out to be references which managed to find and 
"fix" to old outdated copies of my framework.  Who really knows what is sitting out on a user's machine?

Sigh.

With my new tool I will know precisely where I am putting things and fix the references to the files 
that I have just copied.

It turns out to be trivial to read out the references for an access container.  Store that "one 
time" in a child table out in my tool and voila, I know where to go and get the file that is really 
needed for a given access container - even things like excel or word libs.

Note I have not yet actually *done* this.  ;)  But I have the rest of the copy and run app up and 
working.  Adding this is an incremental upgrade to what I already am using.

John W. Colby
Colby Consulting

Reality is what refuses to go away
when you do not believe in it

On 1/1/2012 10:00 PM, Charlotte Foust wrote:
> John,
>
> I read the article as saying the same thing I was saying.  In the code you
> run from autoexec, you disambiguate everything but the VBA call he
> suggested is to check a particular reference to see if VBA is broken.  I
> believe you'll find that you still need VBE to do the fixing because it can
> be called without loading VBA.  Calling things using the VBA library in
> disambiguated calls doesn't fix a broken reference.  You have to test each
> reference to see which one is broken and fix it before you load VBA.
>
>
> Charlotte Foust