John said:

>Practically speaking however, is a different story. VFP's data engine is file server based, not client-server based. In terms of the benefits of what a client/server architecture can provide, you won't see them.

>Basically, take away the VFP data in favor of SQL-Server, Oracle, or some other C/S RDBMS, and you will be on your way....

Could you spell-out some of the benefits that SQL can provide that VFP cannot? (I know they are there; just trying to be clear.)


Erik said:

>>2) What kind of data-transfer protocol would be used?
>
>You would need to make it ODBC, or OLEDB.
>
>>2a) HTTP?
>>2b) DCOM?
>>2c) ??
>
>I don't think either of these address the issue. To make a Client Server database, you need to make it accessible to any language that knows how to access data. This generally means ODBC, or OLEDB. You could make the entire interface COM only, but somebody already did that: ADO. I don't think exposing your data only through a COM interface would allow it to qualify as a client server database.
>
>>3) What kind of network would be required?
>>3a) TCP/IP?
>>3b) NT Server?
>
>It should be irrelevant.
>
>
>If you wanted to do it, here's how I think it would have to be done (resisting the nearly overpowering urge to ask why the HELL you would ever want to do this):
>
>Write a VFP (or VB or whatever) application to manage which tables and databases iwll be served. As soon as a table is added to the "database" it should be opened exclusively. This application will also be responsible for security, table maintenance (reindexing, packing), logging, etc.

I'm with you here.


>The second and most important part is way over my head, but you need to make your application an ODBC or OLEDB application. MS publishes what is required to write an ODBC driver or OLEDB provider for any data source: that's what you've gotta do. You can't do it in VFP, you'll have to use C.
>
>You could do a lot of things in between to compromise, but until your data is reachable through an ODBC interface, it is not client server.


Hi, John and Erik.

Thanks for answering.

For the purpose of this discussion, lets define Client/Server (at least as I mean it).

1) C/S is not file server. In a file-server architecture each client opens the files it needs in shared mode which reside on a file server. If any client bombs at an awkward moment a file can be damaged. In C/S only the server has the files open and only the server can damage those files.

2) C/S does not mean open architecture (programs written in many different languages can access the data.) For example, most folks understand Power Builder to be C/S but that is not open.

3) C/S means that only result sets are sent across the network.

4) C/S as opposed to web-server/browser means that a very powerful UI can be presented to the user.

Other advantages to the VFP-VFP client/server architecture:

* Full Rushmore optimization at all times since bitmaps are never sent across the network.

* All VFP data manipulations commands (SCAN, SEEK, REPLACE) are available at all times.


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."

[snip]

"The good news is that you don't have to build distributed Web applications with HTML. It is absolutely possible to build an application using a rich UI and use the Web simply as a database interface to communicate. The key to make this work is HTTP - the HyperText Transfer Protocol."

Rick says this approach will work across a LAN as well as the Internet.

I'm not claiming that the data should not reside in an SQL database. That would mean a three-tier architecture like:

VFP client
VFP middle-ware
SQL backend

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.


OK: why do this? If this could be made to work reliably there would be major marketing advantages for a product which did not require an SQL add-on.

Peter