>Without trying to justify why anyone would want to do this, I would like to understand the possibility of an all VFP client-server solution. I'm talking about a VFP server program using VFP tables and talking over a network to VFP clients. I'm assuming that the VFP server would maintain exclusive access to a set of VFP tables which would store the data for many clients. It would have little or no UI. The clients would use local cursors but would not maintain any permanent tables.
>
>1) Has anyone done this?


Not that I know of.


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

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.

There is a reason that databases like SQL server and Oracle cost a small fortune: They cost a small fortune to develop. These are not simple pieces of software.


Not sure if it was worth a damn, but that's my 1.5¢.