Structure

There are three major parts of a report: Data structure, Data binding and Report layout.

Data Structure

All ported reports always have two tables: InputItems and ReportVariables. The tables are linked by a unique progressive ID column named _ReportVariablesRowId. All the input items from the original report are generated as fields in the InputItems table, while all the report variables are fields in the ReportVariables table.

Data binding

At runtime, the PPJ Framework takes care of building a DataSet by generating and handling all the SAM_Report* events in the correct order. The dataset is then passed to the CR.NET module to print the report. While generating the data set, the value _ReportVariablesRowId is increased every time a new report variable is assigned. We have a one-to-many relationship between the ReportVariable table and the InputItems table because report variables usually change only a handful of times in a typical report and would be a big waste of memory to repeat the same row for each InputItem row.

Report layout

Report Builder reports are separated in the usual sections. However, each section is separated in old fashioned lines. While porting, we try to consolidate lines into the same report section in Crystal Report. Only when a line needs to grow or has different properties compared to the next line, we generate a new section in CR.

Linked fields in Report Builder are ported as subfields in a larger text field in CR.

All report formulas are ported with vert minimal transformations. We try to use CR built-in functions when possible. We have implemented the following unsupported functions are new methods at the report level:

• DateAddDay

• DateIFF

• DateMonthBegin

• DateMonthEnd

• DateToStr

• NumberIFF

• Power

• StrCase

• StrMid

• StrPad

• StrReplace

• StrTranslate