>>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 :)
>
>Dragan -
>
>Thanks for the good info! As I was playing around with this today, I decided I'd need something like what you're doing for the WHERE. I have a query by form which I hope to use for this part. I haven't figure out how to do the Order by part yet, but in another class I use for a grid, I added a method to parse the table and field names from the SQL statement, so that might be an option.

I guess a mover listbox would be the solution now - just say the top three will be used.

>
>One followup question...I'm not sure I understand '...replace lots of fields in the report with Eval(someexpr)'. Do you mean by opening the .frx as a table?

That's one way, but it's not necessary, just enter Eval(expr) in field contents. The only trouble is that you won't be able to preview this report in the report designer, unless you set up some way to open the report designer from within the routine which runs the report:

< set variables and call selection form >
< run the sql here >

if IAmDeveloping
modify report universal
endif
report form universal .... < options >

Then you can try it out in the designer, since all the variables are set.