John,

This fits in the category of a real wild guess, but you sound like you'd take *anything* at the moment, so here goes. . .

This sounds a lot to me like there are *NO* indexes, thus the slowww performance *and* the large TEMP file creations. Yes, I know you have indexes!
BUT. . . there have been reports of index files *NOT* opening (ie the PRODUCTION .CDX fails to open) when a .DBF is opened *WITHOUT* reporting any error!!! This in a NT environment, and I *don't* know if it is documented in any way by MS.
At least one of the reporting persons advised that he seemed to have circumvented the problem by upping the maximum number of files allowable. I (sadly) don't know what was adjusted to to this, only that it was done and the incidence of trouble seemed to disappear.

So I would look at your User machines (or their NT settings, if such things exist) to see what the differences might be from your "test" machine as far as maximum files permissible is concerned.

Wishing you good luck,

Jim N

>>>>>The users machines are creating the temp files on their local drives c:\windows\temp. What doesn't make any since to me (other than I don't know what the heck is going on here), is why the temp file is so big...It is acting like a badly constructed query, but I know this query works fine because it completes on my development machine in less than a second. Can you think of any other suggestions? Thanks.
>>>>>
>>>>John,
>>>>
>>>>Are you both running against the same data? Is there a diffference between the ST DELETED or SET EXACT settings on the machines? Is the hardware, CPU and RAM, the same? What else is running on the production machines when the fox app does its query? The production machines may be hitting the windows swap file alot.
>>>
>>>Hi Jim,
>>>
>>>Yes, the database is the same for both. Set settings are SET DELETED ON and SET EXACT OFF in the main.prg. Actually the RAM is more and the HD space is larger on the user's machines than on my development machine. I've tried only running the fox app with nothing else on the users machine with the same results.
>>>
>>>I did upgrade my development machine to vfp5.0a about a month ago.
>>>
>>John,
>>
>>I'm at a loss here. None of the things I can think of are present in your environment. I can only tell you that it is something that is different between your machine and the production machines.
>
>Jim,
>
>Would this have anything to do with my upgrade on the development machine to VFP5.0a. Do I need to create another netsetup for the users to reinstall on their local machines? Would this change the older .dll's with VFP5.0a files or are is the runtime stuff the same with VFP5.0 and 5.0a.
>
>Thanks John.