>>A VFP COM object can handle this just fine. The ASP page can call the COM >object, then return the key and generate the HTML page with the result. The >user could use any browser.
>
>Thanks Craig and Josh, at least I know I am headed in the right direction......
>
>OK, if a VFP COM server is part of the answer, then I have some other questions.
>1. What are the considerations to determine if I use an .EXE or a .DLL?
>2. What does the user need on their machine to run this whole process? IE4 and what else? Does my VFP COM object run on the server or locally on the client/user's machine?
>3. What is the best way (again, just in general) to pass data out of a table (in this case it's an access table ) to my COM object?
>4. If instead of just showing the user their Registration Number on the screen, I wanted to pass that number back to my VFP program and do 'stuff' with it (encrypt it and save it in my VFP table), what is the best way to do this? Again, at this point I am looking for real general 'hints'.
>
>Thanks again -
> ~ellen
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.


Wayne

Wayne Myers, MCSD
Senior Consultant
Forte' Incorporated
"The only things you can take to heaven are those which you give away" Author Unknown