A problem occurred while Microsoft Access was communicating with the OLE server or ActiveX control (1 Viewer)

[pdanes]

I have a database that is throwing that extremely unhelpful error about "A problem occurred while Microsoft Access was communicating with the OLE server or ActiveX control". It is a single-file DB – not split. All tables and queries open normally and correctly.



I've tried all the usual things: decompile/recompile, C & R, look for missing references, security properly enabled, trusted location, etc. All that is exactly as it should be – no problems, but the problem remains.



This DB started life almost 20 years ago and has gone through dozens of updates, always working fine. It runs fine now on all my development machines: an old 2008 server with Access 2007, three different Win 10 desktops, one Win 10 notebook and a Win 11 notebook, all with Office 365. Opens everywhere without a hitch and everything works properly. But the customer for this DB just got a new Win 11 desktop machine, into which he installed Access 2019, and that is where this error is cropping up. It is happening in the start-up form, but when I open Access with Shift and manually try other forms, they act the same way.



The start form is unbound, with two subforms – one bound to a query and the other unbound. The source query for the bound subform works properly. When I try opening just the bound subform, it also throws this error. When I click the error message away a few times, it eventually pops up a dialog about wanting a parameter – one of the field in in the subform, but when I give it a value, it goes back to the initial error message. When I put a breakpoint on every single bit of code that would be called from any event in the the subform, none of it ever gets activated – it throws this error on opening and never even enters VBA. When I remove ALL the event calls (some to event procedures, some to functions), the error goes away and the subform (datasheet) opens properly.



The database was developed on a Czech machine, but the new machine is also Czech, and I am very careful about things like control names, field names and table names – strictly US ASCII, no spaces, no special characters.



It's not a corrupt form – again, it works perfectly on numerous other machines, and multiple forms fail in exactly the same way on this problem machine.



I've pretty much run out of things I can think of to try. Anybody have any ideas?

 

[The_Doc_Man]

OK, what version of Access works on the other Win11 machine (notebook) you mentioned? Also, if you go through the Settings >> System to find the version of Windows, are the two Win11 machines the same version of Windows?

Just as an experiment, can you copy the version from the system that is failing to the notebook - where you said you had a working version - and actually open that failing version correctly without any other modifications? I.e. trying to rule out whether the problem is a failed file copy or a difference in system environment. You said you had done some testing but this fine point wasn't clear.

You say it runs on Ac2007 and when using Ofc365, but when you open an Access database with a newer version of Access, it might upgrade the DB file in a way that would prevent returning the same copy to another machine with a different version of Access. So there is a concern regarding versions of Access and whether a newer version of Access has touched the file before you deployed it.

 

[arnelgp]

same with post #2, you probably has English MSO while the db was created in Czech MSO.

 

[tvanstiphout]

This error occurs because you have form bound to a table with a field with "OLE Object" data type. This only functions properly if the application associated with the object stored in this field is installed on the machine. For example, you may have stored a Lotus 123 Spreadsheet in this field, and if Lotus is not installed, KABOOM.
This is why we often say NEVER to use this data type, and to store the objects (files) in the file system rather than the database.

If you don't need these objects anymore, delete the field from the table.

 

[pdanes]

I have not yet tried copying the failing file back to a working machine. I will try that today, and and get the two version numbers.

There are no OLE fields in the tables that feeds any of these failing forms. There is one OLE field in one table, which provides some images to the ribbon.

Everything was created on Czech machines. I live in Prague and do not even have a US machine.

Access in the 2019 machine was deleted and re-installed - no change.

I provided the user with a small test database, with a single table and single form, that only creates records and a command button to delete them. Works perfectly.

 

[pdanes]

Customer has removed 2019 and re-installed 2007. Same problem. Now I don't know what to think. Something screwy in Win 11? But it works on my Win11 notebook with O365.

 

[mike60smart]

On The Customers PC create a new blank Db and then carry out an Import of all objects from the Db giving the error.

 

[pdanes]

On The Customers PC create a new blank Db and then carry out an Import of all objects from the Db giving the error.

