>I have used the coverage profiler and found that the slowest line of code is when this view is requeried.
>
>

>SELECT Ordprod.orderid, Ordsize.orderprodid,;
>  SUM(Ordsize.ordered) AS totordered,;
>  SUM(Ordsize.allocated) AS totallocated,;
>  SUM(Ordsize.shipped) AS totshipped, Ordhead.sbo AS specialord;
> FROM ;
>     Ordsize ;
>    INNER JOIN ordprod ;
>   ON  Ordprod.orderprodid = Ordsize.orderprodid ;
>    INNER JOIN ordhead ;
>   ON  Ordprod.orderid = Ordhead.orderid;
> GROUP BY Ordsize.orderprodid, Ordprod.orderid, Ordhead.sbo;
> ORDER BY Ordsize.orderprodid
>

>
>This view returns about 20,000 records
>
>ordsize table has 194,000 records
>ordprod table has 21,000 records
>ordhead table has 3600 records
>indexes exist for all fields, i.e. orderprodid,orderid in all tables
>
>This query takes about 2-3 seconds on my local machine, but can take minutes over the network at the customer site.
>
>Any ideas on how to speed this up?

I would advise you not to ever test a query's performance on your local machine. You can get it operational and check Rushmore Optimization there, but that's all. Once it's working, performance test it on the network and then tweak it on the network.

The bandwidth from the CPU to the hard drive is huge compared to the average 100Mbit LAN card. It's like being comparing a fire hydrant to your customer's garden hose.

New SATA drives are 3 Billion bits per second versus LAN at 100 Million bits per second. That's 30 times faster if the network isn't busy.

Do you have to pull all the data? Can you not filter things down with date ranges in the where clause?