Report Definition Language syntax and usage
The following conventions are used to document the syntax of the Report Definition Language statements:
- Statement names and keywords are shown in UPPERCASE.
- Arguments that you should replace with actual data are shown in lowercase italics.
- Optional items are enclosed in [italic square brackets].
- String data is enclosed in “quotation marks.”
- Arguments that may be repeated more than once are followed by an ellipsis (…).
Here’s an example:
|
General usage rules
- You can specify statement names, keywords, and arguments in either uppercase or lowercase, except for quoted definition names, which must be uppercase. (ReportWriter converts all nonquoted data to uppercase on input.)
- When an RDL file is “loading,” if required data has not been supplied, or if the data is invalid, an error message is logged and the entire report is ignored.
- You can specify keywords in any order. The documentation lists keywords in the order in which they are generated by the Generate Report Schema utility.
- A keyword that is longer than a single physical word cannot span multiple lines. For example, the following is incorrect, because the INFO LINE keyword is split between two lines.
QUESTION CITY TYPE ALPHANUMERIC SIZE 30 PROMPT "City:" DEFAULT "*" INFO LINE "Enter name of city."
- Keyword file definition names must include the structure name, using the format file.structure.
- Keyword field definition names must be unique within a report. You may have to include the file and structure name to make the field name unique (for example, file.structure.field).
- Do not specify a negative value for a numeric keyword argument, except where noted. A negative value must be immediately preceded by a minus sign (for example, -3 or -10).
- Keyword string data must be enclosed in a set of matching double or single quotation marks
(“ ” or ‘ ’) and cannot span multiple lines. - String data can contain a quotation character if that character is different from the character that encloses the data. For example, the following string is valid:
“Press ‘Enter’ to continue”
- Data that exceeds the maximum size allowed is truncated.
Recommended statement order
To ensure that your Report Definition Language statements are loaded properly, we recommend you define them in the following order. The statements you’d use are in parentheses.
1. | Define the report name and all files. (REPORT, FILE) |
2. | Define all temporary fields in the order in which you want them evaluated. (CALCULATION, ENVIRONMENT, QUESTION, SUBTOTAL, TEMPTEXT) |
3. | Define all selections and sorts. (SELECT, SORT) |
4. | Define each line in the order you want it to appear in the report, along with all of its fields and text. (FIELD, LINE, TEXT) |
5. | Define any miscellaneous report options. (MISCELLANEOUS) |
Field_spec definition
A number of the RDL statements require a field_spec, which is a specification for a field in a report. A field specification may optionally contain subscript or range information.
- A simple field_spec has the format
field [FID fid]
- A field_spec with optional subscripting has the format
field[[subs_value[,subs_value ...]]] [FID fid]
- A field_spec with optional ranging has the format
field[(offset:length)] [FID fid]
Arguments
field
A unique field name. If field alone does not identify a unique field, file.field or file.structure.field must be specified. Field can be a maximum of 30 characters and cannot contain spaces.
FID fid
(optional) The owner file ID. Specify this keyword if a file and structure combination has been selected more than once.
subs_value
(optional) Either a numeric literal or a nonranged, nonsubscripted field name to be used as a subscript value for an arrayed field. (Notice that if one or more subs_value arguments are present, they must be enclosed in square brackets. The arguments must be separated by a comma and can contain no embedded spaces.)
Because an arrayed field can have up to four dimensions, the field can have up to four subscript values.
offset
(optional) Either a numeric literal or a nonranged, nonsubscripted field name to be used as the base one offset position to range “from.”
length
(optional) Either a numeric literal or a nonranged, nonsubscripted field name to use as the “length” of the range.
Examples
ARCUST ARRATE[3] ARCUST(1:15) ARTRANS.ARTRANS.ARCUST FID 1
Condition_spec definition
Conditional_spec is a specification for a condition or set of conditions in a report. It is used after the IF or the SELECT keyword.
field_spec compare value [TRUEIFBLANK][connect field_spec compare value [TRUEIFBLANK]] [...]
Arguments
field_spec
A specification for a field. (See Field_spec definition above.)
compare
The operator used to compare field_spec with value. Valid values are:
EQ = Equal to
NE = Not equal to
LE = Less than or equal to
LT = Less than
GE = Greater than or equal to
GT = Greater than
value
Either a literal or another field specification. If value is a literal value, enclose it in quotation marks. (See the examples for CALCULATION and LINE.)
TRUEIFBLANK
(optional) Indicates that the conditional evaluates to TRUE if the field_spec operand is blank or zero.
connect
(optional) The connector used if you’re specifying two or more conditions. If you specify connect, you must also specify field_spec, compare, and value. Valid values are AND and OR.
Up to five conditions can be connected together for all conditional_specs, except those used in selections, which can have up to 25.
Examples
ARRATE[3] EQ "400" TEMP.QDATE GE TRANS.START_DATE AND TEMP.QDATE LE TRANS.END_DATE SALES.REP EQ TEMP.QREF TRUEIFBLANK