>Maybe there is something I missed for a long time. My understanding was always that you could issue any valid VFP SQL statement against the view, local or remote, and it would work. VFP handled the update against the database. I'm sure if there was VFP specific syntax in the WHERE clause it wouldn't work, but I didn't do that.
>

Ultimately remote views are just wrappers for SPT. If the syntax works, the view works. There are enough syntactic differences between the VFP and TSQL versions of SQL that it is easy to blow it up. Example: you can do a view of view in VFP. SQL hates that. I have a whole list of them someplace as I was doing so many conversions of VFE projects ( where I had taught everyone to always use remote views and never code against tables ) that I wrote a program to analyze views designed to work against DBCs and find those things that weren't going to work against SQL. That was all it took, thanks to Mike and Toni's brilliant design of the framework itself, which really loved SQL Server. We always taught keeping views in their own DBC, so once you had created a views DBC tailored for SQL you actually could run the same app against either VFP or SQL data, but the views DBC had to be crafted for the backend.

A big difference, in practice though, was that it was easier to use GUIDs for pks since you could generate them for new records ( and hence populate fks in children ) on the front end. That was fine (even before sequential uids were introduced in SQL) for smaller apps where index insert speed and table size wasn't a huge deal. But most existing SQL databases would employ identity keys, so we had some magic in our datalayer to handle syncing the newly generated parent pks with the fks in the new children when there was a big save of a new parent and multiple child table records at one time. So a lot of times the "upsizing" would include rethinking pk / fks

In my big project rescue job at Dow Jones this was a very big deal, as the tables were quite large and the existing app was doing some stuff that was ... creative - but stupid :-)