Use the Data Access tab to:
- define class joins to enable reporting on data from multiple classes or tables. For each class join, define one or more logical conditions that specify how to match or join corresponding instances in different classes. For example:
MyOrg-CustomerService-Work.ProductID Is Equal MyOrg-Sales-Data-Products.SKU
- list declarative indexes to allow including embedded properties in the report. A declarative index uses an Index- class defined by a Declare Index rule to store embedded properties in a separate database table so they can be easily and automatically joined to the class table for the class of the report.
- view the list of Association rules that are used within the report to add properties in different classes that the report references.
- identify and configure the connections to sub-reports that provide data for this report.
- set general data source settings, such as resource limits on the maximum number of rows of data to retrieve for this report.
Note: You can adjust default settings for all reports on the Reporting > Settings landing page.
- define security access privileges for the report.
Note: You can define property-specific restrictions in the Access Manager landing page, and these restrictions apply to reports run from the Report Browser.
Class Join
Field
|
Description
|
| Prefix
|
Enter a short text string to be used as an alias for the joined class and its properties. The Prefix must be used to qualify all references to properties in the class on all tabs in the rule form.
|
| Class Name
|
Select a class to be the primary class for the join. The Prefix plus this class name specify the joined class.
If this work type is derived from Work-, choose carefully whether you want to join to an , or to a .
Note: You cannot join to a class in a different database than the Applies To class of the report.
|
| EditConditions (button) |
Click to open the Enter filter conditions form and specify filter conditions that describe how to join or match corresponding instances in the Applies To class of the report and the joined class.
Add rows for multiple filter conditions by clicking the Add join filter link.
Complete the fields for each condition:
| Field
|
Description
|
| Condition
|
Enter a text label to identify the condition in this row. The label is used in the Filter conditions field to identify the condition. |
| Column
|
Select a property within the joined class. This property must be an exposed column. |
| Relationship
|
Select Is Equal. |
| Value
|
Select a property in the report's Applies To class. |
| Filter conditions
|
If you define multiple filter conditions in a join, enter here an expression that describes how the conditions should be combined, using the Condition labels, AND, OR, and parentheses as needed.
For example, if the form contains four conditions labeled A, B, C, and D, you can enter: (A OR B OR C) AND D in this field. This notation is the same as for the logic statement in when condition rules.
The expression entered must include every filter condition in the list.
|
Click OK to establish the filter conditions and dismiss the form. Click Cancel to leave the form without saving any changes you made.
|
| Type
|
Accept the default choice, Only include matching instances, to cause the report to only include instances in each class that have a matching instance in the other class (referred to in database terms as an inner join).
By choosing one of the other options, you can instead use an outer join for the report in which all instances of one of the classes are included in the report even if they have no matching instances in the other class:
- Select
Include all rows in <class> to cause the report output to include all qualifying instances of the Applies To class of the rule, even if there is no match found in the prefix class.
- Select
Include all rows in <prefix> to cause the report output to include all qualifying instances of the joined class (identified by the value of the Prefix field), even if there is no match found in the Applies To class.
|
 Note that when you define a join from one class to another, the report results may include multiple entries for each work item, if there are multiple corresponding entries in the other class or table. |
