I just sent you the e-mail. I also had Doug Hennig helping me on this. Apparently, the error is because of the parameterization of the WHERE clause -- WHERE CustomerID = ?crsCustomers.CustomerID. VFP does not like that when updating native tables, but it works just fine for ADO and ODBC on a SQL DB. IMO, this is bad to have a different behavior by the CA just because the backend or access method changes. I will be testing this on a DBC using ADO to see if I have the same problem. This does not bode well for migrating from a DBC to a SQL DB just by changing the DataSource, etc., when you get into SQL idiosyncracies.

>Sure, Mark, send the full repro to me: jkoziol@microsoft.com
>
>>Hell, I got it pared down to just:

>>update customers set CONTACTNAME = ?crsCustomers.CONTACTNAME
>>where CustomerID = ?crsCustomers.CustomerID

>>Besides the BreakOnError will not catch this because the TABLEUPDATE is returning FALSE so I have to use AERROR() to find out what the error was. You want the ClassLib and Form that repros this? All you have to do is run the form, make a change to the ContactName and hit the save button on the form. The error message info from AERROR is output to the screen.
>>
>>>Hey Mark,
>>>
>>>I don't see anything wrong. Have you tried setting CA.BreakOnError to .t. and then paring down the statement, clause by clause until it stops breaking?