Our help desk not much help (1 Viewer)

[lcline]

Hi and thanks,
My company recently upgraged from Office '97 to '03. However, they decided to wait a while for Access '03. Since the upgrade, I have gotten an error message(see attachement) that prevents Access from launching when clicking on an db. If you open Access first, then choose the file, it will open. The contracted IT person has tried several reinstallations of both programs with no success.

The upgrade has been completed on at least 40 other pc's that did not exprerience the same error. However on about half, we had to redefine MS Access '97 as the default program to open .mdb files.

Please help me help the help desk,
Thanks!!

error message text
You tried to use OpenModule action or method, but Microsoft Access can't find the module you specified in Module Name argument.

 

[The_Doc_Man]

Odds are this is a references issue. In any Module panel, follow Menu path Tools >> References and examine the list of referenced modules. One of them will likely be prefixed with "MISSING:" - because it is not where Ac97 thought it should be. So you will have to browse for the file with that name (or a similar one). Once you do, you can repair the broken reference.

NOTE, however, that between Ac97 and Ac-later, a major rewrite occurred in the DAO library (leading to creating the ADO library) and also, many other modules were upgraded. Ac97 might not work correctly with the upgraded versions. You might have to reinstall Ac97 AFTER the rest of Office '03 in order to be sure the correct library modules are still available. 'cause I think the Office upgrade process might have deleted some of the older modules even though the names had changed and no conflict would have existed.

 

[lcline]

Thanks Doc that showed me where the problem lies. The db is calling the Calender activeX. It is located in the system32 file. There is no system32 file on that pc. What is the easiest fix? Can one be copied from another similar pc or will we need to reinstall the operating system?
Thanks again
Lee

 

[The_Doc_Man]

Yes, you can copy files to another system.

Though if it happens that you copy an ActiveX module, you might also have to register it, too. (That's another item under the Module's menu Tools item.)

I worry about "system32" - which is the name I associate with a windows folder. It is part of a path. But I'll suggest a possibility.

Suppose that you see the referenced file name as

C:\Windows\System32\....

On a later version of Windows, this might become

C:\WinNT\System32\....

or

C:\Win2K\System32\...

Actually, NONE of that matters, though. If you have the file you need, you can put it ANYWHERE as long as it is findable via browsing. In the case where I needed to do this, I put it in a folder underneath the one where I kept my .MDB file, just so it would be easy to find.

I doubt seriously that your problem is a file called system32 as much as it is something like MSCAL.OCX - which means you WILL have to reference and register this file.

In WINDOWS (Not in Access) do a Start >> Search >> Files or Folders

Find your MSCAL file and from there you will have no problem doing the other parts. On my desktop system at work, this file is located in two places.

One is in C:\WinNT\System32

The other is in C:\Program Files\Microsoft Office\Office

Do your search, find your files, reference and register them, and there you go, you're on your way.

BTW, you will probably have to do this for every system not currently set up to use this control, since references are a per-system configuration thing rather than a .MDB thing. Your references are in your registry under the HKEY_LOCAL_MACHINE hive.

 

[lcline]

Doc,
It was my mistake! I was using the "Browse" (in the module >> tools >> references option) to find the MSCAL.OCX file. Since it was in the system32 file it was hidden (dah) from that view. When i went to windows explorer, i was able to find the folder (system32) and the ocx was there. In fact there were 4 modules/options checked in the module >> tools >> references menu and all paths did lead to the specified objects.
Still not sure what is wrong unless it is in the registration as you said.
Thanks,
Lee