Reporting - Troubleshooting Excel and CSV Export

Some of you may remember the days when Reporting was all about printing to paper. Stacks of paper, sometimes – people used to create elaborate sheet puzzles on the largest flat surface they could find to have an overview of all the report data at once. These days priorities have changed and reports are often exported to various document formats for electronic distribution and sharing.

DevExpress Reporting has excellent support for export formats, but some of them are better suited to the typical WYSIWYG-designed report than others.

Not All Document Formats Are Equal

If you create a report in a feature-rich designer like ours, you can use many different elements to make up your layout. Data may be presented in a clear tabular format, but there are usually headers or formatted titles, and possibly graphical elements, charts or sub-reports. A visually rich report document can be represented perfectly by a document-centric export format like PDF. Some formats do a reasonably good job with document presentation but can have issues when documents need to be edited - DOCX and RTF fall in this category (we plan to blog about related issues in the future).

Finally, there is a group of formats that have limited support for document visualization because their main purpose is interactive work with the embedded data. This is true to an extent for XLS(X), and even more so for CSV. This last group is the one we want to focus on in this post.

Please Consider Implementing Data Export Separately

Before we get started with hints to improve report exports to Excel and CSV formats, please consider implementing data export features in your applications separately from Reporting. Much of the functionality provided by a WYSIWYG Reporting system is unnecessary for the purpose of creating pure data exports for end users who want to run their own analysis processes in spreadsheet applications. What they need is the cleanest possible data-only export structure, and visual elements of any kind are frequently in the way and don’t provide any added value for this purpose.

Please check out the DevExpress Spreadsheet Document API as an option if you consider creating data export functionality that is independent of Reporting.

If You Really Need Clean Data In A Reporting Export

Several export formats don’t support intersecting elements. For those formats, our export engine generates a tabular structure where columns and rows are used to position output elements as required by the visual report layout. Especially for Excel and CSV formats, this technical implementation may result in extra columns or rows, or even merged cells, which makes it hard to work with the documents for data analysis purposes.

We have evaluated several problem scenarios, and below you can find possible workarounds, strategies to design your reports in order to keep them compatible with data-centric exports.

Misaligned Columns

Here is an image showing a report layout with a table. It might be hard to see, but the table header columns are not aligned perfectly with the table cells.

Here is an XLSX file created from this report definition:

You can see that only the columns A, C, E and G are fully visible in Excel. Extra columns B, D, F and H have been added to the XLSX export file.

As mentioned above, the reason for this behavior is that the columns in the table header are not aligned correctly with those in the detail band. The problem becomes more clearly visible if you zoom in on the Excel file and set some background colors:

The misaligned column borders are highlighted with red lines in this image.

You can fix this problem by aligning header and detail band table cells precisely, using the vertical indicators displayed by the designer. This image again uses red lines to illustrate:

Empty Space

Here is a report with empty space between individual report controls:

When exporting to XLSX, this is the result:

Extra columns and rows have been generated in this case, to reflect the spacing of the design. In the sample case it’s not hard too see what happened, but for complex scenarios it can be a good idea to set element background colors in the report designer before you export. The colors will show in Excel, making cell boundaries easily visible:

As a solution, we recommend to adjust element positions and sizes in your report layout so that no empty space remains. You can use the TextAlignment and Paddings properties so that labels are still displayed in the same locations as before:

Headers And Footers

Report header and footer bands can also be the culprits when additional rows or columns are found in an export file, if their controls don’t line up with those in other bands. Here is an image of a report design that shows this problem:

The resulting XLSX file looks like this:

To understand exactly what is going on, it helps to export with background colors. This image shows red lines to illustrate which controls influenced the creation of columns.

As before, the recommendation is to align controls in headers and footers with those in the data bands of the report.

Calculated And Custom-Formatted Values

If you had a requirement for your reports to include calculated values or to apply complicated custom value formatting, you may have used a BeforePrint event handler to assign custom values to the Text property of labels or table cells. Unfortunately this mechanism doesn’t work with Excel and CSV exports. The reason is simple: Excel and CSV are the only currently supported formats that distinguish between string values and other data types. Our export engine uses the original typed data source values by default (XlsxExportOptions.TextExportMode is Value) so that resulting export files can be used for data analysis purposes. But at the same time this behavior means that dynamically assigned Text values are not included in the export.

There are several different solutions to this problem.

1. Since v17.2, the property XRControl.Value is marked public. If you have existing BeforePrint implementations, you can change them to assign to Value instead of Text, and your dynamic values will be included in Excel and CSV exports correctly.

2. You can use the event EvaluateBinding instead of BeforePrint. Assign your calculated value to e.Value if you choose this approach.

3. Change XlsxExportOptions.TextExportMode to Text. This is the quickest possible fix, but it comes with the serious downside that all values will be exported as strings. Especially in Excel files, this means that users can’t easily perform calculations with the values.

CSV Export Specifics

All examples shown above apply to CSV exports as well as Excel exports. However, some additional options are available for CSV that can help avoid empty cells in the resulting export file.

The options SkipEmptyColumns and SkipEmptyRows are enabled by default. Here is a sample report design to demonstrate the effect of these options:

When exported to CSV and loaded back into Excel, this is the result with default settings:

For comparison, this is what you get if both properties are switched off:

A final option that is sometimes useful for CSV exports is the static property FollowReportLayout. This is true by default, and here is another sample report exported with that default setting:

If the option is switched off, certain layout details of the report are not observed when exporting. This means that additional empty space can be eliminated from an export.

Please note that these extra options for CSV format exports are meant to be used in conjunction with other methods described previously. For CSV, it is even more important to be able to generate clean data export structures, since the format is frequently used for automated data transfer mechanisms.

Conclusion

As described at the start of this post, purposes collide when WYSIWYG documents need to be exported to precise structures such as those required in Excel or CSV files for data processing. It is good advice to use alternative approaches when consistent data structures are expected from an export feature. For those scenarios where a compromise must be found, the approaches described above can be helpful. Please let us know what you think, or if you have discovered additional methods yourself to work around specific export issues.