I second both Dan and Mike.
The problematic part is, you won't find any book covering how Cursoradapter can be used for remote databases, you have to read up that in the VFP help.
It's good to know that you have three main options:
1. Remote Views. You need a DBC for that, and the DBC has to have a connection object defining the connection to any remote database you can connect to via ODBC.
2. SQL Passthrough: SQL...() functions, which also work with ODBC connections. (Start with SQLStringConnect, SQLExec, and SQLDisconnect.
3. Cursoradapters set up for remote access.
Cursoradapters may use ODBC driver or OLEDB provider, while the first two options depend on ODBC driver.
Remote views may be easiest to set up both in regard of defining the query visually and defining them updatable, but the view editor is limited.
SQL Passthrough is easy for readonly queries and the only option to also execute longer scripts instead of just queries, ie. SQLExec enables you to create databases, tables, stored procedures etc. via DDL (data definition language) and also enable simple to complex queries you may also design visually within a visual query editor for the remote database, eg in MS SQL Server Management Studio. What's harder with SQLExec is to make the result cursor updatable so you can write back changes to the remote database via TABLEUPDATE().
Cursoradapters don't depend on the limitations of the view editor for remote views on the one side and on the other side enable an easier set up to be updatable, than SQL Passthrough does via the Cursoradapter builder. Bernard Bout extended the builder coming with VFP.
I use a mix of SQL Passthrough and Cursoradapters.
In any way you choose, you must learn the SQL dialect of the remote database, you cannot use VFP functions in queries, for example, which makes it a less simpler task to convert native data access to client/server. Even harder is to convert USE of tables or using the DE, there is no such thing for tables of remote databases, you have to make use of sql queries and you have to change your overall thinking about data access. You don't first show all data and let users then filter, you rather ask users what they search and then only query that. Also you don't (easily) have refresh of the viewed data. If you try simialr things as SET REFRESH with your view or cursoradapter cursors, you end up with more problems than the benefit of the live view on data. Client/Server rather means using your connection sparsely for reading and saving, not for refreshing and also not for writing each single change right away. What works better this way is multi user. It scales up better to work this way and you can even set up remote connections, so the database can be in the internet or cloud.
Bye, Olaf.