I don't quite understand. In the example I gave you there were 3 result records for each of the the 2 date ranges. The report needs them to be opposite each other. I've sent you an email with ETM and non-ETM versions of the report so you can see what I mean.

Terry

>How do you want the result to be present? Are you sure you have only two records for one Op and route for given period (Prev and Curr)?
>
>
>>Hi again, Boris
>>
>>Just realised that when I print out the report the matching Routes between the two date periods/ranges do not line up side-byside, i.e. 2006s' results for route X next to 2005's results for route X, like they do for the ETMDATA results. They take a line each.
>>
>>As yet I don't know if this is due to the next processing I do on the cursor (which mirrors what I did for the ETMDATA). Just though I might catch you before you leave work :-) The cursor for the report comes from the code below:
>>
>>

>>Wait WINDOW "Non-ETM Data: Calculating Numbers of Trips within the Time periods ..." NOWAIT NOCLEAR
>>
>>SELECT ps.*, IIF( ps.CurrPass > 0, lnNotECurrMult, 0.00) as Mult2, ;
>> 	    IIF( ps.PrevPass > 0, lnNotEPrevMult, 0.00) as Mult1, ;
>>	    IIF( ps.CurrPass > 0, ps.CurrPass * lnNotECurrMult, 0000000.00) as Trips2, ;
>>	    IIF( ps.PrevPass > 0, ps.PrevPass * lnNotEPrevMult, 0000000.00) as Trips1 ;
>>  FROM csrNotETMPassengers ps ;
>>  ORDER BY	ps.Operator, ps.Route ;
>>  INTO CURSOR csrStep2a NOFILTER READWRITE
>>
>>

>>
>>or because of the removal of the GROUP BY clause, which IS used for the ETM data
>>
>>Any quick ideas? BTW, the lnNotECurr.PrevMult figure is an aggregate multiplier got from the ETMDATA.