Thank you Mike,

The current transaction table has a structure something like this (much simplified. There many dozen fields)

CREATE TABLE XXX (ntra N(7,0), ccodemp C(6), ;                        && transaction number, employee code
                  nsalreg N(9,2),nsalsob N(9,2),nsalbru N(9,2), etc ; && regular, overtime and total pay. Summary fields.
                  nhr N(6,2),nhsn N(6,2), etc. ;                      && Regular hours, O/T hours rate 1.  Time fields.
                  nComision N(9,2),nBono N(9,2), etc)                 && comission and bonus ($)  Primary Money fields

A typical SELECT statement in preparation for a report may choose a portion of that table, augmenting it with additional fields or perhaps calculate the sum of several of the numeric fields in table other than ntra. The finished cursor will have one record per report detail section.

Thanks for the help.


>Could you give a small sample from your tables and data?
>
>>We have some transaction tables that are not properly normalized, with transaction records containing some detail fields right in it. I know this is against good practice but 13 years ago it seemed like a good trade-off to gain speed, plus we had few detail types back then. With this structure it is easy to derive cursors that have all fields of interest in one record and reports can show all fields in one line very naturally and speedily.
>>
>>If we fully normalize those tables and the transaction detail fields are stored in several records of a child table how do I print reports with all those fields in one line? Sounds like a cross-tab problem, but I am not very impressed with the speed of crosstab. It is also not as intuitive to develop. What is the best way to approach this problem? By now we are having too many new detail types and the previous method is getting unwieldy.
>>
>>Is this a place where the new VFP9 capability of "Subqueries in a SELECT List" help? Actually I don't know how one would use "Subqueries in a SELECT List" at all.
>>
>>Thank you very much.
>>
>>Alex