Access 2003 object class does not support set of events (1 Viewer)

[Processor]

I have 2 computers i5 and an i7
Had trouble with the above problem. They both run win10 64 pro and are both upto date
Using office 2003 pro. On both.
I have cured the i7 by office repair followed by a decompile and it now works fine.
On th i5 i have done same to no avail, also imported into a new database. Still same problem.
Does anybody know why this happens and a cure.

 

[CJ_London]

no idea at the moment, but might help if you give us a clue as to what the object is that is causing the problem.

Can only suggest reinstalling office 2003 on your i5 machine

 

[Ranman256]

Each PC may have a different version of OS vs Access ver.
Esp. Office 15 vs Off 16.

If the app uses Object references to say Excel, or word, you must edit the VB REFERENCES, to the new office objects.
so, edit on the LOWER version of office. Usually if the controls are set to Off 15, you can copy the app to an Off16 PC and they automatically upgrade themselves to Off 16 versions. (not always but usu.)
BUT
if you go backwards ,edit on Off16, then copy to Off15, ...FAIL.
you must enter VBE (alt-F11) , Tools, References,
then uncheck the MISSING objects ,and check the more current versions.

Also, use PTRSAFE on all API calls to prevent errors on 64bit OS.
once you've updated the objects, THEN distribute.

 

[CJ_London]

@ranman - OP is using 2003.

but always something to check anyway

 

[The_Doc_Man]

The key to understanding Ranman256's suggestion is whether you are running a 32-bit vs a 64 bit version of Access - but I don't recall that Ac2003 even ALLOWED that option. I thought that the 64-bit option came in at Ac2007.

The question will be whether the computers running these apps are on the same version of Access that you named (Ac2003) AND don't have a higher version of Access installed. Mixed versions of Access could cause a problem.

His suggestion to check references is an excellent idea, though. And that could certainly cause the issue. The other part of this is knowing which object is causing the problem. If this is some commonly-used external Application object, like Excel or Word, that shouldn't be a problem. But there are other things you could be running as an App Object that might not be so common. So the first part of this thread of troubleshooting is to try to determine which object is barfing.

 

[Processor]

references are as follows access 11 object lib, MS DAO3.6 object lib, MS Active x Data Objects 2.1, VB for applications
Software is Access 2003 32 bit.
=DLookUp("[client_nam]","[clients]","[account_no]='" & [Account] & "'") seems to be the problem on load
hope this helps as it is fine on I7 system and is identical.
I5 is running compatabilty pack for Office 2007 as well as on I7
I5 is Lenovo 520 desktop I7 ASUS zenbook
hope this helps

 

[Processor]

Also have found that command buttons used in 2003 are also giving the same error including the Close form
'DoCmd.Close' but if switched to a macro and use 'close' form there is fine.
Also if you use the switchboard menu system gives same error on load.

 

[isladogs]

Doc
For info, 64-bit was introduced with Office 2010. VBA7 was introduced at the same time to handle it..

@Processor
Please can you explain why you have the Office 2007 compatibility pack. What purpose does it serve with Office 2003?

 

[Processor]

Allows you to open docx,xlsx etc without having to upgrade .
A lot of people use it

 

[isladogs]

Thank you. I'd forgotten that even though I had it myself many years ago when I still used 2003.

 

[The_Doc_Man]

From this description, it HAS to be EITHER a missing reference or the ORDER in which a given reference is being tested or something else to do with the References list. I've seen it before, when a seemingly innocuous function like DoCmd.Close fails even though it HAS to be one of the simplest functions in existence. It occurs because something is blocking the scan of the library for its entry points. This is when the order of appearance of something makes a difference.

If you use the Tools >> References dialog, you can identify the locations of the supposed references. Verify that you actually have permission to use those files. There are ways to install things other than "All Users" so if it was installed incorrectly, that could have an effect.

You might also wish to check the Windows Update History on both systems to see if there is a difference in the version of Windows.

In my list of "it has got to be..." above, I omitted the need to repair the installation because you reported you had already done that. But if you had not, an installation repair would have been next on my list.

 

[Processor]

I may have found out why I have this problem on my I5. I have 2 users on the system and the first user under which the software was installed and another user I switch to for other matters. Its the other user that has problem as I have found the original user does not have the problem with the same database at all. So is this a compete re install for all users of the original software???