>>It all makes perfect sense, and should be fairly straightforward to do, but I can't figure out what DNS has to do with anything.
>Erik!
>I guess I'm trying emphasize that the remote DBFs reside on a Web Server, rather than some other kind of network server.

It really makes no difference. With one, you might specify a machine name, with another, an IP address or web domain.


>I think I'm also trying to emphasize that: Rather than an HTML Client submitting calls to a CGI engine, the client would be a VFP form (not ASP or Active Doc), and it would connect to the Server VFP DBMS through (the) DCOM.
>

Right.

>So.. the part about forwarding parameters across DCOM seems workable? DCOM can do a VFP connect to the server DBF, pass arguments for record points, and store results in VCX properties. Little bits of data like this could be stashed in a DCOM property, thus forcluding an immediate foray into XML or ADO (right?).
>


Yeah, that would work, but why? Neither XML nor ADO is all that difficult to implement (there are plenty of samples out there for using both), and using one of these would mean doing it right the first time. You can set yopur properties, call your method that populates properties, and then retrieve those properties, but over a remote connection this is a lot of overhead, and a design like this prevents you from taking advantage of the ability of MTS to scale a stateless object.

>I guess its time to do some local tests. Is the only difference between COM and DCOM, the fact that DCOM is local to the server, while COM is local to the client?

Yep, and the setup. DCOM is considerably trickier to configure, but just as easy to use (from a programming standpoint, the usage syntax is identical).