lucianc

Hi This is a bug introduced in iReport 1.2.5: http://jasperforge.org/sf/go/artf1474?nav=1 A workaround is to set the comptability level of iReport to 1.2.0. I don't know whether there is a better workaround. Regards, Lucian

Hi This behaviour is caused by a bug in iReport: http://jasperforge.org/sf/go/artf1474?nav=1 A workaround is to set the comptability level of iReport to 1.2.0. I don't know whether there is any better workaround. Regards, Lucian

Hi I don't think the subreport is causing a memory leak. The JVM runs out of memory simply due to the size of the report. To be more specific: your sample produces a 6,900 pages report when the subreport is removed. When the subreport is present and each subreport instance renders 500 rows, empirical tests show that the resulting report would be around 460 times larger, making it around 3 milion pages long. Report virtualization does not guarantee filling of arbitrarily large reports using a constant amount of memory. The required memory is still (directly) proportinal to the report size, because some amount of memory is still consumed by each page of the resulting report (but at a much slower rate than when virtualization is not used). You really need 3 milion pages report, you'll definitely need more than 256M of heap space and you'll also need a huge amount of free space on your disk (and a file system that supports really large files, if you're planning to use the swap file virtualizer). Also, you might revise the parameters for the virtualizer. For example, you set the swap file block size to 100 bytes, which is too small consiudereing that your report pages usually produce 6-7 kbytes of virtual data. HTH, Lucian

What I think you misunderstand is the chart dataset increment logic. If you set incrementType="Group" and incrementGroup="DirectionGroup" for a chart dataset, the dataset will only get incremented when the direction group breaks. This is usefull in the chart should display group totals, which is not your case. You need to increment (i.e., feed data to) the chart on each row. With the first data set, the direction group breaks at each row (the direction changes at each step), therefore using group increment is equivalent to using row increment. In the second case, the group breaks only two times (when the direction changes and when the data ends), and only the last value is fed to the chart dataset. Change incrementType to "None" (which is the default, and maybe poorly named) and the charts will be fed data at each row. HTH, Lucian

Also note that the XLS exportes do keep the entire report in memory when IS_ONE_PAGE_PER_SHEET is not set (and it is unset by default). This does not happen when the flag is set or for other exporters. Regards, Lucian

Which JR version are you using? I'm not able to reproduce this.. I don't have your data, do you think it would be possible to somehow isolate the issue and replicate it with some static data? Regards, Lucian

You have printWhenGroupChanges="Coverage" set for your text field. Is this group changing when "NONE" gets repeated? Could you try removing this and see whether the text still gets repeated? Also, on which band is the text field placed? Is it on the detail band? Regards, Lucian

Could you try to fill the same report using iReport/JasperReports >= 1.2.3? Your layout issue might be caused by a bug which was fixed in JR 1.2.3: http://sourceforge.net/tracker/index.php?func=detail&aid=1459774&group_id=36382&atid=416703 HTH, Lucian

Are you using a single data source instance for the subreport? If so, the data source would get exhausted by the first appearance of the subreport and would not yield any data for subsequent appearances. If a subreport contains detail/row data, it should be provided a fresh data source at each subreport instantiation. Another option would be to rewind (if applicable) the data source for the subreport before each instantation of the report (e.g. in the report scriptlet's beforePageInit()). HTH, Lucian

What kind of chart do you want to obtain? Generating distinct series based on the direction can be achieved by simply setting the direction as the series expression: Code: HTH, Lucian