Okay, I can create a new DB and import things, but if I import only the problematic forms, nothing will work - they are heavily reliant on things that do work. And what purpose would that new DB serve?

I'm not trying to be obtuse, but I don't understand what you're proposing as a fix, or even a test.

 

[mike60smart]

Okay, I can create a new DB and import things, but if I import only the problematic forms, nothing will work - they are heavily reliant on things that do work. And what purpose would that new DB serve?

I'm not trying to be obtuse, but I don't understand what you're proposing as a fix, or even a test.

Hi

No You have to Import all Objects - Tables / Forms / Queries/ Macros /& Modules.

This has fixed this error for me in the past.

 

[pdanes]

You mean import every object in the database into a new one? That would be a LOT of work - there are hundreds of such objects, and many non-importable things, like custom document properties. I would have to manually re-create all those. And again, this DB works properly in many other places. Just this machine is throwing fits. I'd be more inclined to think there is some odd setting or configuration in this specific machine, especially since it does so in now two different versions of Access.

 

[mike60smart]

You mean import every object in the database into a new one? That would be a LOT of work - there are hundreds of such objects, and many non-importable things, like custom document properties. I would have to manually re-create all those. And again, this DB works properly in many other places. Just this machine is throwing fits. I'd be more inclined to think there is some odd setting or configuration in this specific machine, especially since it does so in now two different versions of Access.

Hi
It does not involve a lot of work, you just select the Object ie Tables and click Select All, Do this for all Objects and that's it. Just 10 Clicks and you are done.

If you try it and the problem still exists all you have done is waste approx 5 minutes.

 

[pdanes]

Okay, I did it. Bypassed all the custom document properties. Same problem in new DB.

 

[Minty]

The only likely cause I can see based on your fault finding so far is something in the underlying Query for the bound subform, that it doesn't like.

Remove the subform source object from the opening form, and manually set it in the main forms load event, this will at least begin to breakdown where the issue sits.

 

[pdanes]

The only likely cause I can see based on your fault finding so far is something in the underlying Query for the bound subform, that it doesn't like.

Remove the subform source object from the opening form, and manually set it in the main forms load event, this will at least begin to breakdown where the issue sits.

The source query is an ordinary Select statement, and works fine on its own. It is non-updateable, but that is intentional. And numerous other forms in the DB throw the same error when I launch them by hand. Normally, they are all called from the ribbon, or an occasional button on a form, but they can be started manually as well. Not always will they work, because some of them depend on things being prepared by the calling code, but they can be launched. Some throw the same error as the main form, some bork when they try to run the OnOpen event code, mostly when a subform tries to refer to Parent.<something>.


