Problem "With Communicating with OLE Server" Using Non-Latin Alphabet Databases

[MajP]

I kind of stop helping people on this site that post databases not developed in a Latin alphabet based database (examples Arabic, Cyrillic), because I run into too many problems that cannot be fixed without a rebuild from scratch. The problem I see often is this message when I try to modify code or other design changes.

AFAIK the users do not see these errors when designing in their own databases.

The only success I have had is to rebuild the form from scratch.
So in the above example the form runs fine. I added a click event procedure without any code. Same if adding other events. There is no code in the event procedure. There are no ActiveX controls, no OLE Objects, no broken or missing references. And the expression clearly results in an "[event procedure]'".

I have tried
1. Decompile
2. Creating a new database and importing objects
3. SaveToText and LoadFromText on the form

This is similar to what I have seen in other non-latin alphabet developed DBs. So the error message AFAIK is unrelated to the real problem due to language incompatibility
.
Unfortunately the form I need to fix is pretty involved and I am not desiring to rebuild it for the user. I will likely provide the code and have them try entering themselves.

Anyone seen this, and have any ideas? Any settings that can be adjusted? I have seen the issue often and only on non-latin based dbs so this problem is not unique to this form or database.

 

[sonic8]

Any settings that can be adjusted?

I assume, the problem is triggered if any character was used inside the VBA environment that is not part of the character set you configured for VBA on your computer ("Language for non-Unicode programs"). - This would be a setting to adjust, if you want to work on the file without fixing the problem.

Even though the error message appears to be misleading at first glance, it may actually be not far off.
"The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure]."

And the expression clearly results in an "[event procedure]'".

Well, yes, but not really. The EventProcPrefix property stored in Access with Unicode support is different from the actual event procedure in the VBA project without Unicode support. This might not necessarily apply to the event procedure you just added but a different one that prevents the module from being compiled.

I have tried
1. Decompile
2. Creating a new database and importing objects
3. SaveToText and LoadFromText on the form

All these steps preserve Unicode characters in the Access form and control properties. - I'm not surprised that they didn't fix the problem.

What should work if my hypothesis is correct:

1. Export using SaveAsText
2. Remove/replace all non-ANSI characters in control names
3. Remove/replace the corresponding characters in the VBA code
4. Import the files with LoadFromText.

 

[MajP]

Thanks I will give it a try.

 

[MajP]

Wow! That worked well! There was probably 100 controls on this form. I did a Saveastext and did a Find on "Name". Of all the controls only one used non latin alphabet. This was only an image control showing a static picture. Changed it and it worked. However this control did not have any associated events.

This fixed conditional formatting that would not work at all on the form.

I probably should post this a seperate thread with the solution. I scoured the internet and no one even got close on this answer.

 

[KitaYama]

Just to clear some misunderstanding here, I don't think this famous error is because of non-English object names.

I'm on an English version of Windows 11, English version of Office 365 and all of my apps are in English.
I've never (again never) have used non-English object names, never a non-English word in vbe.
Yet I'm facing a 90% (not 100%) chance of receiving complaints of the same error about my uploaded databases here.
My guess is, it's because of my locale in control panel which is set to Japanese. And as I discussed a similar case in this post with Sonic8, I believe it's because of the same ASCII codes are rendered differently in different fonts. Japanese fonts render 0x5C (ASCII 92) as ¥ (Yen sign), but other fonts render the same AscII as \.

And the fun part is that I don't have any problem with @MajP and @isladogs uploads, but I've never been able to open the samples that @Edgar_ has posted. I receive the same error on his databases.

Just my 2 yens.

