I'm not meaning UPDATE sintax error, I'm writing about Update Conflicts that's not the same, in the same way, Update Conflict isn't a error, ist's a update Conflict (if we call Aerror() is just a coincidence), why my PKField doesn't exist where it should be?, maybe another user delete it, so?, we have an Update Conflic, not an error.
With Views you can Catch Update Conflict and VFP programmers don't care if you are using Oracle or SQLServer, if I told to my DBAs hey guys! go on and program Stored Procedures to handle my update conflicts they could ask: WHY?, We didn't do it before with you!! I'll have to say: Opppss, because now I'm using CursorAdapter??? Or are you telling me that before CursorAdapters you didn't use Remote Views only SPT+SPs and that's the way I should deal with remote data using SQL commands?
Ok, let's say I have to code Stored Procedures, how many do I have to? 1, 2 50? taking care of any different situation?... That's why I told that the workaround is an "only-few-servers-Workaround" because it's not a solution to program SPs to every action or system, I didn't do it before, why should I do now?

>If you send an UPDATE SQL that looks like:

UPDATE MyTable Set Field1 = 'somevalue' where PKField = 99392

>The SQL syntax is 100% correct as long as there is a MyTable, Field1 and it accepts the right data submitted to it, and PKField exists. However, if there is no record where PKField = 99392, no records get updated. This is NOT an error just because you have no matching records. So TABLEUPDATE() will indeed return TRUE. To expect anything different is not realistic when dealing with remote data using SQL commands.

>If the DB is SQL Server, I believe you have to issue a subsequent SQL to query the @@ROWCOUNT to see how many rows got updated or deleted. For Oracle, you have to use Stored Procs to do the UPDATE/DELETE commands for you in order to get a row count returned.

>>I would do it too, but it doesn't work, TableUpdate() always return .T. in any update error. I test it by myself too... Here's Focus Magazine say's about it...
>>
>>"As with the native CursorAdapter, most errors are trappable in the "traditional" way ? test the return value of TableUpdate and, in case of failure, use AError to determine the cause. Unfortunately, the detection of an update conflict is also a problem for the ODBC type CursorAdapter."