A Problem occured while MS Access was communicating with the OLE server or ActiveX Control. (1 Viewer)

[SORM2]

Hello all,

My application worked perfectly in around 200 users except for 1 person. He uses the same Access version with us (Prof. Plus 2016). He uses the same language for access, Windows and region language settings for unicode. However he gets this problem when he opened the application. I have tested with very quick access creating a form and creating the opening event says welcome for this form. and send this access to my friend. He got this error message even in this access. When he created the same small test from stratch in his own access in his computer. it workes. VBA Code is completely same. Everything is same.

And the access that he created for this welcome message test is also not working in our access. I could not explore the solution. I will be appreaciated any help. I am sure you have faced it before. (I have attached the error message as attachment in this topic)

Thanks

 

[theDBguy]

Hi. No offense, but if their file doesn't work on your machine, and your file doesn't work on their machine, then I can't help but doubt both machines have the same system configuration. If you're sure the Access versions are the same, perhaps some other settings are different. Just a thought...

 

[The_Doc_Man]

It might be difficult to check this, particularly if the app has been secured somewhat to prevent "diddling." However, when you talk about aberrant machines that otherwise appear to have the same configuration, there is the issue that you could have registry-level differences. For instance, the references involve the registry, which IS unique to each machine. Or at least the HKCU and HKLM hives are unique to each machine.

First thing to consider: If you can arrange to validate that the machines have the same references, do so.

Second question: In a shop big enough to talk about 200 users, you probably have an IT support staff. Ask them if among your 200 users, some of them have different Group Policies in place than others, and if so, see if those differences correlated to the failing systems.

 

[SORM2]

It might be difficult to check this, particularly if the app has been secured somewhat to prevent "diddling." However, when you talk about aberrant machines that otherwise appear to have the same configuration, there is the issue that you could have registry-level differences. For instance, the references involve the registry, which IS unique to each machine. Or at least the HKCU and HKLM hives are unique to each machine.

First thing to consider: If you can arrange to validate that the machines have the same references, do so.

Second question: In a shop big enough to talk about 200 users, you probably have an IT support staff. Ask them if among your 200 users, some of them have different Group Policies in place than others, and if so, see if those differences correlated to the failing systems.

Hello The Doc_Man,

Thanks for comment. How can I check which references are used in the machine? I will look at it tomorrow accordingly.

 

[The_Doc_Man]

If you can see the DB in a developer mode, you can call up the VBA code. From the VBA screen, the menu bar allows you to use Tools >> References. The complex box that crops up shows you the names of library modules that are checked (near the top of the list) and many more that are NOT checked. The latter are listed mostly alphabetically but the checked items can be raised or lowered in order of reference using up and down arrow keys to the right of the list box. For two machines to have the same references, the same exact libraries must be checked and they must appear in the same order. Normally, order doesn't matter. But depending on Access versions, if you are using both DAO and ADO, both of which support the Recordset object, and if your code doesn't supply qualifiers to show which one you mean, then the order of appearance of the libraries makes a difference. There are other cases, but that one is the most common.

 

[SORM2]

If you can see the DB in a developer mode, you can call up the VBA code. From the VBA screen, the menu bar allows you to use Tools >> References. The complex box that crops up shows you the names of library modules that are checked (near the top of the list) and many more that are NOT checked. The latter are listed mostly alphabetically but the checked items can be raised or lowered in order of reference using up and down arrow keys to the right of the list box. For two machines to have the same references, the same exact libraries must be checked and they must appear in the same order. Normally, order doesn't matter. But depending on Access versions, if you are using both DAO and ADO, both of which support the Recordset object, and if your code doesn't supply qualifiers to show which one you mean, then the order of appearance of the libraries makes a difference. There are other cases, but that one is the most common.

Dear The Doc_Man, Today I tested the both machine's access references. They are completely same and in the same order. But the application which is created in his machine gives the error message in my computer and vice versa.

 

[The_Doc_Man]

From each machine, open Access, then hit the File tab and look for Help near the bottom. That will bring up a screen with a column of options and a banner on the right for Microsoft Office. The second section of that right most column will be headed by "About Microsoft Access" and under that will be a "version number" line and a parenthetical statement of (32-bit) or (64-bit). See if those are both the same.

 

[mike60smart]

Hi
When I last saw this error I created a New Blank database.
I then Imported all of the objects from he database giving the error message.
Did a Compact & repair and it then worked just fine.

 

[SORM2]

Hi
When I last saw this error I created a New Blank database.
I then Imported all of the objects from he database giving the error message.
Did a Compact & repair and it then worked just fine.

Hey mike60smart, Yes it workes in this way. However When you think that you need to do that for more than one user and for each updated version of appllication, It does not seem the ideal solution. After doing what you told, the working application because is still not working in my computer in that time :S

 

[SORM2]

From each machine, open Access, then hit the File tab and look for Help near the bottom. That will bring up a screen with a column of options and a banner on the right for Microsoft Office. The second section of that right most column will be headed by "About Microsoft Access" and under that will be a "version number" line and a parenthetical statement of (32-bit) or (64-bit). See if those are both the same.

Dear The Doc_Man, Should those version numbers be completely the same? I will test tomorrow.

 

[The_Doc_Man]

The "bitness" (32/64) should be the same. If not, we have identified a problem.

 

[SORM2]

The "bitness" (32/64) should be the same. If not, we have identified a problem.

Hi The Doc_Man, iI think today I solved the problem. There were some non-english words in the word headings in the forms which I did not realize. I have changed all of them. It seems now it is working. Thanks for the help.

 

[The_Doc_Man]

Interesting, though non-English words would not inherently cause issues. They are just text. But did they involve non-ASCII text? Like UTF-8 encoding or something similar? That might confuse the world a bit.

 

[SORM2]

Interesting, though non-English words would not inherently cause issues. They are just text. But did they involve non-ASCII text? Like UTF-8 encoding or something similar? That might confuse the world a bit.

No, there is not ASCII Text. There is some charachters like "İ", "ı" in the other tab of propery section of forms. So it seems they were the reason of the problems.