Dear Mike:

Now I know I am showing my ignorance, but others will benefit from the conversation. Often you cannot learn if you do not show your ignorance.

So a DCOM object behaves like a stored procedure on a server.
Can a DCOM object be run on a standalone Win95 or Win98 workstation?
How about NT Workstation or Windows 2000?
Of course it can run standalone on an NT Server since it would likely be running as a service.

In a nutshell, what is the difference between DCOM, COM, and DLLs?

Thanks
Bruce Strom


>>Once I write this DCOM object, should I call it from my FoxPro application?
>
>"Should" you? Depends on what you need. If you need to use it in a VB app, then by all means, call it from VB. It's a standard COM server, so call it from whereever you like.
>
>>Can I run Foxpro reports from DCOM objects, or should I use Crystal instead?
>
>Umm, I don't think you can run reports from a VFP COM server. I could be wrong, I seem to recall that there's some problem doing this. In short, I don't know. :-)
>
>>Would calling it from FoxPro mean that I have two instances of FoxPro running?
>
>Yes, but one will be on the client and one on the server. There will always be an instance on the server, because the VFP runtime has to be running in order to instantiate the COM server.
>
>>Or would it not make any difference whether the routines are imbedded in >FoxPro code or called as DCOM objects?
>
>That, of course, becomes a question of why you're using DCOM in the first place. Using a DCOM server, you will be passing data over the wire, and that means overhead. You also have to deal with marshalling, and that takes overhead, too. However, if the client is a P200 and the server is a quad P500 with striped SCSI drives and 500Meg of RAM, then the overhead of sending data across the wire may be comparatively trivial. Like I said, it all depends on what you're hoping to accomplish.