Problem with References

crhodus

Registered User.
Local time
Today, 03:20
Joined
Mar 16, 2001
Messages
257
A few days ago, I copied a database that I'm working on to a user's computer so that he could review and test it. He received an error stating saying something like this, "Missing Visual FoxPro Type Lib info control" . In the VB editor, i clicked on Tools, References. I then uncheckd a box next to the Missing Type lib. This corrected the problem. Today, the same thing occured.

The error occurs on this line of code:
If IsNull(Me![CallID]) Then
Me![Call Listing Subform].Form![CallDate] = Date

The Date is what is throwing off the program.

Can anyone tell me how I can stop this from happening again?
 
To be precise about it, No. Nobody can tell you how to stop it with any guarantees. We can, however, tell you that it is a known glitch with Access. And I can give you a suggestion about how to stop it on a case by case basis.

You are getting burned because Access is not too good about keeping track of references. I refer you to the Microsoft Product Support articles #Q160870 and #Q197110.

In summary, Access and references are a case of the left hand not knowing what the right hand is doing. References, in order to work right, have to be in the individual computer's registry. But if you move the database to a different machine, the contents of that machine's registry can be different. On the other hand, the actual list of references is still in the database. They are merely ENABLED by the registry. Or something like that, it gets kind of confusing after a while. To show you just HOW confusing, the problem is not with the Date function at all. It is just that when you open the database, that is the first function it comes to when it detects that you have an unresolved reference.

The references include all sorts of information that is so specific that if you do something like install a Windows service pack you can whack the Access references - because the version number of the module might be updated.

The only way I have found to assure that this problem doesn't occur is to get to the references installation dialogue box. Find all the files that are MISSING: in that box. When you highlight the MISSING entry, a part of the box shows you the names of the specific files it wants to see. Get those exact files from the machine where you keep the database master copy. Put them on a shared drive or otherwise make them available to be copied. Then, whenever this problem occurs, copy the files and reassert the references.

You can search this forum for other views on the subject; mine are not the only ones that apply here. Supposedly there is a way to automatically install missing reference files, but the catch is that if the files are truly missing, the install won't work - a real CATCH-22 if ever there was one.
 
I decided to reply in both spots...

Could making an .MDE possibly prevent future installs from making changes or does this problem reach deeper than an MDE would protect?

Thanks again.
 
Thanks for your help. I will have to do this the next time it occurs.

Do you know what will happen if I lock my VB project from being viewed, when this error occurs again?
 

Users who are viewing this thread

Back
Top Bottom