In general users want to insert a report inside another report to simulate a master-detail relation. To NextReports this means to insert a report inside the detail band of the master report, communication being done through a simple convention: the sub-report must have a parameter with the same name as a column from the master query
This natural way (vertically data scaling) translates to generate a sub-report for every result from our query.You can read more about it here
There are some situations when users want to scale their data horizontally and not vertically as in a master-detail form. Your query can become from too complicated to nearly impossible in achieving such thing. To make it easily possible, NextReports 6.1 introduced a new type of element inside report layout: Multiple Report
element (FOR) contains a report with a special property: "multiple report sql
" (FOR-SQL). The report must have a parameter with the same name as the column from FOR-SQL.
At run time, this FOR element is replaced with a number of report elements. This number is the number of values returned by the FOR-SQL. A value from FOR-SQL will be passed to corresponding report's parameter.
To make it more clear, lets look at a simple example. We have a simple database with scores from EURO 2012 tournament. These scores are grouped on stages like Group First Game, Group Second Game, Group Third Game and so on until the Final. Inside database there are also kept the scores entered by some users. Any user guessed the result exactly, guessed just the prognostic 1/X/2 or did not guess anything and was rewarded with 3 points, 1 point, 0 points respectively. We want a report to show all the results as they happened and all the results entered by users with the rewarded points. We also want for every user to compute the total number of rewarded points per stage and per entire tournament along with some other statistics.
To make an idea of what we want to accomplish I will start with showing you the results. You can see in the first image every stage with the games, scores, users scores and users rewarded points:
In the second image (the end of report) you can see the statistics for the entire tournament:
This kind of report is a typical candidate for a "Multiple Report" usage. What we can observe by looking at the previous images is that report can be divided between to elements:
- a stage element which shows the games from a stage and the scores
- a repetitive user element which shows the scores entered by user and the rewarded points
So we need to create two reports. First one has just a grouping by stage (to show games and scores) and the labels for statistics section:
Second report has the same number of visible rows with the same fonts and padding for every corresponding row from the first report (We used some detail rows D1-D4 just to compute some expressions for statistics section, these expressions are hidden, and the detail rows D1-D4 are also hidden):
Second report also has a user parameter allowing us to run it for every user.
After that we can create a new report with the following layout (just two cells where we insert the previous reports):
We can see that the second report was added as a "Multiple Report" (FOR element). When we click the FOR element we can see it's properties with the new "multiple report sql". This query will return us the names of the users who entered scores for the tournament:
When you notice that you need a "Multiple Report" for your design, it is always easier (especially if you have a lot of rows) to create at first a single report which will show everything just for a single entity (user in our case). Then you should cut it in two reports (left and right parts) and create the new report as showing before. In this way you are sure that all rows from the split parts have the same fonts and padding, so when you run the master report there will be no vertical shifts.