>I haven't solved the actual problem, but I do have a work around that was successful under Win98.
>
>First I got rid of the SCAN..ENDSCAN in favor of FOR..ENDFOR, but that didn't help in and of itself. Still bombed on the same exact line. Haven't had time (mad conversion now) to analyze the code and explicitly release every object rather than letting them go out of scope.
>
>So, in the first line after the SCAN I put:
>
>FLUSH
>WAIT WINDOW '' TIMEOUT .5
>
>This worked, although it consumed way to much time to be a viable solution. Then I tried:
>
>FLUSH
>WAIT WINDOW '' TIMEOUT .1
>
>Did not work. Bombed on same line of code. Then I tried:
>
>FLUSH
>WAIT WINDOW '' TIMEOUT .25
>
>Did not work. Then I though perhaps it needs to be .5 but not for every iteration.
>
>IF lnCounter % 50 = 0
> FLUSH
> WAIT WINDOW '' TIMEOUT .5
>ENDIF
>
>This did work, and with an acceptable minimum processing time hit. So I tried:
>
>IF lnCounter % 100 = 0
> FLUSH
> WAIT WINDOW '' TIMEOUT .5
>ENDIF
>
>This also worked. The performance is acceptable "for now". I obviously need to get totally "type A" with my object variables. I don't know if this solution will work for a 25,000 member company yet, but as a work around it is encouraging.
>
>Thanks for all your help and PLEASE let me know if you have any more ideas.
>
>
>
>>>>I'll give these two a try. Thanks again. Any other/further suggestions are greatly appreciated.
>>
>>Christian,
>>
>>It may not be related at all, but when creating multiple selects in a loop, it might be wise to clean them up afterwards with a USE IN selectalias before moving to the next one, or if your selects are causing a table with disk presence, to close and delete the file before doing the next one.
>>
>>If you do get it solved, please report back so everyone will know what the problem was.

Christian,

From the mix of machines you're testing on it's unlikely the problem is anything machine-specific. However, is there anything else in common amongst the failing machines? Any 3rd party software installed on all of them? For example, you haven't specified what the network environment is (if any). If it is Novell and you're using Novell's Client32, there are known issues that cause reliability problems similar to what you're experiencing.

Is the .EXE on a local drive in each case, or is it on a server?

Again, if networking is in play, there could be infrastructure problems. I once traced flakiness in an accounting app (not VFP) to a bad 10BASE-T hub.

One general point to bear in mind is, ever since FPD2.0, Fox products have pushed the performance envelope and are well-known to stress computers on which it runs. If there is any weak point in each system, VFP'll find it.

Good luck.