>Greg,
>
>At this time I'd recommend you don't use DCOM (or COM+) for remote execution. It's extremely difficult to get the remote setup configured right, and more importantly life time management is all but impossible. Servers will time out and not automatically reload and there's no way to control this. IMHO it never worked really well even in the heydey of COM when it was amongst Microsoft's recommended technologies.
>
>It's better to look at other approaches for remoting. Web Services can work well, or simply having a Web server on the other end to handle incoming requests and serve the response. The problem is there no real good native FoxPro server solutions unless you delve into third party stuff or using other technologies like .NET as the gateway. For example, .NET has remoting which actually works fairly well across machines with minimal configuration and you can self-host many .NET technologies like WCF and ASP.NET Web API in standalone applications or services that you control and install. Ultimately I think that's the best solution: Hosting a service of some sort (FoxPro, .NET or otherwise) on the remote and then feeding it remote requests somehow. Whether it's over HTTP or via a common semaphore sharing solution - it all beats DCOM/COM+ by a long shot.
>
>+++ Rick ---
>
>

Hi Rick, and what about a remote linux machine? I mean, I have a Windows client that has to access Foxpro data that is on several linux servers which are hundreds of miles away. What I'd need to accomplish that, if it can be accomplished. What would I need on the linux machines so that it can return results from queriyng the foxpro data on them?

TIA