Yes, that's correct. This component runs on the PC where data is located, so it should have a means to communicate with the client to get the request and return the result set. If it is DCOM, it might be the call to DCOM method to pass the query parameters or name of the procedure/method to execute on the server PC (that would be similar to calling the stored procedure in SQL Server), and it can return the result set different ways - for example using ADO or XML.
In case of my FoxPro DOS application, client and server exchange through small DBF files. The client PC writes the request DBF and starts watching for the small result DBF to appear in certain server PC directory. Some security features can be provided by the network administration with limiting the user rights to this directory. Also on the server I have a little VFP application running, which is a Server Monitor and takes care of the FoxPro DOS server well-being. FoxPro DOS 2.5 server bombs around every 28800 requests with Error 1308 - "Insufficient Stack Space". In this case it automatically shuts down and the Monitor runs another instance of the server. You can see the picture here: http://www.geocities.com/redfoxpro/miscellaneous/


>Let me see if I understood. The idea would be to create a middle tier component to access the VFP database, just as a database server? This is an approach I always had in mind, but never had the time to implement and test.
>Please I would like to have your comments Nick and Erik.
>
>>>>I understand that Chung is using a VFP database as his backend.
>>>>
>>>
>>>Then that's not really Client/Server...
>>
>>Just as a side note.
>>
>>You can have a real Cilent/Server with VFP database if you use DCOM on the LAN, or idea of FoxPro Server. I consider here only some properties of the Client/Server model - ability to get the requests from remote PC, perform all queries and data manipulations on the server and return only the small result set, when nothing else is going over the network. I set aside here the data access and security features of the Client/Server.
>>Of course, it may not be the viable solution for some particulary application needs, but there are the cases when you might consider it.
>>As I mentioned in another thread (Benchmarks for VFP versus SQL Server Thread#485384 Message#486533), I just created such a client-server solution for big FoxPro 2.5 DOS application where the new functionality requred to query and calculate the data from 50-100 million records FoxPro 2.5 datastore about 10 GB in size.
>>This gives you all power of FoxPro data manipulation language for the LAN application with practically no network traffic.