The problem you have is that dynamic report generation is not a trivial action. Reports, like forms, have fields that you can place dynamically - but in essence you have to build a "wizard" in your VBA code to do this.
Logically speaking, this is, indeed, an approachable task. Practially speaking, you need to be REALLY REALLY good in VBA. So before you decide you really want this, ask yourself... {Dirty Harry imitation} .... "Do I feel lucky today." Well, do you?????
In overview, your problem is TWO-fold. First, you need to consider the query that will drive the report. Second you need to consider the report itself.
If you have a list of fields that can appear on a report and use the checkbox method of selecting, that would work, though you might wish to have a second & third checkbox to note whether the information will be the basis of a sort or group operation. Eventually you could build a query string that consists of your SELECT clause and the list of fields, the FROM clause and table name (including a JOIN if that is required), and the WHERE clause with lists of criteria (if any). Plus any ORDER BY and GROUP BY clauses as determined from your other check boxes. Store the query so that you can use it as a recordsource.
So now you have the query. What next?
Well, you need to create a blank report, set up some sizing parameters, and take a shot at placement. Where there is a GROUP BY clause, you have the candidates for report headers for each grouped field. Sorting doesn't automagically imply a header, but grouping does. Things that are the basis of a GROUP BY go in either/both the header and/or footer for that group. Things that aren't associated with the GROUP BY fields go in the detail section. You need to consider for each item whether you will label it or merely present it, and you need to allow space for everything.
OK, once you have built this report, you need to save it so you can open it and print it.
Now, next trick: You have users creating ad-hoc reports all over the place. You will have a TON of obsolete objects that need to be cleaned up. You can take the approach that you never save a dynamic report or query, but then there is the question of knowing when it is safe to remove them. OR you can take the approach to just leave them where they are. In either case, you will have to compact and repair your DB frequently. You will also face serious DB "bloat" issues.
OK, there are some of your issues. Are you sure you want to do this?
The way I would do it is go to each user and say, "What reports are you going to want?" If they can't answer, they obviously haven't got a clue as to what they are asking for in terms of dynamic reporting.
Now, I should be fair about this. If you only had, say, less than 10 fields where you had any choices, it might be possible to build a "one report fits all" by using form checkbox values as part of the overall query criteria (WHERE clause stuff) defining the report. But the more fields you have that you could select, the worse this gets, and it is a problem in FACTORIAL math.
My best advice is to VERY CAREFULLY rethink this problem before you get totally overwhelmed. If you still want to do it, go for it.
The other way to do this is to allow users to get to the Access report wizards, teach them what fields they can choose, and then impose restrictions on them so that they know you will come behind them to delete EVERYTHING that isn't on the list of "approved permanent reports." Then let them struggle with it and leave you the housecleaning. This requires you to educate your uses regarding what is in your DB and how to use the Access report wizard. But your hair won't go gray as fast or get torn out as fast.
