Slightly off-topic, but...

Another alternative is to not use DCOM at all in this case. With all of the XML capabilities in VFP7 and VFP8, you could have your client send the call over HTTP (using the WinHTTP object) to an IIS machine, and have a simple ASP page do a createobject on your DLL and pass it parameters. Your COM server could then put the results in an XML string or even a cursor with CursorToXml() and then pass that back to the caller. It will probably be as fast or faster than DCOM and a whole lot safer because you only have to have a single web port open. Also, you can change the server side all you want without having to (re)register anything on the client; just keep the server name/port/asp page the same and the client will never be impacted by your code changes.

And if you think you need more speed, you are still free to put the server-side DLL in a COM+ server application so it always stays instanced.


Just alternative (and a better one IMHO) to a client doing createobject().


>Hi Vin
>The Dcom is not in com+ server, but is in mts that is almost the same. I've tried to create a client executable to register the dcom from mts, but the mts creats the folder "client" (where an executable for registration must to be), but the folder is empty. What did I do wrong?
>Which is your alternative to createobject()?
>thank you