>>>>>>How do I determine, in my PRG code, that a record has been updated? That is, without searching for the Field2 = 'XYZ'.
>>>>>>
>>>>>
>>>>> Are you looking for absolute verification that indeed, the row was changed, and specifically, that the column was changed from 'ABC' to 'XYZ'?
>>>>
>>>>Yes.
>>>
>>>As Naomi said, you can use the OUTPUT clause....OUTPUT actually gives you visibility into the DELETED and INSERTED tables that are otherwise private to a trigger. They allow you to see the "before" and "after" values for the table you're updating.
>>>
>>>Microsoft basically created the OUTPUT to give people the "low hanging fruit" of some of the benefits of a trigger, without needing to write a full trigger. That's not to disparage it - it's a nice feature.
>>>
>>>My 2 cents, if you need an audit trail of who changed what and when....you might want to look at either update triggers or change data capture. Triggers are great, though you do have to write a bit of code (which shouldn't scare someone). Change Data Capture "usually" requires less code - though there are some nuances to be aware of.....it's good but not perfect.
>>>
>>>After years, my 2 cents is that triggers are the best way to go, to build a custom log of who changed what and when.
>>
>>Thank you for your detailed message. This job, updating multiple records based on some value, was just a one-time thing. I did it using the extra parameter in the SQLEXEC() function of VFP. But I will save this message for when I need to do it again.
>
>Now that it's settled I have a question:
>Did you actually have a case where a SQL Update failed to update the columns in question without throwing an error?
>That will be a first for me. I've had lots of errors thrown on Updates but never saw an Update fail without throwing an error.

I never said there was a problem/error with the SQL Update. I was running the SQL Update against many records with a WHERE clause. I simply wanted to know how many were updated (since some records didn't match the WHERE clause).