Sergey,
Thanks for looking that up. The k_seqno keys are unique autoinc keys in bsmemo. So I would assume that it would only need to lock the 3 records in bsmemo where the keys matched the 3 recs in c_memo. Am I correct or do I have it wrong?

>Hi John,
>
>See Re: Why this DELETE is so slow? Message #989423 for explanation.
>
>>The folowing two table updates where tested with the bsmemo table open at another PC but with no locks.
>>
>>The c_memo and bsmemo tables have identical structures of:
>>k_seqno i(4), k_memo i(4), textln c(65)
>>and are indexed on k_seqno and k_memo.
>>(Note that k_memo is not used in the updates.)
>>
>>c_memo has 3 records, bsmemo has 9,000 records.
>>
>>I tried several ways with the SQL Update and nothing helped. It appears that the SQL Update is not using the index at all. Using the Old Scan/Replace takes .013 seconds. The SQL Update takes 16 seconds.
>>TIA, John.
>>
>>

*
>>* This Scan/Replace takes .013 seconds
>>* ---------------------------------
>>select 0
>>use bsmemo order k_seqno
>>select 0
>>use jmemo alias c_memo exclusive
>>*
>>msec = seconds()
>>*
>>select c_memo
>>scan
>>  select bsmemo
>>  if seek(c_memo.k_seqno)
>>    replace textln with c_memo.textln
>>  endif
>>endscan
>>*
>>? seconds() - msec
>>*
>>*
>>* This SQL Update takes 16 seconds
>>* ---------------------------------
>>msec = seconds()
>>*
>>update bsmemo set ;
>>textln = c_memo.textln ;
>>from c_memo ;
>>where c_memo.k_seqno = bsmemo.k_seqno ;
>>and c_memo.updtflag = 'U'
>>*
>>? seconds() - msec