Walter,
I'm glad you posted this because I had intended to pursue this a bit more but wanted to pass on the reference first. Then I forgot (age!).

It seems to me that, through all the time since I've been on UT, only 2 such problems have arisen - the referenced thread (by Gar Lipow) and Dan's. And Mr. Lipow's came as an answer that addressed the "problem".

Both found CPU had topped out, and I think most would agree that this is a strange situation when it is I/O that is the main objective of this processing. And given the power of modern processors, the actual processing of 25,000 or even substantially more records should happen in the blink of an eye.

The limited number of these reports lead me to conclude that there is something else at work here. Sadly, I have no real idea what it might be.

The only practical thing that I can suggest is to take the processing that has the known characteristics and run it several times, starting with the bare minimum of running processes (in the whole system) and adding others in one-by-one, observing similarly during each. Of course if one of the 'bare minimum' processes is involved in the problem, it will not be found.

I suppose that another option is to take the whole application and try it somewhere else, maybe on a different OS or version of the OS and certainly on a different network using different network hardware. Thinking back to my mainframe days, flat-CPU (100%) for extended periods was almost always related to hardware error processing. I think that Win has had more and more error processing/correction functionality added to it over the years, and possibly hardware too, so this feels like it could be the real root of the problem too.

Cheers

SNIP
>>Actually, we've found that in most cases because FoxPro is such a CPU hog, we were CPU bound not I/O bound. We purchased a box with monster drives and found we were pegging the CPU, so the disk activity was not really the problem.
>
>Pulling 25.000 records from the network should not be due to running out of CPU resources. Like Jim says, There should some I/O problem causing the slow response. You've tried the SEEK, COPY WHILE .. FOR .. method which rules out rushmore optimization problems. The problem should be network or other I/O problems. Did you try this on your local machine or on a network station ?
>
>Walter,