>When you say "nada" do you mean as far as pure VFP COM components?. What if I had SQL Server on the same box and transfered this processing to a stored procedure... or did minimal processing with the VFP COM component and instead used a C# routine to crunch the data. Would either of these play better as far as not hogging the CPU?

There are two issues here on one of which I can offer no advice. The first is actual CPU load in VFP which is not something you can change. If VFP hogs the CPU on a single command (SELECT or REPORT) you're stuck with that behavior. No way around it really. Offloading to SQL Server should help here as VFP just sits idly waiting for a remote SQL command to process. However, fi the SQL Server is on the same box you may still have issues with CPU loading although SQL Server is configurable of how much CPU it can hog...

The other issue is that of VFP going to 100% calling another component as you mentioned. I've not seen this, but I haven't done as much COM stuff recently... I would think that when you call an out of process compoinent that VFP would just wait (with a few internal cycles for checking for completion of the COM call) In fact I just tested that by calling a Web Connection server from VFP that basically waits 20 several seconds and both apps sit at 0 CPU usage. If I go in and call a long method that runs 20 seconds of processing I get 0-5% on the waiting VFP process and 80-100% on the running code... which is as I would expect.

Ultimately the solution will be to offload either to SQL Server or to another box doing the VFP processing...





>
>>This is one huge problem with VFP with long running requests. Remember I think we had this discuession last year (or two ago) at a Web Conneciton training conference
>
>I can barely recall what happened last week. :-)