>>I worked with a person who liked to do things his way. He had to run an end of month report every month and it took 8 hours. There was lots of data from many sources. I looked at his code, modified it in our test environment, and it ran in under 90 minutes. He verified what I had suggested and the savings of time. He stated, “I will do it my way”! So the report took 8 hours to run.
>>
>Hmmm, interesting story <g> Not the case here, though, since this was my code <g> And though I like doing things my way <g>, I always want to do them the best possible way and as quick as possible. That's why I'm always open to new ideas and always try to improve even working code <g>
>
>In this particular case the delay is not explainable. I think since it was a single case, I don't yet have to worry. It this problem repeats, I would need to investigate.

Going over the network always presents concerns when doing SCAN-ENDSCANs on a table. All the data has to move over the wire to the local pc to determine if it is in the FOR condition. Depending on the network traffic (like is someone streaming a music station, etc) can severely impact performance. But the end-user doesn't care about their streaming, only your program took too long. I would recommend doing a SELECT-SQL to a local cursor and then update changes to the backend table from the local cursor.