Edit : I receive the same error when I try to open third database in this post. (The OP is from Brazil, so I assume it's Spanish)
And my money is on none of you receive this error on that database. So, the core of this error can not be non-latin object names. If it was, then both me and you should be facing this error.

 

[NauticalGent]

(The OP is from Brazil, so I assume it's Spanish)

Not that is matters, but it is probably Portuguese.

 

[KitaYama]

Not that is matters, but it is probably Portuguese.

Because we're talking about character sets, Ascii and their possible effects, it matters a lot.

Thanks for the correction.

 

[isladogs]

In this context, it shouldn't matter whether a file is in Portugeuse (Brazil) or Spanish (Mexico). Both use the same Latin (ASCII) character set

 

[GPGeorge]

Not that is matters, but it is probably Portuguese.

Yes, that's Brazilian Portuguese in the screenshot.

 

[KitaYama]

In this context, it shouldn't matter whether a file is in Portugeuse (Brazil) or Spanish (Mexico). Both use the same Latin (ASCII) character set

Meanwhile , we'll be waiting to see the results coming back from Access team (per your post here)

And thanks for your efforts to solve this.

 

[isladogs]

I’ve had one possible suggestion from MS related to locale. Hence my question to the OP in the other group.
Having said that, the issue has existed for 25 years + and at least one MVP thinks there is no solution that will always be guaranteed to work.

 

[KitaYama]

there is no solution that will always be guaranteed to work.

 

[Edgar_]

Just to clear some misunderstanding here, I don't think this famous error is because of non-English object names.

I will try to inspect if there's a solution. I was able to open the arabic file by renaming objects with names written with arabic characters to export and import the form as text. After that, the file worked for me.

It's interesting that my samples are causing issues for you, @KitaYama. Typically, my samples come from a Spanish installation of Office 2016. Correct me if I'm wrong, @isladogs, but as far as I know, the language of Office can only be changed through a separate installation, is that right?

 

[isladogs]

No. The Office language can be changed from Access options

 

[KitaYama]

I was able to open the arabic file by renaming objects with names written with arabic characters to export and import the form as text.

But apparently that method didn't work for me and others.

Just curious : When non-Latin object names cause these kind of troubles, why simply opening the form in design view and changing the names doesn't help? But exporting as text, changing the names and importing works. What's the difference?

 

[The_Doc_Man]

I am stepping in only to offer a guess to KitaYama's post #15.

The difference MIGHT be the language of the libraries implied with the project. You can change the language of Access itself but what about the reference libraries? Do THEY change if you change the language of the Access environment? This is a GUESS - but as to "what is the difference?" The difference might be hidden in a library.

Now, here is a question for someone else to investigate because I don't have the means to do this test very well. IF you get that error even if it does not crash the application, there is a CHANCE that you would get an event log in either the SYSTEM event logs or the APPLICATION event logs. If you do, the error is frequently recorded to two levels deep. You will get the stack frame for the error and the stack frame for the caller of the errant code. So, for example, you might get an error code and address for Access itself (MSACCESS.EXE) PLUS the module name and a second address for whatever was called. If it is one of the referenced libraries, that might be a useful clue.

 

[Edgar_]

But apparently that method didn't work for me and others.

Just curious : When non-Latin object names cause these kind of troubles, why simply opening the form in design view and changing the names doesn't help? But exporting as text, changing the names and importing works. What's the difference?

I tried and did it step by step this time. Procedure:
1. Go into the immediate window
2. Type the class name of the form with a problem, followed by a dot to trigger intellisense. The idea is to manually check if there's any element with a weird name.

3. Found 3 elements with weird names.
4. I checked the types and confirmed that they are section names. I was suspecting that would be relevant because, for instance, in Spanish, the detail section is labeled "Detalle," and you can see this in the IntelliSense list. However, it doesn't appear in the debugger list. To resolve this, I changed the section names to Latin characters. All three sections in the form had their names written in Arabic, which caused them to display as unreadable characters in the IntelliSense list.
5. I test the form again and it keeps triggering the error.
6. I export it as text and import it again
7. It no longer triggers the error.

As for why? Office objects are stubborn, they tend to not show everything that is under the hood. Getting rid of the defective object and importing a cleaned up version may help our cause. Another step I didn't mention is that I went through the text of this file and looked for this expression: Name =" so I could quickly determine whether there was anything initialized with a non-latin name.

In other development environments, I also try to go to the "source of truth" to fix things from their root, when there is no other choice. If the root is even available and if I can make sense of it, of course. In the case of our development environment, I would say the export/import pattern is our best ally before going too low. It did work in this exercise, anyway, for me, of course. I'll keep testing.

TL;DR
To fix that error, all I had to do is modify the names of the sections with latin characters, then I exported/imported the form again. I went straight for the sections because they tend to be initialized with a name based on the locale of the application.

Let me know if you still get the error.

 

[Edgar_]

Now, here is a question for someone else to investigate because I don't have the means to do this test very well. IF you get that error even if it does not crash the application, there is a CHANCE that you would get an event log in either the SYSTEM event logs or the APPLICATION event logs. If you do, the error is frequently recorded to two levels deep. You will get the stack frame for the error and the stack frame for the caller of the errant code. So, for example, you might get an error code and address for Access itself (MSACCESS.EXE) PLUS the module name and a second address for whatever was called. If it is one of the referenced libraries, that might be a useful clue.

Here's what I could find

Log Name:      OAlerts
Source:        Microsoft Office 16 Alerts
Date:          6/27/2025 9:17:54 PM
Event ID:      300
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      LAPTOP-
Description:
Microsoft Access
The expression After Update you entered as the event property setting produced the following error: A problem occurred while Microsoft Access was communicating with the OLE server or ActiveX Control.
* The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure].
* There may have been an error evaluating the function, event, or macro.
P1: 502473
P2: 16.0.14334.20090
P3:
P4:

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft Office 16 Alerts" />
    <EventID Qualifiers="0">300</EventID>
    <Version>0</Version>
    <Level>4</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2025-06-28T03:17:54.4370170Z" />
    <EventRecordID>1216</EventRecordID>
    <Correlation />
    <Execution ProcessID="22904" ThreadID="0" />
    <Channel>OAlerts</Channel>
    <Computer>LAPTOP-DKCV3JNL</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Microsoft Access
The expression After Update you entered as the event property setting produced the following error: A problem occurred while Microsoft Access was communicating with the OLE server or ActiveX Control.
</Data>
    <Data>* The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure].
* There may have been an error evaluating the function, event, or macro.
</Data>
    <Data>502473
</Data>
    <Data>16.0.14334.20090
</Data>
    <Data>
    </Data>
    <Data>
    </Data>
  </EventData>
</Event>

 

[KitaYama]

4. I checked the types and confirmed that they are section names.

Last question : How exactly you checked for the types of the object with strange names?
Thanks.

 

[The_Doc_Man]

Thanks, @Edgar_ - it appears that though the error was logged, it didn't give the "deep format" I expected. In a way, I almost wish that it would actually crash the process (rather than leave it in the GUI) because that might have led to one of the more detailed error messages I am more used to seeing. It was worth a try but sometimes these things don't work out as hoped/expected.