Bill,

I couldn't resist the suggestions to test this.

SCAN FOR (Index on field) 1.047 sec
SEEK + DO WHILE (Table in order of field) 40.753 seconds

SCAN FOR (Table has no indexes) 1.769 seconds
DO WHILE !EOF() (Table had no indexes, couldn't seek) 182.754 seconds
(Almost got bored and killed it!)

Does this help with your decision?

I've taken over some old apps which "evolved" and have worked on replacing some junk with more efficient coding, so answering this type of question has become important for me too. Now I reach for the best commands more often!


>I have been given the task of optimizing the performance of a block of code (too large to be copied here). Currently, the code contains a mix of SCAN..ENDSCAN loops and DO WHILE..ENDDO loops. Some of the WHILE clauses are not Rushmore-optimized, so normally my first step would be to replace these with optimized statements. In some cases, however, this may not be possible.
>
>While I'm at it, I was going to replace the DO WHILE..ENDDO loops with SCAN..ENDSCAN. However, someone mentioned to me that when using non-optimized statements, a DO WHILE..ENDDO can actually give better performance than a SCAN..ENDSCAN. Is this true? I've always used SCAN..ENDSCAN, but some of the legacy code I'm looking at uses DO WHILE..ENDDO.
>
>Bill