>>This is the way I decided to write it. Not the most elegant way but runs really fast; .04 seconds to update 200 records. I am building a string of keys. mk_ivinvt holds "AAAAA","BBBBB", etc. up to 120 keys at a time.
>>
>>My question now is: Why the heck does

IN (SELECT K_IVINVT FROM C_CHNG)

take the same 12-15 seconds as the original query.
>>
>>Where using

in (<<mk_ivinvt>>)

take only .04 seconds???? It seems they should both be the same but then, as we all know, software works in strange and mysterious ways.
>>
>
>Hi John,
>
>The IN() is somewhat similar to a join (more than one table is involved) and, as I mentioned before, a join can't be optimized with indexes on a table, which is the target for the UPDATE. The IN (), on the other hand, is a filter condition (only one table is involved) and it can be optimized with an index.
>
>Thanks,
>Aleksey.

Aleksey,
Thanks for the info. Your answer makes sense. It seems to me that there must be a simple way to do what must be a very common task.

Beer is proof that God loves man, and wants him to be happy. - Benjamin Franklin
John J. Henn