>Aleksey,
>Confusion reigns, this is from the VFP8 Help:
>
>Visual FoxPro automatically generates the SQL INSERT, UPDATE, and DELETE commands for local and remote views. When working with CursorAdapter objects, you can customize and control how Visual FoxPro generates these SQL INSERT, UPDATE, and DELETE commands.
>
>When the CursorAdapter InsertCmd, UpdateCmd, and DeleteCmd properties are empty, Visual FoxPro generates the corresponding SQL commands automatically. You must determine whether automatic generation of these commands is appropriate for the data source you are using. To generate the SQL INSERT, UPDATE, and DELETE commands automatically, you must set the following CursorAdapter-specific properties:
>
>Tables
>KeyFieldList
>UpdatableFieldList
>UpdateNameList
>....
>

Hi Simon,

I don't see anything confusing here. What exactly looks confusing to you?

>I understand how this works, but I come back to the point I asked: if portability is not an issue, what are the key reasons for using a CursorAdapter over something like a remote view or a call to a stored procedure? Where is the correct place to put one of these objects: on the form or in the Data Environment?
>

I believe the key reason is the functionality that wasn't there before.
Consider just the following two:
1) TABLEUPDATE() can call stored procedures or other custom commands instead of regular SQL-INSERT/SQL-UPDATE/SQL-DELETE commands.
2) Ability to refresh timestamp, autoincrement and other fields while TABLEUPDATE() commits changes.

Those examples have nothing to do with portability from one data source to another.

Thanks,
Aleksey.