>>You can call an ASP to instantiate the object on your server and do the exact same processing as you do now in VFP. Since it is VFp, you open the table normally and get the key and return it to your ASP. Then from there you can display it for your user.
>>
>>OTOH, you could just do the coding in your VFP application and do a call to the object on the remote server through DCOM. If you do this, you don't have to worry about a browser at all since it's all native VFP code.
>
>
>Whoa, Wayne!!
>Back up a step please!
>Just when I thought I was understanding all this stuff..... (I've been doing some heavy duty reading this past week - this is all brand new to me!).
>
>Can you please explain two things:
>1. How DCOM would be different than COM in this instance?
>2. I have a basic idea of how to create a COM Server, but what does it take to do something in DCOM? Is it a similar process? Do you know of any references that I could read to find out more about DCOM and VFP?
>

A DCOM component (a little redundant) can run on another computer. A COM component runs on the same computer as the calling program. A COM/DCOM component needs to be registered on the computer that will be using the component. Once it's registered, you're all set to use it. In the case of DCOM, when you create the object instance in your calling program, DCOM handles all the work of creating an object on a remote computer. Your program doesn't need to worry about the details, it uses it the same way you'd use any other object.

For more info on DCOM, take a look in the VFP manual under "Remote Automation".