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

Some people think if you USE a table it's all transferred, but that's wrong. If the FOR condition is Rushmore optimized, the data is also not transferred.

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