We have generated some 48 reports with the DevExpress XtraReports Suite, and they all look and work great.
The last report we have to get done is our "Executive Summary", which is really nothing more than 9 of the existing reports all gathered into one. When we used to use Crystal Reports this was very easy to do. In their system, you simply drop in a subreport control and then either assign the existing report, or drag and drop it on their control and voila! You have a working subreport - or as in our case, 9 of them in 1 report.
For over a week now I have tried to emulate the same with XtraReports, but nothing works. First I tried using the subreport control and then assigning that control a report. But even if I put just ONE subreport in, I consistently end up with a System Exception - Out of Memory.
I gave up on that approach and tried adding new Detail bands into the report and then bringing in the code and format from each report. To start, I did just ONE report… Same results - an Out of Memory Exception.
Each of the subreport includes a chart or graph, so I tried removing the chart/graph and going with just the printed data - again, I did this with ONE report. Same result - an Out of Memory Exception.
The examples given in the Help system are overly simple, but somewhat helpful - the problem is that they do not represent real business reporting where Datasets can be very large (as mine sometimes are), and they do not seem to account or even mention the load caused by he charts/graphs.
Is there any other way I can get this work done? The "Executive Summary" is one of our most popular and often-used reports. But it appears that XtraReports doesnt have the memory management to handle the task. Can someone please provide suggestion as to how I might do this work, and get it done?
Thank you.
Ticket
Q393925
Visible to All Users
Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Hi Bruce,
Thank you for contacting us. This issue is the result of generating a very large report. Please note that when the report is generated, it completely stays in memory, so the System.OutOfMemoryException may occur. In this situation, we suggest to run a solution under x64 mode or deploy it to x64 server. This solution may resolve the issue.
However, it is strange that a single report works fine, but in the same situation it does not work as a subreport. Would you please answer the following questions in order to clarify the situation?
I am looking forward to hearing from you.
Thanks,
Sergi
Hi Sergi,
Thanks for the reply, hope you are well.
The app we are building is for commercial distribution, so although I understand the x64 opportunities, I have to build for the lowest common denominator which in this case would be x86, Win XP, Min 2 GB RAM.
That said: Here are responses to your questions…
It sounds like the Dataset is an area I should attack first, but the problem there is going to be that if I use subreports, I have to have that data there at generation (eg, right before print) and thus breaking up the Dataset might just be redundant - whether its one large Dataset with 15 tables, or 15 Datasets with 1 table each - am I not going to be in the same situation when these go to load?
Any suggestions would be helpful.
Thanks
Hi Bruce,
Our report builder mechanism is not optimized to process a big number of pages in an efficient manner. I am afraid there is no built-in capability to define a memory limit when generating a report. We have already added the corresponding feature to our To-Do list (Data - Improve performance and memory usage when generating very large reports (e.g. report generating server)), but the target release date isn't yet established.
We have already discussed this scenario and have examined the report builder execution procedure via the profiler tool (various common document layouts were used), but we have not found any major bottlenecks there. As an immediate solution, I suggest that you use a subset of the original data collection to generate a partial report document.
Alternatively, you are welcome to examine our source code and modify it based on your requirements, but we do not provide any support for modified API or any related breaking changes. The report builder infrastructure is a part of our native (private) API, which isn't covered in our documentation. I hope you understand our position.
Thanks,
Alex
Thanks for the info Alex.
I understand this is a work-in-progress for XtraReports and for now, I can hold off release of this report so no need to get into the API or anything like that.
I will try some final things on my end such as building the data in the BeforePrint event to see if I can work around this - if not, we will sit tight untill a later time when XtraReports might be able to manage this.
Thanks again.
Bruce,
Thank you for your response. Please feel free to update this ticket if you need any further assistance. I will be glad to help you.
Thanks,
Alex