This problem is probably asked about a hundred times here and elsewhere, but I can't find any reports of it uing google.

When I copy an access-2003 from one machine to another, upon first open it says that a certain reference is missing.
One then has to open the references, remove the missing link, CLOSE the window, reopen and reselect the formerly missing reference which now is on the list. Things work ok from then on.

The two pc's both run win2k and axs2003.
I've tried moving the one offending ref. in its placement a buit lower but it does not help. Though I have not tried many positions for it.

Any suggestions on how to fix this will be most appreciated.

__________________
Tim

By inspecting the registry I verified that the 3rd party dll was a slightly different version for one pc to another.

Assuming that is the correct explanation:
This was a problem since when the code is protected and the project sold.
I now worry about the client upgrading the 3rd party dll and if the link goes missing at that time again which requires the unclick/click which is normally closed to them.

Tim

Everything that is available in the unlocked version can be exposed in the locked one through dialogs you build.

Write a test for this condition, and if it crops up—in VBA—find the references, show them on a form with appropriate controls for each reference to remove it, and allow opening a dialog to go find the right file to set a reference to, updating the references collection with that info.

There might be an easier way, but this could be done...

Thanks.
But not quite.
The references diaplay is a simple thing by the NAME of the server libraray.
I can check for broken links and remove them, very easily using the application.reference object.
The problem is that to add them I will need the full path to the dll on the local machine.
I can also add by guid but can't expect the user to type the horrendous guid.
Unless there is a way to get ALL library names and ask them to select from a list.

On the other hand, it is possible that different versions of a server ALWAYS have the same guid.
If I can be sure of that, then I can write the guid in the code and display the name only.

Tim

The GUID is created when a package is built. So the GUID should be associated with the application. No matter what machine the tool is installed on, the GUID should be the same. Sometimes the GUID is associated with a specific version of the application. If the GUID is different for different versions, you'll just have to try registering each version specific GUID until it fixes the reference.

Do be careful in your code. If a reference is missing, some of the simple VBA functions won't work. (E.g. InStr(), Left(), etc.) You can avoid having your code break by dereferencing those functions in any code that might execute before you have the references fixed. (E.g. VBA.InStr(), VBA.Left(), etc.)

Randall J Weers
Membership Vice President
Pacific NorthWest Access Developers Group
http://www.pnwadg.org

Thanks RJ.
Yes it seems that the guid should stay the same with different versions.
However, in the one test case I just looked at, things seem worse than I thought.

The (broken) ref. with the different version is easily detected and its guid is still detectable, but its NAME is missing, and reference to it causes error (they could have had the forethrought to set it simply to null).

Worse yet, the Reference.Remove method fails since it is not registered.

Neither of These is the same as removing the check box in front of the MISSING ref in the references listbox where the name is clearly visible and "remove" by way of uncheck, does not cause an error as in .Remove.

If only there were a way to lock the code and make the references visible to the end user, life could be so much easier. For reasons unknown to me, only the opposite is possible!

Any further suggestions will be appreciated.

Tim

Just a quick note. I've read the words "lock the code" in a couple of the postings.

If "lock the code" means you are making an MDE or ADE file that your users run, you WILL NOT be able to change references. When the code is "compiled" (i.e. when an MDE or ADE is made), you are stuck with whatever file was referenced at the time of compile.

If this is what you're doing References.Remove will never work. I got the impression that you were NOT making an MDE/ADE because you indicated that you were successfully using the Application.References collection.

If "lock the code" means setting a password on it using the VBA Editor, I don't know whether you can change references while the code is locked.

I have something that I think is working for MDB/ADPs. But I have to think about it a bit. I'm just not sure why your References.Remove failed. Since you're removing a reference object (not simply removing the object by name), it shouldn't matter whether all of the properties of that object (including the Name) are set. ??? And I'm not sure that what I'm doing works with password protected code.

Randall J Weers
Membership Vice President
Pacific NorthWest Access Developers Group
http://www.pnwadg.org

You know, depending on how you are using the tool's functionality, there is another way around this. If the tool is only used in VBA (not on forms), instead of...

Having a Reference to the library and having code that looks like this...

Dim objX as ToolLib.Object
Set objX = New ToolLib.Object
objX.Property = [whatever]

you could leave off the reference to the library and have code that looks like this...

Dim objX as Object
Set objX = CreateObject("ToolLib.Object")
objX.Property = [whatever]

Using this method you don't get IntelliSense while you are developing. But there are ways to get around that ... Use the Reference and Dim the object as the ToolLib.Object while you're developing then remember to remove the reference and Dim the object as Object to test and deliver your app.

Randall J Weers
Membership Vice President
Pacific NorthWest Access Developers Group
http://www.pnwadg.org

I've considered this as much as I have time for right now. I think my last solution is your best bet. It will work as long as the names of the classes in the tool's library don't change between versions. Since you think that changing the reference to the correct library will work, the names of the objects should not have changed between version.

It is possible this solution will work even if the tool is used to add objects to forms/reports.

Randall J Weers
Membership Vice President
Pacific NorthWest Access Developers Group
http://www.pnwadg.org