>>I use another trick:
>>- in "group by" I put "eval(gr1)", "eval(gr2)", "eval(gr3)"
>>- in group headers/footers, there's "tx1+' '+eval(gr1)" etc.
>>
>>In the routine calling the report, I just set these three pairs of vars
>>(gr1 contains the field name, tx1 its description), according to the
>>user's choice of ordering. This way, by recombining the orderings, I get
>>six reports (or more, if gr1..gr3 may be chosen from a list with more
>>than three rows) with one .frx (twelve, if we consider summary or not),
>>and yet add some filtering to it (ID range, date range and such) and it
>>eliminates the need for lots of other reports. Yes, the report is bound
>>to the routine, but the routine does work like a swiss army knife.
>
>Dragan -
>
>Can I ask how you allow the users to choose the ordering and filtering (e.g. do you have a fixed list or do you base the contents of the list on some kind of a table)? It seems to me that while you have only 1 report form (good!), unless there is some way of generically getting this kind of info to the report form, you still have to create a number of custom print forms for each situation. Can you give an example?
>
>Thanks,
>
>Sylvia
>
>BTW - I know this request is long after the original thread, but this info is new to me)...

Never mind, I still remember what I did, though I didn't touch the thing ever since - it works :). The app has just two more reports, which print one document or one item history - all the other reports designed for doing any summing up were deleted long ago.

Well, I do have a small form with three dropdown lists; anything selected in the first gets disabled in the second and third, selected in second is also disabled in third and so on (oops... no "so on", unless I stretched it to four or five levels, which is overkill). Each selection bears three parameters: the expression to group by, group expression to be printed (includes some title info and the value of the group expression, plus name if the expression is a code), and the column position in the SQL statement. I generate the SQL Group By and Order By clauses, which then look like "4,2,8" or so. I keep these triplets in one array, which made it pretty extendable - once we got an user who had departments, just added a row to the array. There's also an additional modal form where the filtering can be done - date ranges etc; from it I generate the SQL Where clause. When the user exits this little form, the .prg prepares the SQL, runs the SQL and then runs the report.

The app is specific - it has one long table with all the possible production expense tracking info. Any relevant report is pulled from that table - whether it's the cost, or consumption of specific materials grouped by division, account, material or final product (or none, in the third dropdown - so there's actually a two-level version, too). I have applied it in another case (amortization and revalorization of permanent goods - i.e. buildings and equipment), where it could be grouped by account, division, calculational group and supplier.

I was pretty much forced to make it by sheer number of possible combinations, and every customer seemed to need some particular combinations that the others didn't... when it came to five reports with roughly the same columns and more to come, I put it all together.

So this was the couple of cases where I could have come up with one report which does it all; maybe in some other cases this would be applicable too, and maybe worth writing a generic report like this. The array could be retrieved from a table, so the parameters could actually be stored into one; still, there was no need for that, because having it all in a .prg ran just fine, and didn't have to maintaion one more table. The number of fields to group by was limited anyway - some groupings simply wouldn't make sense, so I took only those which did.

Your situation may be different, and taking the trouble to do this may also save you trouble of making dozens of other reports which may be hell to maintain. The limitation, as I see it at the moment, is that you should have to run an SQL to create a cursor which could be ordered (or indexed) in any desired order, and have all the variant of the report run off the same cursor. This cursor may be built in many ways, and from many tables (here's room to make it general), but it should contain the fields that the report needs... though, you can replace lots of fields in the report with Eval(SomeExpr) and thus make just a shell of a report... actually, you may go as far as you like :)