Trying to clearly understand how to do this...
>
>With your ODBC example above, if the Access data is on one server PC and a VFP application is on a client PC, then it seems that these need to exist:

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

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

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


>- VFP application on client

Yup.

>Are more components needed?

None come to mind...

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

>Could we use native VFP as the database on the server?

Do you mean can a VFP app use native VFP data? Well yeah. 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, 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.

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