>>>>>>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!

There is nothing wrong with it. Update is called with a where clause or not it does the update on matching records. Nothing might be updated as there is nothing to update but "update" operation result is a success. OK with some code better to see what I'm saying and might be an answer to Jim's problem:
With VFP native tables

update customer set Company = "Modified" where cust_id="ALFKI"
? _Tally && With testdata!customer would return 1

delete from customer where cust_id = "ALFKI" && from local or another user
* assume set deleted on or was packed in between

update customer set Company = "Modified" where cust_id="ALFKI" && result Success - .t.
? _Tally && affected results now 0

With SQL server consider you do the update via a stored procedure that returns @@RowCount - rows affected (like _Tally). Then you would know if none or how many updated. Yet another alternative (if applicable due to reccount of dataset you're dealing with) is to make the SQLExec() result cursor updatable, buffering the cursor with 5 and using regular tableupdate() (with getnextmodified() you could loop teh modified records).
Cetin