Skip to content

Tips & Tricks

This section provides a list of guidelines that will  assist you during the report development process. These are described under  modeling, RDF modifications for XML generation and layout design.

Modeling

Use of appropriate view types

Use a New Detail view along with an Aggregate Array relationship to represent data with multiple occurrences and an Aggregate relationship to represent data with a single occurrence. For example consider order items for an order. There will be multiple occurrences of order items for a given order. Therefore use an Aggregate Array to represent the order items. Consider Total discount amount for a given order which will appear only once for the entire order. Use an  Aggregate to represent data of this nature.

Naming views

When naming newly created views, use meaningful names which best describes the data contained in the view. Avoid using abbreviations as it may not be too clear for the others. Having descriptive names will prove useful later on as these names are used in the XML as elements and having well defined logical names makes it all the more easier to understand the XML structure better.

Naming aggregates

Name the aggregate to reflect it's view. In most cases the name given to the aggregate is the plural of it’s connected view name. For example, if the name given to the view is Orderthe aggregate is named asOrders. This may not always be the case but as long as the aggregate name describes the view it's connected to, it is acceptable.

Set aside unwanted report columns

Use Report wizard to set the view columns blank for database columns that do not appear in the layout. However, if you feel that these unused columns might become useful in the future then go ahead and include them in as this will avoid any inconvenience in having to add them to the model on a later date.

RDF modifications for XML generation

Draw up a rough XML structure

Put down the report's XML structure on a piece of paper and use it as a guideline to carry out the RDF modifications. Refer your XML structure from the top and modify the RDF to create corresponding elements, start tags and end tags.  Once you complete the modifications compare the XML structure generated by the RDF with that of your sample XML structure. Verify if all elements are present, start tags have their matching end tags and the end tags are placed in the appropriate locations.

Use Report_Sys methods

Always use Report_SYS methods to define the report and it's layouts. Avoid using table comments.

Call Report_Sys.Finish_Xml_Report method call

Do not forget to add the Report_Sys.Finish_Xml_Report method call as the final RDF modification. This statement initiates the XML to be written to the database and therefore it is important to make sure it is present.

Layout design

Selecting page dimensions

It is always a better option to select Set page size in runtime option over Fixed page size option when setting page settings for a new custom layout. This way you can reuse the same layout for both A4 and Letter paper formats. You need not create separate layouts for different paper formats.

Adding horizontal lines in the flow section

Use border properties of tables and cells to draw horizontal lines in the flow section. For instance, if a line needs to be drawn after printing the column titles, select the cells of the row which contains the column titles and set the border bottom property to solid. This will add a line underneath the column titles. Follow this approach to create horizontal lines in the flow section.

Adding space between lines

To have additional space between lines one can make use of empty table rows. However adding an empty row it self will not be enough, as the row height would initially be set to 0. Therefore, slightly adjust the row height using the mouse pointer or set a specific row height using the row properties. Another option is to add cell padding to achieve the same output. Simply select the cells, set the padding for the bottom border explicitly. Having both these options in mind it is best to follow the first option as the use of padding may not be as successful.

Grouping fields together

Use block containers to group things together within static areas. Add a block and place the fields inside the block. Now, you can simply move all the fields within the block by simply moving the parent block. Grouping fields together in this manner will help you move fields without disturbing their relative positioning.

Formatting Dates and Numbers

When selecting format options for numbers and dates it is recommended that you select run time formatting over hardcoding and format masks. Use of run time formatting will increase the flexibility of the report and give you the freedom to select a preferred locale at run time.

Setting page breaks

When setting page breaks it is always a better choice to go for the yes - except last page/yes - except first pag e options. The reason for this choice is that, simply selecting yes for Page Break after property might result in an additional blank page being added to the end of the report and similarly, with Page Break before a blank page might be added to the beginning of the report. By using yes - except last page option for Page Break after and yes - except first page for Page Break before one can avoid such situations. Having said that, if the report requirement is to add a blank page then that can be achieved by selecting the property value yes.

It is also a good practice to use conditional breaks to avoid any blank pages being added to the middle of the report. This may occur after printing the break and then realizing that no data is present in the next row or table. To avoid such instances make use of conditional breaks available with the Conditions dialog.  This way the page break will be applied only if a given table count is greater than zero. For example, if you set a page break with the condition count(tns:MODULE_REP/tns:MODULES/tns:MODULE) > 0the break will only be applied if the data count of MODULES is greater than zero.