>Jeff,
>
>> Can you move the data to the local drive and see if maybe network access is what is taking longer than you think? <
>
>Is already local. With this size tables, I always prototype locally. Even when it's a COM server on another machine it will be local to that machine.
>
>> Have you looked at using the profiler to see where your slow down is? Not know where or how you are getting to your data, I'm just guessing.
>
>Sad to say, I don't think that would help, only because the 11 hours were spent on a single REPLACE. FWIW, that replace command was passing an 8 million record table, with two RELATIONS into 4 million record tables. A similar command earlier in the job took 40 minutes. I can see 3 or even 4 hours for this one, but it was the 11 hours and the "coincidences" of it moving on when I killed the Task manager that has me confused.
>
>Thanks for the suggestions, though.
From the VFP end, do you have to have relations for your process to work? For large tables you might try manual SEEK()s. Also, other recent threads have pointed out large slowdowns if tables are ordered on an index tag.
From the platform side, I'd recommend going to NT SP5 and, most definitely, VS SP3. The consensus *seems* to be that although SP3 may not fix all memory leaks etc. it's much cleaner than the earlier version(s).
Regards. Al
"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov
Neither a despot, nor a doormat, be
Every app wants to be a database app when it grows up