Hi John

How's la belle province?

You will find switching to using meaningless / factless / surrogate integer keys will give you better performance everywhere. Assume your cStatus field is 10 bytes. The size of the index tag information will be larger and take longer to transmit than integer keys. You wouldn't need to use ==. Is there a chance that cStatus will have some number of spaces preceding the word "REJECTED" in some record? Are there records that have "REJECTED" followed by something else in the field? Not when you use a lookup table.
Additionally you'd be doing far less UPPER(ALLTRIM()) which is just a way to get around the possibility that someone didn't type in " REJECTED". Specify the fields you want to work with. It will further reduce the time to return the result set.

If ROLLS had an integer iRol_LupFK which was matched with a lookup table Lup_PK...

liStatus=LOOKUP(LookupsTable.Lup_PK,"REJECTED",LookupsTable.Lup_PK,"DescriptionTagName")
SELECT specific_fields FROM ROLLS WHERE iRol_StatusLupFK = m.liStatus ORDER BY nRoll INTO CURSOR tmpRejected

When joining tables together...

SELECT * FROM ROLLS WHERE UPPER(ALLTRIM(cSTATUS))=="ACCEPTED" AND ROLLS.cWorkOrderID == SALEORDER_ITEMS.cWorkOrderNo ORDER BY nRoll INTO CURSOR tmpAccepted

becomes

liStatus=LOOKUP(LookupsTable.Lup_PK,"ACCEPTED",LookupsTable.Lup_PK,"DescriptionTagName")
SELECT specific_fields!!! FROM ROLLS WHERE iRol_StatusLupFK = m.liStatus INNER JOIN SALEORDER_ITEMS ON iRol_PK = iSoi_RolFK ORDER BY nRoll INTO CURSOR tmpAccepted

>
>SELECT nWeight_Roll, ;
>SUM(nWeight_Roll) AS nWeight_Skid, ;
>SUM(nWeight_Roll_Metric) AS nWeight_Skid_Metric, ;
>SUM(nUPerRoll) AS nUnits_Skid, ;
>SUM(nFootage_Roll) AS nFootage_Skid, ;
>cSkidID ;
>FROM ROLLS ;
>WHERE ROLLS.cWorkOrderID = SALEORDER_ITEMS.cWorkOrderNo ;
>GROUP BY 6 ;
>ORDER BY 6 ;
>INTO CURSOR tmpSkid

You're going to have trouble with that query when you switch to VFP 8. Standard SQL doesn't permit this kind of query. You'd find out about that if you had to use SQL Server. VFP does support such queries, at least until VFP 8. There is a way to keep doing the non-standard SQL way in VFP 8, but I suggest you start getting out of the habit now. <g>

nWeight_Roll would have to be dropped from this query and determined in a second query. If nWeight_Roll is guaranteed to be the same in every ROLL record, you could use MAX(nWeight_Roll) to deal with it. However, I'll bet it does change throughout the set of ROLL records. That's why it shouldn't be in this query.

Are you sure you want to do this summing for every Roll and SaleOrder combination?

SELECT SUM(nWeight_Roll) AS nWeight_Skid, ;
SUM(nWeight_Roll_Metric) AS nWeight_Skid_Metric, ;
SUM(nUPerRoll) AS nUnits_Skid, ;
SUM(nFootage_Roll) AS nFootage_Skid, ;
cSkidID ;
FROM ROLLS ;
INNER JOIN SALEORDER_ITEMS ON iRol_PK = iSoi_RolFK ;
GROUP BY cSkid_ID ;
ORDER BY c_Skid_ID ;
INTO CURSOR tmpSkid

I hope you can try some of what I'm suggesting.