Thanks all

Here is a cut n paste summation of the views expressed so far


1. allows us to completely abstract the backend. If one does the proper planning, you could theorhetically go from a dbf to SQL Server/Sybase/Orcale ODBC to ActiveX Data Objects to XML and back having only to change one or two lines of code.
This is a big issue for folks who their data in lots of different data engines: dBase, SQL Server, Oracle, etc. Also, the user can have multiple databases (eg. databases for company 1 and company 2 or last year and this year). Being able to change between engines and data locations with just a tweak is a huge benefit..

2. Not just being tied to ODBC is a plus, since ODBC is essentially a "mature" (read not going to be updated any more) technology as far as MS is concerned. What if you need to retrieve data when you're not directly connected to the data source, as ODBC requires? With a CursorAdapter, you have the freedom to work against the OLE DB provider instead of the ODBC driver, if you want.

3. You can't access stored procedures through a view. This can be a huge deal for some people. Many DBAs prevent direct access to tables, so the only way you can get at the data is through stored procedures.

4. Remote views live in a DBC, so that one more set of files you have to maintain and install on the client's system. DBCs have been known to get corrupted.

5. Since a remote view's SQL SELECT statement is pre-defined, you can't change it on the fly. Although this is fine for a typical data entry form, it can be an issue for queries and reports. You may have to create several views from the same set of data, each varying in the fields selected, structure of the WHERE clause, and so forth.

6. When you use TABLEUPDATE() to write changes in the view to the backend database, you have little ability (other than by setting a few properties) to control how VFP does the update.

7. When you open a view, VFP attempts to lock the view's records in the DBC, even if it's only briefly. This can cause contention in busy applications where several users might try to open a form at the same time. Although there are workarounds (copying the DBC to the local workstation and using that one or, in VFP7 and later, using SET REPROCESS SYSTEM to increase the timeout for lock contention), it's something you need to plan for.


8 The connection information used for a remote view is hard-coded in plain text in the DBC. That means that a hacker can easily discover the keys to your backend kingdom (such as the user name and password) using nothing more complicated than Notepad to open the DBC. This is less of an issue now that you can specify the connection string in the USE command (although you can't do that for a remote view in the DataEnvironment of a form or report).


9., If you have any VARCHAR fields, a RV will send those values to the server RPADded with spaces. The server will not trim them off. With the CA, you can have the CA send trimmed values to the server


10. It is not possible to just create a cursor and make it updatable (which would be faster with larger tables) like a local view (slow creation with larger tables). A CA can because no SQL SELECT has to be used to create the initial cursor structure. The performance of data handling in both directions is faster. Greater simplicity for new Visual FoxPro developers.

----------------------------------------------------------------------------------------


I have been won over to the idea that CA are the future and will use them.
However a couple of issues still exist for me.

4. Remote views live in a DBC, so that one more set of files you have to maintain and install on the client's system. DBCs have been known to get corrupted.

At present I find it quite handy to be able to look at my data by using the DBC. It would be nice if there was a way of quickly seeing what my various various CA return as data without opening forms or running prgs. (maybe there is this is all new to me)


10. It is not possible to just create a cursor and make it updatable (which would be faster with larger tables) like a local view (slow creation with larger tables). A CA can because no SQL SELECT has to be used to create the initial cursor structure. The performance of data handling in both directions is faster. Greater simplicity for new Visual FoxPro developers.


I have not yet found them to be more simple than opening a view and setting a few properties, however that may just be because of my ignorance:)