SELECT Z.ZaznamAutoId, Z.TypZaznamu, tT.Rod & ' ' & tT.Druh AS Druh, tT.Rod, tT.Rad, Z.RokOd, Z.MesicOd, Z.DenOd, Z.RokDo, Z.MesicDo, Z.DenDo, Z.Char, [Katastr] & IIf(InStr([Katastr],'[')=0,' [' & [OkresKraj] & ']','') AS KatastrCely, tO.Oblast, Z.Kvadrat, Z.Lokalita, Z.Zdroj, Z.Pocet, Z.PocetOdhad, Z.Elevation, Z.Zapsano, Z.Zapsal, Z.Poznamka, Z.ProtokolCislo, IIf(([RokOd] & IIf(IsNull([MesicOd]),'','/' & Right('0' & [MesicOd],2)) & IIf(IsNull([DenOd]),'','/' & Right('0' & [DenOd],2)))='',Null,[RokOd] & IIf(IsNull([MesicOd]),'','/' & Right('0' & [MesicOd],2)) & IIf(IsNull([DenOd]),'','/' & Right('0' & [DenOd],2))) AS DatumOd, IIf(([RokDo] & IIf(IsNull([MesicDo]),'','/' & Right('0' & [MesicDo],2)) & IIf(IsNull([DenDo]),'','/' & Right('0' & [DenDo],2)))='',Null,[RokDo] & IIf(IsNull([MesicDo]),'','/' & Right('0' & [MesicDo],2)) & IIf(IsNull([DenDo]),'','/' & Right('0' & [DenDo],2))) AS DatumDo, Z.TaxonAutoID, Z.AOPK, IIf(IsNull([GPSLat]),Null,FormatGPSLat(ScaledLatToDec([GPSLat]),ReadCustomDocumentProperty("GPSFormat")))+', '+IIf(IsNull([GPSLon]),Null,FormatGPSLon(ScaledLonToDec([GPSLon]),ReadCustomDocumentProperty("GPSFormat"))) AS GPS, Z.GPSLat, Z.GPSLon, Z.KatastrAutoID, Z.PohlaviAutoID, tP.PohlaviSymbol, tP.Pohlavi, Z.OblastID, tCh.ChUV, Z.CHUVAutoID, Z.Oznaceni, Z.GPSOdhad, IIf(tD.Doklad & IIf([DokladNeurcite],' ?','')='',Null,tD.Doklad & IIf([DokladNeurcite],' ?','')) AS Doklad, Mid([Poznamka],6,255) AS PoznamkaSRT, Left([Zdroj],255) AS ZdrojSRT, IIf([Pozorovani],Chr(149) & IIf([PozorovaniNeurcite],'?',''),'') AS P, IIf([Znaky],Chr(149) & IIf([ZnakyNeurcite],'?',''),'') AS Z, IIf([Odchyt],Chr(149) & IIf([OdchytNeurcite],'?',''),'') AS O, IIf([KadaverSilnice],Chr(149) & IIf([KadaverSilniceNeurcite],'?',''),'') AS KS, IIf([Kadaver],Chr(149) & IIf([KadaverNeurcite],'?',''),'') AS K, IIf([Fotopast],Chr(149) & IIf([FotopastNeurcite],'?',''),'') AS F, IIf([Detektor],Chr(149) & IIf([DetektorNeurcite],'?',''),'') AS D, IIf([Netting],Chr(149) & IIf([NettingNeurcite],'?',''),'') AS N, IIf([Ulovek],Chr(149) & IIf([UlovekNeurcite],'?',''),'') AS U, Z.DokladAutoID, tK.Katastr, tK.DefaultOblastID, tK.DefaultKvadrat, tK.DefaultChUVAutoID, NOT IsNull(tK.DefaultOblastID) AS OblastJeZKatastru, NOT IsNull(tK.DefaultKvadrat) AS KvadratJeZKatastru, NOT IsNull(tK.DefaultChUVAutoID) AS ChUVJeZKatastru, Z.BiotopAutoID, tB.Biotop, Z.Foto, tK.OkresKraj
FROM TableOfTaxons AS tT INNER JOIN ((TableOfChUVs AS tChDef RIGHT JOIN (TableOfKatastrs AS tK LEFT JOIN TableOfOblasts AS tODef ON tK.DefaultOblastID=tODef.OblastID) ON tChDef.ChUVAutoID=tK.DefaultChUVAutoID) RIGHT JOIN (TableOfBiotops AS tB RIGHT JOIN (TableOfDoklads AS tD RIGHT JOIN (TableOfOblasts AS [tO] RIGHT JOIN ((Zaznamy AS Z LEFT JOIN TableOfPohlavis AS tP ON Z.PohlaviAutoID=tP.PohlaviAutoID) LEFT JOIN TableOfCHUVs AS tCh ON Z.CHUVAutoID=tCh.CHUVAutoID) ON tO.OblastID=Z.OblastID) ON tD.DokladAutoID=Z.DokladAutoID) ON tB.BiotopAutoID=Z.BiotopAutoID) ON tK.KatastrAutoID=Z.KatastrAutoID) ON tT.TaxonAutoID=Z.TaxonAutoID;

 

[Minty]

Okay - that query is quite an unpleasant read

There is nothing I can see in that SQL that would cause an issue, and as you say numerous other forms are giving you the similar problems on this machine only, that work perfectly on other similar machines.

You could try not loading all (both) the subforms after the main form has loaded, (using the same technique outlined above) and see if that removes the Parent reference problem, but it looks to me that we are down to something specific in the set up on that machine.

