References?

[omega1]

Anyone seen this before? The scenario is -
A distributed application on ten machines - all running the MDE in runtime.
All machines are running perfectly.
Minor changes made to the application and new MDE built.
After roll-out, six machines work perfectly with the new version. The remaining four run the application but experience the dreaded "#Name" in various places. Revert back to the previous version - and all run perfectly again.
Cannot be missing files - have not called for any and previous version works.
Cannot be broken references - six are running OK.
Cannot investigate on any of the machines because they are running MDEs.
??

 

[RuralGuy]

See if there are any useful suggestions in this link.

 

[omega1]

See if there are any useful suggestions in this link.

Thanks for the suggestion RG. There might be a new suggestion here, but I think I have been through these loops before.
Because the problem is not consistent I am completely at a loss.
I don't think it anything to do with version numbers either, as the development machine hasn't changed and the target machines may or may not work depending on the application version that is run!

 

[boblarson]

Reference problems can occur at any time. You can use code to refresh references automatically so MDE's will work. See my post here:

http://www.access-programmers.co.uk/forums/showpost.php?p=658969&postcount=4

 

[omega1]

Reference problems can occur at any time. You can use code to refresh references automatically so MDE's will work. See my post here:

http://www.access-programmers.co.uk/forums/showpost.php?p=658969&postcount=4

Thanks Bob,
I will look at your suggestion next week and post a report .......

 

[omega1]

Reference problems can occur at any time. You can use code to refresh references automatically so MDE's will work. See my post here:

http://www.access-programmers.co.uk/forums/showpost.php?p=658969&postcount=4

Bob,
I have confirmed that under a successful installation, if I remove comctl32.ocx it generates the described problem, put it back and everything is OK.
However, the client machines are all using the same version of comctl32 as the development machine - and as I said before, if I revert to the previous version of the application, all is fine!
I incorporated your suggested code but all references were reported as good.
This is a real strange one!!

 

[gemma-the-husky]

i know this is late on this thread, but i've just had a similar issue

one user is experiencing error 3075, which has turned out to be the failiure of certain functions - in this case date()

now, they are using mde's, so i cant open up and check the references

so does your suggested code refresh the references in a mde bob?

btw, what is your query in there, "qrytestrefs"

thanks in anticipation

 

[boblarson]

i know this is late on this thread, but i've just had a similar issue

one user is experiencing error 3075, which has turned out to be the failiure of certain functions - in this case date()

now, they are using mde's, so i cant open up and check the references

so does your suggested code refresh the references in a mde bob?

btw, what is your query in there, "qrytestrefs"

thanks in anticipation

yes, it will work on an MDE (in fact that is why I had it). the qrytestrefs is extraneous. The code is part of an MSDN article which had you create that query to generate the references error. But you don't have to use it.

 

[omega1]

i know this is late on this thread, but i've just had a similar issue
one user is experiencing error 3075, which has turned out to be the failiure of certain functions - in this case date()
now, they are using mde's, so i cant open up and check the references
so does your suggested code refresh the references in a mde bob?
btw, what is your query in there, "qrytestrefs"
thanks in anticipation

Gemma,
It was that reference that was troubling me. I have discovered that it is most definitely something wrong in the references. The "minor" mod that I introduced included calling for the msword olb reference. This is what caused the problem on some m/c. Take out the olb reference and the problem disappears. I am still researching why it only fails on some m/c (it is nothing to do with file locations or versions).
BTW, refreshing the references with that submitted code is not much help - I run it in a modified form and it confirmed there were no broken references, yet the Date() function was failing - until I removed the olb reference.

 

[boblarson]

The best thing to do is to use late binding on objects instead of early binding. that will eliminate a LOT of your reference problems. I typically will use early binding for development but then will convert over to late binding for production.

 

[DJNickWatt]

Re-register the library on the offending machines using:

regtlib.exe

You may need to have a hunt for this file or get it from the microsoft site. Run it in a command prompt with /? for instructions. You'll need to also locate the file msword.olb with full path.

 

[gemma-the-husky]

i'm still not quite following this

i dont quite understand why my user is getting the error reported

eg, if i supply an mde with a reference to MS Access 10 Object Library (say), but they have MS Access 11 Object Library, is this automatically corrected in their system. It seems to me that using Bobs code just reconnects the path - if the target dll of the path doesnt exist then it cant reconnect (can it?)

[edit - ive read RG's thread nowe, which is also very useful]

 

[RuralGuy]

As Bob said in Post #10, late binding is the best answer and can still give you problems when going to earlier versions if you are using some function that did not exist in the earlier version library.

 

[DJNickWatt]

If you reference an older library in development and the user has a newer library USUALLY this is detected and corrected. It doesn't always happen but I haven't seen it not happen a very long time.

Now here's were it falls over more often. If you have the newer library and the user is running the older library it doesn't always detect the older one and hence you get the "MISSING:" object library problem. I've seen this happen a lot as I'm developing in 2007 and a number of my users are still using 2003. So what I have done is run both copies of Access on my machine. Go to Access 2003 to compile (checking references obviously). This also means that you have the older versions still on your harddrive.

Omega the msword.olb problem just existed on one of my users machines. No explanation. Used the old version of the mde and it was fine. Put the new one and it didn't work. Re-registering the library as I described above solved the problem.

 

[gemma-the-husky]

thanks all

well ive extracted the reference data to a table
i'll copy my dll's just in case, and have a look at djnicks regtlib suggestion

thus armed, i'll go to my clients and see what i can do

-----------------
now, one of rg's links suggested you cant reset the references in an mde, even if you could see them - i take it thats not quite right, bob?

 

[gemma-the-husky]

dj - i got regtlib, but i already had a version on my computer

your version does allow regtlib /?

but the other (slightly later - vn 7.10.3052.4) doesnt give the help message

is that likely to matter?

 

[DJNickWatt]

nah i wouldn't have thought so.

 

[The_Doc_Man]

The problem with sporadic reference errors is that references aren't an Access function, they are a registry function. And registries are unique to EACH MACHINE. Which is why some work and some don't.

Not only do you need to see the references on each machine, but you need to see the ORDER of references on each machine, because both of those factors are specific to one machine and one machine only.

This also applies to the "workgroup file" you are currently using because that is also a registry entry, not an Access thing.