Ehhh... how's that? DCOM is EXACTLY designed for this scenario. COM+ is basically DCOM for DLLs using a host container that's using the same RPC architecture that DCOM is using... it's the same technology with the same set of problems and limitations.

The reason this stuff breaks is typically for a couple of common problems:

* Address resolution fails on the network (IP or domain names)
* Servers have unloaded due to idle timeouts (which COM+ does handle a little bit better than DCOM)

Personally I think that either DCOM or COM+ for remoting are crap technologies that never worked reliably. The configuration nightmare it incurs plus the finicky network connection architecture that made it way to easy for remotes to become disconnected without the client being notified properly made this is a volatile technology at best.

+++ Rick ---


>While it won't help you solve this problem, I'm going to come back to my arguement that the "proper" way to this kind of thing is throught COM+. That's what it was designed for. It may require some rework of your code to get it working, but you will avoid problems like this. The whitepaper on my web site for more information.
>
>>Hi. I have a VFP 6 app running on multiple notebooks. They exchange data with the server using COM/DCOM. The COM server is also written in VFP6. Some of the notebooks are starting to get 'RPC server is unavailable' (when trying to CREATEOBJECTEX()). The affected notebooks are some of the ones they've upgraded to Win 7 or the latest XP patches.
>>
>>Any ideas?