Skip to Content

This issue is specific to the following variables:

  • VS .NET application
  • Export to non paginated file format
  • Large amount of data

The following are considered to be non paginated file formats:

  • CharacterSeparatedValues
  • ExcelRecord
  • EditableRTF
  • RichText
  • TabSeperatedText
  • Text
  • Xml

These paginated file formats will normally not cause the same issue:

  • CrystalReport
  • Excel
  • HTML32
  • HTML40
  • PortableDocFormat
  • WordForWindows

A definition of large amount of data is difficult to define (see below), however internal testing was able to reproduce the issue with >90,000 rows and about 30 columns. Interestingly, export to non paginated file formats works in the CR designer and thus the issue is limited to VS .NET applications, making me wonder if the issue is a combination of the framework, the OS and the Crystal Reports Print engine. The issue has been escalated for a fix and is being tracked under ADAPT01320923. At this time there is no ETA available for a fix and just to set expectations, it may very well be that the issue will not be fixed. Discussions are ongoing with the product managers and developers to see what if anything will be done in future service packs and/or product releases.

Probably for the most part, the issues is due to the way the Crystal Reports print engine allocates memory for the exported file. All exports are exported in “blobs”. However non paginated file formats are exported as one large blob as opposed to paginated export formats, where each page is it’s own distinct blob. When the amount of data consumed by the report is small, export to non paginated file format is not an issue as there is enough contiguous memory space to complete the operation. When a report consumes a large amount of data is may be that there will not be enough contiguous space and thus the error. Whether an error occurs depends on the system as well as the state of the system; The space available will differ from system to system depending on how much total memory the system has and how long the server has been running. Less contiguous space will be available when a server has been running for a long time. And indeed, it is usually reported that the same export may run initially, perhaps even for a number of days and then for no apparent reason, the error will be thrown. This makes the issue difficult to analyze and resolve. Not only is this dependent on the server, but also on the server load, the applications running on the server, amount of time the server has been running, and more.

What work-arounds are available until a fix is released? 

1) With the Crystal Reports Server or Business Objects Enterprise products, the reports can be scheduled to be exported to the desired format. The Report Job Server and the Output File Repository are designed to handle these types of large export files. Once the print job is done the exported file can be retrieved from the system and served up to the end user. The Crystal Reports and InProc Report Application Server (RAS) SDK were not designed to handle these large export files. By design, these are limited to small/agile reports (and thus small export files) that are returned in a matter of 10s of seconds, not for reports that take minutes to complete.

2) Use paginated export formats. These perform well even for very large reports. I am not sure if there is a limit on amount of data when exporting to a paginated file formats (I suspect there is, but have not come up against one as yet), but you will be able to export a larger data sets with these formats.

3) Limit the amount of data exported by use of selection formulas. This may prove to be tricky to determine due to the system memory variability (see above).

This blog is based on the forum thread ‘System.OutOfMemoryException’ when exporting to XML format where David Hilton provides additional excelent information.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply