>>>>>I do an UPDATE command using SQLEXEC.
>>>>>I *know* that the conditions specified (WHERE clause) cannot be matching, yet I seem to be getting a "1" back (updating only 1 record each call). The record is *NOT* being updated, which is what I want, but the return code is telling me to update a list that is shown to the user to indicate records updated.
>>>>>
>>>>>The Help says:
>>>>>"Numeric data type.
>>>>>SQLEXEC( ) returns the number of result sets if there is more than one. SQLEXEC( ) returns 0 if it is still executing and returns 1 when it has finished executing. SQLEXEC( ) returns –1 if a connection level error occurs.
>>>>>
>>>>>SO what does it return after an UPDATE command? I had guessed that it would return the number of records updated but that is obviously wrong.
>>>>>
>>>>>Thanks
>>>>>Jim
>>>>
>>>>Jim,
>>>>Take that "1" as command successfully finished executing w/o any errors.
>>>>Update might finish successfully yet no records are updated (ie: no match to where clause). Just before update try a select with the same where to see if that's the reason.
>>>
>>>Cetin (and Fabio),
>>>
>>>That apparently is what I have to do... but I want(ed) to avoid an extra SELECT because this is run inside a MSCOMMCTL where timing is critical.
>>>I had already specified that the SQLs (using VFP ODBC by the way) should be synchronous (and batchmode for insurance) and I had also limited my updates to single records to both make it fastest possible and provide possibility of clear return code.
>>>
>>>With this limitation I wonder why so many people say SPT is the best way to do this stuff?
>>>
>>>Anyway, thanks both of you
>>>Jim
>>>
>>>>Cetin
>>
>>Jim,
>>There is a misunderstanding. I said use select only to see if where has any matches (you said no records were updated).
>>Second single record updates are slower than batch multiple updates.
>
>Not really a misunderstanding...
>I update a record and it does update. BUT if the user submits the *same* record again, then I expect the UPDATE to not update because the WHERE clause. This works - the second UPDATE does not cause any change to the table.
>However, I want to tell the user which records got updated (so by implication which did not) by putting key info about updated records into a List. Because the SQLEXEC returns 1 regardless, I post the record as having been updated (again). I understand that the UPDATE executed "properly" but now I have no way of knowing HOW MANY records were updated (and how many were not by deduction).
>
>I understand that a single record update is slower than updating multiple records but the most records I can get in a single tramsmission is 2 anyways and I anticipated that getting a good return code was an excellent tradeoff. Now I have to look at it again.
>
>Thanks again
>>Cetin

I have a similar scenario,

If you are in a multiuser environment, and a user is currently editing a record just before a second user delete it. When the first user will update it will still return .T. when the update occur!