>I am very familiar with the article, and I have written several such applications.

>If this is the way that you define C/S, then I have already done it

>But here's the cool part. Using wwIPStuff, I can build the SQL in code from a client application, and post the result type as XML, and submit it from a client app. The result is passed back, parsed, and converted to a VFP cursor. All over the internet. I am using the same server method to service a client side VFP app, and to serve queries from a browser.

Agreed, tres cool!


>The server code that does this is quite simple.

That's VFP code you are talking about, right?


>I guess by the definition you are trying to establish, I have built a client server system that implements SPT all from VFP.

>But IMHO, this implementation does not a client server database make. You would still have to build connectivity into another development platform, include an XML parser, and unless the dev platform was able to bind to XML datasets, you would have to have another data format to convert to so you could bind controls. Either that or manually build ADO recordsets. (You can just imagine how blazingly slow that would be.)

>A client server data should subscribe to some standard (usually ODBC) that allows it to be easily access from heterogeneous clients.

This is where you lose me. If I can build a VFP server which can talk to a VFP client anywhere on the LAN or to an HTML browser anywhere on the Internet, isn't that enough? What other development platform should I be concerned about?
What other clients besides VFP and a browser should I be concerned about?

Peter