>>>Hi all ...
>>>
>>>The section of code below is one which I changed recently to use Update instead of Replace commands to avoid an issue arising with certain clients.
>>>Now, however, I am experiencing a strange problem with the update statement under certain circumstances.
>>>
>>>UPDATE Loop SET;
>>> dRejDate = Iif(WORKORDR.lReject And Empty(dRejDate),WORKORDR.dWrDate,dRejDate),;
>>> lRejVer = .F.,;
>>> lRejent = WORKORDR.lReject,;
>>> lCalEnter = .T.,;
>>> lCalVerify = WORKORDR.lReject,;
>>> nWorkID = Iif(WORKORDR.lReject,0,nWorkID);
>>>WHERE Loop.nLoopID = workordr.nEquipID
>>>
>>>I am updating a single record in our "Loop" table identified by the unique reference Workordr.nEquipID. In most cases, this update proceeds correctly, and the record pointer remains on the Loop record in question. In some instances, however, the update command causes the record pointer to move to the last record in the table. I have verified that an update does occur as _TALLY=1 after the update. If we attempt to run the same update command again, after this type of adverse action, the same problem arises. For this reason, I feel that the issue must be with some global variable or SET parameter, but I haven't been able to track it down. Does anyone know of what can cause the update to act in such a way.
>>
>>Mark,
>>That's normal behavior. You shouldn't expect your pointer to be preserved at all times using Update-SQL, TAbleupdate() etc.
>>You might try replace instead since you're using one-to-one.
>>Cetin
>
>Are you sure that this is normal behaviour ?? ... the frustrating thing is that in some cases (ie where the code runs OK), the record pointer is NOT moved by the same section of code ... if it was happening all of the time, I could rewrite with this in mind.

If it's not it should be, so yes I'm sure. I didn't say at all times however. What's wrong with simple replace? Update SQL doesn't support currentof clause as SQL server does.
Cetin