SELECT Ordprod.orderid, Ordsize.orderprodid,;
  Count(Ordsize.ordered) AS cntordered,;
  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
But it could need to read the nearly the full ordSize table as aggregates are called.

>
>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.

IF the client machine is of similar capabilities, it should be able to finish the query locally in less than 5 seconds. Assuming a 100MB network and moderately sized fields should you should be able tor read all needed tables and fields into local cursors in less than a minute - this should be less than 10 MB of pure data, so neither the network nor disk should in theory be botlenecked. Compare the times needed to copy 10MB across the wire or navigate the unknown table size on disk (the fields have to be read in recsized lumps). And try that approach selecting into local cursors first, timing each select and the following index<g>. Local indexing on 200K records is fast. This assumes that somehow one of the steps (group, aggregate, order) still reads across the network instead of local intermediate table - seems improbable, but might be worth making sure of.

But before that - make SURE that cursors are created LOCALLY at that client and not somehow are redirected to a network drive <bg>. That might be the most simple explanation...

HTH

thomas