Declarative Index Join
This area lists instances of Rule-Declare-Index rules used to access embedded properties from the Applies To class of the report. Normally, this area is read-only and does not need to be modified by you, since declarative indexes are automatically added to this list as references to embedded properties are added to the report.
Field
|
Description
|
| Prefix
|
Enter a text string to be used as an alias for the joined declarative index class and all its properties. The prefix is assigned to all the properties in the class and used to reference these properties on other tabs of the rule form.
|
| Index Name
|
Select the Index- class created by the Declare Index rule.
|
| Type
|
Optional. The default choice, Only include matching instances, indicates that the report will only include instances in the Applies To class that have a matching instance in the declarative index (referred to in database terms as an inner join). By choosing the other option here, you can instead use an outer join for the report, in which all instances of the Applies To class are included in the report, even if they have no matching instances in the declarative index.
|
Associations
This read-only area lists any Association rules included in the report. See the PDN article When and how to create an association rule to support reporting.
Sub-Reports
Sub-reports enable results from any report definition (including a report definition defined on a different Applies To class) to be referenced and included in a different report definition. Any report definition to which you have access, and which does not have its own sub-report, can serve as a sub-report.
Using a report as a sub-report does not change its definition or design, and users can still run such reports directly and independently.
See the PDN article When and how to use sub-reports in Report Definition reports.
To add a sub-report, click the Add subreport link in the Sub-Reports section. Fill in the three fields:
Field
|
Description
|
| Prefix
|
Create a unique prefix for the sub-report, consisting of letters, numbers, and the underscore character, with no spaces. This prefix must not be the same as the prefix for any other sub-report, or for a Class join or Declarative Index join, in this tab. |
| Class name
|
Select the Applies To class of the report you wish to use as a sub-report. |
| Name
|
Select the name of the report to use as a sub-report. If you select a report that has its own sub-report, an error message appears when you click the Configure button to remind you that "a sub-report cannot itself contain a sub-report." If you see this error message, select a different report to serve as the sub-report. |
After you have added a sub-report, click the Configure sub-report button to display the Configure sub-report use form. Complete the form as follows:
Field
|
Description
|
| Number of rows returned by this sub-report?
|
Select either More than 1 Row (the default) or 1 Row. Your selection here, together with your selection for the next option, Where will you use this sub-report?, will determine whether you need to specify filter conditions to join or match corresponding rows of the sub-report to those in the main report. |
| Where will you use this sub-report?
|
Indicate where columns from the sub-report will be referenced on the Query tab. Select all options that apply for any of the columns in the sub-report:
Edit Columns section of Query tab
Edit Filters section of Query tab - Column Source
Edit Filters section of Query tab - Value
|
| How will you join rows in the reports?
|
Click the Add join condition link to add filter conditions for joining or matching corresponding rows of the sub-report to those in the main report. For each condition provide information in the fields as follows:
Field
|
Description
|
| Label
|
Provide a unique alphanumeric label, with no spaces, for the condition. |
| Sub-Report Column
|
Select a column from the sub-report. |
| Relationship
|
Select a relationship statement (Is Equal, Is Greater Than, and so on). |
| Value
|
Select a property in the main report. |
Use the labels to enter an expression in the Conditions field at the top of this form to describe how the conditions should be combined, using the Condition labels AND, OR, and parentheses as needed. Each filter condition must be referenced in the Conditions expression.
Select one of the options in the drop-down menu to specify whether the report includes:
- only matching rows from both reports
- all rows from the main report, regardless of whether they have a matching row in the sub-report
- all rows from the sub-report, regardless of whether they have a matching row in the main report
The default option is Do not match rows.
Note: Join conditions must be specified for a sub-report that returns more than one row, unless the only reference to the sub-report is as a Value entry in the Edit Filters section of the Query tab.
|
| Ignore filter conditions from the sub-report in this report
|
Select this option to ignore any filter conditions specified in the sub-report. Selecting this option means that only the filter conditions in the main report determine the report results; otherwise, only the sub-report results that satisfy the sub-reports' filter conditions are included in the main report. |
| Local names for sub-report columns
|
For each column in the sub-report, provide an alias (composed of letters, numbers, and the underscore character, with no spaces). The report uses these aliases in its selection menus when listing sub-report columns as options. |
| Sub-report parameters
|
If the sub-report has input parameters, then:
- Check the Auto-populate parameter values from main report box if you wish the sub-report parameters to have the same values as the corresponding parameters in the main report. This assumes that these parameters exist in both reports.
- Otherwise, supply values for the sub-report’s parameters here.
|
When you have completed configuring the sub-report, click OK. Click Cancel to leave the form without saving your changes.
General Data Source Settings
You can enter settings for some of these options on the Designer Studio> Reporting > Settings landing page that will serve as defaults for all reports.
Field
|
Description
|
| Maximum number of rows to retrieve
|
Optional. Enter a maximum number of rows of results to retrieve for the report. As a best practice during testing, accept the default value 500. If you leave this blank, the system enforces a limit of 10,000.
If you exceed the established limit, the rows that have been retrieved are displayed, and the report header displays how many rows there are. No error dialog or error message is shown, and no error is written to a log.
When the Use Paging check box on the User Interactions tab is selected, this value is ignored (and not available). You can advance though pages with no limit.
|
| Maximum elapsed time in seconds
|
Optional. Enter the maximum elapsed time in seconds that the report execution is allowed to run before being interrupted. If you leave this blank, the system enforces a default limit of 30 seconds.
If the report exceeds the maximum elapsed time, a dialog appears explaining that the report took too long to run and that the filter conditions must be more specific. A report typically runs faster by adding additional filter conditions, or making the existing ones more constraining.
|
| Maximum number of rows for export
|
Optional. Enter a maximum number of rows of results that will be exported. If you leave this blank, the system enforces a limit of 10,000. |
| Maximum elapsed time in seconds for export
|
Optional. Override the default of 30 seconds if your system generally requires more time to export a report. |
| Restore defaults
|
Click to clear any custom values and to restore the system defaults for the four settings in this section.
|
| Display unoptimized properties in data explorer
|
Check this check box to have unoptimized properties (properties stored in the BLOB column) appear as selection options in the Report Editor's Data Explorer, in the Calculation Builder, and when defining report filters.
Caution: When you select an unoptimized property, a reminder appears that using such properties in calculations or for report columns may significantly reduce report performance. See the PDN article When to use — and when not to use — unoptimized properties in reports.
Caution: Calculations in reports cannot read data from encrypted BLOB columns. If the BLOB column is encrypted, you need to optimize the properties you want to use.
|
| Report on descendant class instances
|
If there is any implementation class in the application rule set list, check this check box to have the report build its query using the implementation class mapping. This feature eliminates the need to copy each framework class-based Report Definition into the implementation class.
Caution: This is extended behavior from versions previous to 7.1. If you want the report to be based on the parent framework class, make sure this check box is unchecked.
|
| Use alternate database
|
Select to have the report use the database identified in the Reports Database field of the Data-Admin-DB-Table instance that supports the Applies To class of this report. See How to use a reports database.
If no alternate database has been identified, checking this check box has no effect.
If the report uses JOIN operations that draw from multiple database tables, all tables must be in the same reports database.
|
| Ignore formatting when exporting to Excel
|
Select to ignore the column formatting in the Report Definition in the Excel spreadsheet. |
| Ignore formatting when exporting to PDF
|
Select to ignore column formatting in the Report Definition in the PDF file. |
| Ignore application skin when exporting to PDF
|
Select to remove the styles that were applied from the application skin when exporting to PDF. This is useful for improving performance when exporting to PDF. Custom styles can be added to pyReport_ExportToPdfStyles.css when selected. |
Row Key Settings
Field
|
Description
|
| Get row key
|
If this check box is checked, the key of the table (usually the pzInsKey property, for internal classes) is included among the columns listed in the select clause.
By default, this check box is selected. However, when you select the Remove Duplicate Rows option on the Design tab, this check box is cleared, because if a unique row key is included, there are no duplicate rows.
|
Class Join
Security
Field
|
Description
|
| Privilege
|
Optional. Use SmartPrompt to select security privileges required to run this report. Click the Add Privilege link to add additional privileges. |
Related Information
Open topic with navigation