Erik,

Really appreciating your advice here...

>>- ODBC driver on server
>It depends on where the VFP database is...
>

The VFP data is on a file server (unix) local to the "servers".


>>- VFP database on client
>It depends. The VFP database can reside anywhere that is visible to the client app.
>

Rather than making the database "visible" to the client, we want the client to use ODBC/SQL/etc to make requests and receive responses. We want the bulky data handling to occur on the server.


>>- VFP Remote view defined on client
>VFP Remote view is defined in the dbc. THe dbc can live on the server or the client, but the usual place is the server.
>

Asking this to figure out the mechanic of achieving client/server with VFP server.


>>How does the client SEE the server datasource?
>The client app USEs the view in the VFP database. Or the view lives in the forms data environment. There is nothing in your app itself that points to an Access database, only the remote view in the VFP database. Only the ODBC datasource knows the location of the Access database, and the connection you defined in your dbc knows the name of your ODBC datasource. Your views only know the name of the connection and the name of the datasource, and your app only knows the name of the view.
>

So can the client (VFP and other tools) access the server database via ODBC technology in much the same way as if the data was local on the client, but without bulky data transfer such as when a SELECT SQL selects by a non-indexed field?


>>Could we use native VFP as the database on the server?
>Do you mean can a VFP app use native VFP data? Well yeah.
>

... but not just by accessing the shared directory of the data server?


>Or do you mean could you set up VFP as the ODBC datasource and use that >datasource in your VFP app? Yes, you can do this, ...
>

We realise this is not the ideal approach, but nevertheless we're looking for an interim solution. You say it can be done, but we cannot work out HOW?


>... but its not recommended. VFP isn't very efficient as an ODBC datasource,
>its not really designed to be a database server, its really optimized for
>local access. Maybe the better question is why? Especially considering your
>next comment, you don't want to do this.
>

Currently that is the format of the data, and due to legacy software on the file server, the data is harder to change than the client software. An SQL server type database must wait until the legacy software is made able to access it.


>>We're trying to minimise data transfer between the server and client.
>Parameterized local views are great for this. Figure out what data the client really needs to see, and only bring that data down the pipe. You just have to get out of the SET ORDER and SEEK mindset...

I agree about the plv's. However, particularly due to the idiosyncracies of Rushmore, and the fact that some selections are not indexed, we need to get the server to do the reading of the database.