Not withstanding the kicking of Oracle's butt out of the park, when I think of the ease of use and the astounding things that VFP could do if it were overhauled to take advantage of the newer chip technology, it makes me sick to have MS abandon it. Whomever made that decision should have HIS butt kicked out of the park as well. From the beginning MS didn't do too much promote it. My suspicion is that all they wanted when they bought it was Rushmore, but then they found that we followed it to MS too and they kind of had to carry us for a while.

I'm going to keep XP Pro on one of my systems along with VFP and continue to use it for my personal programming. But, I'm just b_i_t_c_h_i_n_g, so I'll shut up and go away.

>Stored procedure is a preferable place for data-processing code, i.e. it's always faster regardless to number of cores.
>
>>You folks are more knowledgeable than me so this idea might be out it left field, but there might be a pretty good gain in performance if the code that might cause a slow down is located in a stored procedure where SQL Server could take advantage of its ability to use the dual cores.
>>
>>>>>>I wasn't concerned with speed that much - just wanted to know whether the load would be spread.
>>>>>
>>>>>Yupp it should. But make sure the "load" mostly taxes the cpu, or you can have contention on already bottlenecked parts: 2 processes querying a table via phone line won't help<g>. In the very worst case you might actually slow down compared to processing singlethreaded if you tip caches already running near capacity over into thrashing. Happened on relatively memory starved machines on disk intensive routines - but is the exception and not the rule. I am sure both of you can visualize similar scenarios, even if I don't get into detail here.
>>>>
>>>>Sure, we're talking about processor load only, of course, since everything else is pretty much shared. I had in mind the typical scenario with VFP web apps, where you'd offload the creation of lengthy reports to a queued exe, so the main app running the web server wouldn't take too long to respond. I assume these two would naturally go to different cores (or should be tweaked to do so if they don't by themselves).
>>>>
>>>>But as you say, we can have various scenarios here, including the fight between the twins.
>>>
>>>All in all such approaches work great as long as you find ways not to bother with managing them - but which is typical case shown by poolmanager et al. Best are the fire and forget-scenarios like your report, but recently I have been very lucky with pre/selforganizing parallell tasks via task/semaphore table. Much better than trying to control the different processes - typically I have a minimal prg checking the task table and OLE-automate the intensive tasks. COM is great as long as you can stay on a few machines without installation/config troubles.
>>>
>>>>Seems to be one of those things where the automatic settings are too good to tweak, i.e. the time wasted on tweaking and testing never materializes in a serious performance gain.
>>>
>>>Well said.
>>>
>>>regards
>>>
>>>thomas