Hi

I have created 6 COM objects and 5 work perfectly but the 6th one gives the error 0x80020009. If I do lo=CreateObject("dCFusionCmd") from VFP's command windows the object is created and all the methods work correctly. If I try lo=CreateObject("dCFusionCmd.dCFusionCmd") then I get the error. I am running VFP9 on Windows 2019 Server. I have compared the registry entries with my other COM objects and everything appears to be correct They all have the same entries in the registry.

I have unregistered the COM object and re-registered it using C:\Windows\Syswow64\Regsvr32.exe and it always reports success. I have removed all code from the Init method but it makes no difference.

Does anyone have any other suggestions as to what might be wrong?

Thanks, Simon

Hi

I am not sure I understand what the issue was but I found a small prg file included the project of the COM object that failed but was not present in the other projects. Once I removed it everything worked just fine. I am not really sure why the inclusion of an unused prg file affected the COM object but at least I have found the cause of the error.

Simon

If you're invoking a COM object locally that points at your current project (ie. the source files are all there) then it's better to use CREATEOBEJCTEX() instead to make sure the component loads correctly as a true COM object rather than loading from some components from memory or source.

Or better yet, make sure when you test the COM object create a new folder and test program in a separate instance of VFP.

This has bitten me many times before, so I can relate to this 😄

+++ Rick ---

Simon - how exactly did you find this unused prg? OI have been chasing the dreaded OLE error in my project for years. When the error occurs, we refresh a few times and it goes away - most likely because another instance of the same com object resets itself.

I checked the Project Manager to compare which files were included in the COM objects that worked vs the one that did not. I found an extra prg file listed in the project that did not work. I checked the project to ensure it was not used and then deleted it from the project and re-compiled the COM object. After that everything worked correctly. In my case the prg file contained my utility functions I use for most of my desktop applications.

Simon

Another reason for 0x80020009 error messages is when the VFP9R.DLL or VFP9T.DLL version does not match the VFP9RENU.DLL version. Basically, if you have the SP1 or SP2 runtime mixed with the original release of VFP 9.

This error can even be user specific, because there are VFP9Rxxx.DLLs for different languages (VFP9RDEU.DLL ist the German version, for instance). You can specify the language version with a command line switch. If you don't (the 99.999% case), then VFP uses the current UI language to load the appropriate DLL. If a particular user selected a different language, or more nasty, if the system language differs from the current UI language, then VFP might load a different resource DLL.

A possible cause is that the computer already had several of the original language files installed, but your setup only updated the VFP9RENU.DLL file, because that is all you thought you need.

Christof

Yeah I've seen that as well. I've done customer trouble shooting sessions where we were spinning our wheels for these random COM errors - those are fun to track down. Even if you know about the issue, it's still very likely you'll miss the symptoms and it'll likely be the last thing you think of to fix 😄

That's why I always recommend doing a full runtime install - especially for server installs - and either install the runtimes locally in the app folder (for non-component apps) or in the proper global location. No custom installs or if you do making sure to drop all the necessary files for a complete runtime install including those locales that you may not use.

+++ Rick ---

Hi Christof,

I just stumbled across this post once again after getting tired of seeing the OLE errors in my app on an intermittent basis. I discovered that sure enough I have a mismatched vfp9renu.dll. I updated vfp9r and vfp9t to the older versions, rebooted it, and we shall see.

C:\Program Files (x86)\Common Files\Microsoft Shared\VFP VFP9R.DLL - 4/3/9 - 4624kb VFP9T.DLL - 4/3/9 - 3816kb VFP9RENU.DLL - 10/15/07 - 1.13mb

I wondered where we might discover what the official latest versions of the three files are?

The latest versions are available from two different places. The official release is on:

https://docs.microsoft.com/en-us/previous-versions/visualstudio/foxpro/mt490121(v=msdn.10)

This is VFP 9 Service Pack 2. There are three cumulative hot fixes available. You can either get them through Microsoft Support (in theory) if you are affected by any of these issues, or you download them from VFPX:

https://github.com/VFPX/VFP9SP2Hotfix3

The latest version are 9.0.0.7423 for VFP9R.DLL and VFP9T.DLL, and 9.0.0.5815 for VFP9RENU.DLL. The hot fix did not update the language specific files.

Runtime installers are available at

http://www.foxpert.com/download/runtime.html

https://github.com/VFPX/VFPRuntimeInstallers

Thanks for the quick response.

Based on what was mentioned in this thread, I was thinking that the versions id's would all match. I guess it is safe to assume that you have used the three files together without COM errors ?

9.0.0.7423 for VFP9R.DLL and VFP9T.DLL 9.0.0.5815 for VFP9RENU.DLL

ps: I had my first COM error after putting the matching files I mentioned previously. Seems I have some other issue in my code that leads to "Forced Release of Server" or "RPC Server Unavailable (Invoke): Attempting to Reload Server". We do lots of remote mySql calls and I assume the external request was 'bad' or ambiguous leading to a long request.

The board software ate my message again... Yes, I've used these versions in COM servers together. The combination SP2/HF3 is the only one were different version numbers are valid.

The error looks like a WebConnection issue rather a general VFP issue. Maybe this has additional information:

https://support.west-wind.com/Thread5JF1BO80A.wwt