>
>Hmmm.... OK, I think I understand what you are saying, but now I have 2 more questions:
>
>1. With COM the component runs on the Web Server, with DCOM it runs on a different machine other than the Web Server. What would be a good example of WHY you'd want to use DCOM?

You might run the DLL inside Microsoft Transaction Server (MTS) that is running on another machine. You'd do this for scalability and performance.

>2. You say I have to think 'connectionless', with this in mind, is there going to be a problem if one of the jobs my COM object is trying to do is to write data to a VFP table that is sitting on the user's machine? If it's 'connectionless' will it be able to see and write to the table on the user's machine?

No. I can only write back to the place that created it, ie: and active server page. The client application knows nothing about the COM object. However, you can make it work the way you want, but the client will need to run Internet Explorer. I don't think this will will work in Netscape.

1. With your application, you will distribute COM component A (COM-A).
2. The user will go to your web site in their browser and enter the code.
3. The ASP script on the web server will launch COM component B (COM-B)
4. COM-B will determine the key that is needed and return this information to the ASP page in the form of an ADO record set.
5. The ASP page will generate a return HTML page and send the HTML page and the ADO record set to the client.
6. The HTML page will instantiate COM-A on the client.
7. COM-A processes the ADO record set and updates the VFP table.

Simple, huh!

>
>Thanks!
> ~ellen