If you remove Access completely, and install a runtime only does it work?
Is the Access installation part of an MS office install?

 

[pdanes]

Okay - that query is quite an unpleasant read

There is nothing I can see in that SQL that would cause an issue, and as you say numerous other forms are giving you the similar problems on this machine only, that work perfectly on other similar machines.

You could try not loading all (both) the subforms after the main form has loaded, (using the same technique outlined above) and see if that removes the Parent reference problem, but it looks to me that we are down to something specific in the set up on that machine.

If you remove Access completely, and install a runtime only does it work?
Is the Access installation part of an MS office install?

Yeah, I didn't bother formatting it because there is nothing in it I wanted anyone to try troubleshooting. Just showing that there is nothing exotic in it - a vanilla-grade Select with some Joins and a bit of formatting. And it works perfectly.

I can try importing only the minimum of tables, queries and forms to make it capable of starting and and see what that does. I also suspect it's something specific to that machine, since (1) all other machines handle it fine, and (2) both 2007 and 2019 throw the same error, and ONLY in that machine, and the error is essentially nonsense.

I don't have direct access to the machine, or at least not easily. I have been communicating with the user and logging in to the machine with a remote desktop application, but have gotten no further than I was from his original description of the problem. I was considering a personal visit to the customer, because it's fairly close, but since I'm completely stuck on what to even try, I don't see a personal visit as anything that would improve the situation. Response time and monitor resolution would be better there than over the RDP link, but aside from that, I could not do much more there than I can do remotely.

Yes, the machine has the entire Office package in it, but I don't know now whether he ditched the entire 2019 package and re-installed Office 2007, or just Access and left the rest of the package in 2019. I will look tomorrow and see if I can make the entire situation clearer.

 

[pdanes]

Okay - that query is quite an unpleasant read

There is nothing I can see in that SQL that would cause an issue, and as you say numerous other forms are giving you the similar problems on this machine only, that work perfectly on other similar machines.

You could try not loading all (both) the subforms after the main form has loaded, (using the same technique outlined above) and see if that removes the Parent reference problem, but it looks to me that we are down to something specific in the set up on that machine.

If you remove Access completely, and install a runtime only does it work?
Is the Access installation part of an MS office install?

Just got hold of the customer. The installation is the entire Office package. He cleared out the 2019 installation and put in the entire 2007 bundle, which throws the same error as the 2019 version.

 

[The_Doc_Man]

This description is still confusing. If the package is the same one you used for Ac2019 and you step back to Ac2007, it SHOULD NOT work because the package, having been exposed to Ac2019, cannot step back to Ac2007 - even if you step back Office versions as noted.

That error,"A problem occurred while Microsoft Access was communicating with the OLE server or ActiveX control", is a generic error message for Access that says whatever actual utility Access has called returned an error - but it doesn't tell you what error that implied utility returned.

 

[pdanes]

I'm not sure what you mean by package. Do you mean the database? It opens normally, both previously in the 2019 version and now in 2007, and messing with it does not show any oddities that I can discern. It compiles, the immediate window runs expressions properly, the VBA editor works, the forms designer works, queries operate normally, tables are populated exactly correctly. Just trying to run forms throws these idiotic error messages. Removing all calls to event code makes some of them open without error, but of course, they are then completely useless.

 

[pdanes]

This description is still confusing. If the package is the same one you used for Ac2019 and you step back to Ac2007, it SHOULD NOT work because the package, having been exposed to Ac2019, cannot step back to Ac2007 - even if you step back Office versions as noted.

That error,"A problem occurred while Microsoft Access was communicating with the OLE server or ActiveX control", is a generic error message for Access that says whatever actual utility Access has called returned an error - but it doesn't tell you what error that implied utility returned.

The actual .ACCDB file is not the one that I tried in 2019. The user brought over a fresh copy from his other machine, which still has 2007 and where it all works normally. I never tried opening a version in 2007 that had previously been opened in 2019. I can look in the trash, if you think that might be worth trying - might be something there. But I'm not sure what that would tell us.