>>Forgive this really dumb question ... but
>
>Very good question, actually. My orginal message could have been clearer.
>
>>how does the above coding change allow one to access web data instead of local data.
>>Ultimately you open the customer table with the command
>>USE HOME(2) + 'Tastrade\Data\Customer.dbf'
>>isnt that local?
>
>I think you pretty much nailed it below.
>
>>could you clarify what
>>"Session OLEPUBLIC" means... ?
>>are building a .dll that sits on a machine at the different IP address and then 'SERVES' the data via XML ?
>
>Yes, thats exactly what I'm doing. The class is compiled as a COM object, and with VFP7, I can expose that COM object as a Web Service. So it would (in English) work like this:
>
>1. Your client app has a URL to a Web Service.
>
>2. Your client app can create an object based on the information store in that URL (this is called the Web Service Descrption Language, or WSDL)
>
>3. When your cleint app calls methods of the object it created based on the WSDL, messages are sent using HTTP to the Web Server.
>
>4. When the Web server gets the message, it knows to call and run your VFP function ON THE WEB SERVER, this is possible because your VFP function is exposed as a COM object.
>
>5. Once the function is done, it returns a value back to the web server, which is ultimatley passed back down to your client app.
>
>6. Your client app can use the result of the function call, that ran on another computer, just like it opened up the data lcoally.
>
>This may sound liek alot of work, but really, every single step is automatically done for you in VFP7 thanks to the SOAP Tool kit.
>
>Does that cliarfy?

yes it does...
thanks...

>
>>If indeed accessing web data between two machines is this simple... I'm buying VFP 7 tomorrow.
>
>Go for it :-)