>I was encouraged to think along these lines by a white paper on Rich Strahl's site:
>
>"Building Non-HTML Web Applications with Visual FoxPro"
>
>http://west-wind.com/presentations/wchttp.htm
>
>It says in part:
>
>"But what if you could build an application using Visual FoxPro on the client side talking to a Web server on the other end of the connection that is also a Visual FoxPro application? Rather than using clumsy HTML you could take advantage of the power of VFP's User Interface and ease of data access to build a truly user friendly application and still get the distributability that HTML based Web applications promise."

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

>There may well be good reasons for that. Communication between VFP and SQL using views or SPT is well understood (by some if not by me). So what I'm trying to understand better is the communication between a VFP client and a VFP middle-ware or server program.
>

If this is the way that you define C/S, then I have already done it. One of my web server applications has a function that takes an SQL string as a parameter, and a result type as another parameter. The browser interface to this function is just an edit window where I can type in an SQL statement, and a dropdown listbox where I can specify the type of results: HTML table, Encoded DBF, XML, or even Excel spreadsheet. This comes in quite handy when a client wants to know some site statistics that are stored on the remote server. I just type in my query as if I was at a command prompt, select HTML table, and Voila, the results are right there in the browser.

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.

The server code that does this is quite simple. I just make sure that all tables are open or in the current path, I append " INTO CURSOR Tmp" to the passed in SQL, and I execute the SQL using macro substitution, trapping for errors along the way. Any errors are reported back to the client, but if the query is successful, the results are converted to the appropriate format using COPY TO, or a HTML Table building method, wwIPSTuff's EncodeDBF, or wwXML's CursorToXML.

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

Rick took this idea in a different direction. His method embedded the SQL statement in a XML documents as only one node. When you use XML for this, you can also do things like specify a server or connection name, include a username and or password, and build the result type right into the request. You can see details of his implementation in a sample he posted on his website.

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.