Tabular reports
A tabular report is the most basic type of report. Each column corresponds to a column selected from the database.
Group above reports
A group above report contains multiple groups in its data model. It is a "master/detail" report, where there may be a lot of information in the master group. For every master group, the related values of the detail group(s) are fetched from the database and are displayed below the master information.
Group left reports
A group left report also contains multiple groups in its data model, dividing the rows of a table based on a common value in one of the columns. Use this type of report to restrict a column from repeating the same value several times while values of related columns change. The data model for group above and group left reports is the same,
but the layouts differ; group above reports display the master information at the top while group left reports display break columns to the side.
Form-like reports
A form-like report displays one record per page, displaying field values to the right of field labels.
Form letter reports
A form letter report contains database values embedded in boilerplate text (any text that you enter or import into a Report Editor.)
Mailing label reports
A mailing label report prints mailing labels in multiple columns on each page. Using the Report Wizard, you can specify the format for your mailing labels.
Matrix reports
A matrix (cross-product) report is a cross-tabulation of four groups of data:
• One group of data is displayed across the page.
• One group of data is displayed down the page.
• One group of data is the cross-product, which determines all possible locations where the across and down data relate and places a cell in those locations.
• One group of data is displayed as the"filler" of the cells.
TYPE OF TRIGGERS
associated with the trigger.
Report triggers are activated in response to report events such as the report opening and closing rather that the data that is contained in the report. They are activated in a predefined order for all reports.
Format triggers are executed before an object is formatted. A format trigger can be used to dynamically change the formatting attributes of the object.
Validation triggers are PL/SQL functions that are executed when parameter values are specified on the command line and when you accept the Runtime Parameter Form.
Database triggers are procedures that are stored in the database and implicitly executed when a triggering statement such as INSERT, UPDATE, or DELETE is issued against the associated table.
About report triggers
Report triggers execute PL/SQL functions at specific times during the execution and formatting of your report. Using the conditional processing capabilities of PL/SQL for these triggers, you can do things such as customize the formatting of your report, perform initialization tasks, and access the database. To create or modify a report trigger, you use the Report Triggers node in the Object Navigator. Report triggers must explicitly return TRUE or FALSE.
Oracle Reports has five global report triggers. You cannot create new global report triggers. The trigger names indicate at what point the trigger fires:
a.Before Report trigger: Fires before the report is executed but after queries areparsed.
b.After Report trigger: Fires after you exit the Paper Design view, or after report output is sent to a specified destination, such as a file, a printer, or an e-mail ID. This trigger can be used to clean up any initial processing that was done, such as deleting tables. Note, however, that this trigger always fires, whether or not your report completed successfully.
c.Between Pages trigger: Fires before each page of the report is formatted, except the very first page. This trigger can be used for customized page formatting. In the Paper Design view, this trigger only fires the first time that you go to a page. If you subsequently return to the page, the trigger does not fire again.
d.Before Parameter Form trigger: Fires before the Runtime Parameter Form is displayed. From this trigger, you can access and change the values of parameters, PL/SQL global variables, and report-level columns. If the Runtime Parameter Form is suppressed, this trigger still fires. Consequently, you can use this trigger for validation of command line parameters.
e.After Parameter Form trigger: Fires after the Runtime Parameter Form is displayed. From this trigger, you can access parameters and check their values. This trigger can also be used to change parameter values or, if an error occurs, return to the Runtime Parameter Form. Columns from the data model are not accessible from this trigger. If the Runtime Parameter Form is suppressed, the After Parameter Form trigger still fires. Consequently, you can use this trigger for validation of command line parameters or other data.
2.TRIGGER SEQUENCES.
Order of report trigger execution
The order of events when a report is executed is as follows:
1. Before Parameter Form trigger is fired.
2. Runtime Parameter Form appears (if not suppressed).
3. After Parameter Form trigger is fired (unless the user cancels from the Runtime Parameter Form).
4. Report is "compiled".
5. Queries are parsed.
6. Before Report trigger is fired.
7. SET TRANSACTION READONLY is executed (if specified with the READONLY command line keyword or setting).
8. The report is executed and the Between Pages trigger fires for each page except the first one. (Note that data
can be fetched at any time while the report is being formatted.) COMMITs can occur during this time due to:
SRW.DO_SQL with DDL, or if ONFAILURE=COMMIT, and the report fails.
9. COMMIT is executed (if READONLY is specified) to end the transaction.
10. After Report trigger is fired.
11.COMMIT/ROLLBACK/NOACTION is executed based on what was specified with the ONSUCCESS command line
keyword or setting.
Usage notes
a. In steps 4 through 9, avoid DDL statements that would modify the tables on which the report is based. Step 3
takes a snapshot of the tables and the snapshot must remain valid throughout the execution of the report. In steps 7 through 9, avoid DML statements that would modify the contents of the tables on which the report is based. Queries may be executed in any order, which makes DML statements unreliable (unless performed on tables not used by the report).
b. If you specify READONLY on the command line, you should avoid DDL altogether. When you execute a DDL statement (for example, with SRW.DO_SQL), a COMMIT is automatically issued. If you are using READONLY, this will prematurely end the transaction begun by SET TRANSACTION READONLY.
c.As a general rule, any processing that will affect the data retrieved by the report should be performed in the Before Parameter Form or After Parameter Form triggers. (These are the two report triggers that fire before anything is parsed or fetched.) Any processing that will not affect the data retrieved by the report can be
performed in the other triggers.
d. Consistency is guaranteed if you use DML or DDL in (or before) the After Form Trigger. However, consistency is not guaranteed in the Before Report trigger, since Oracle Reports may have to start work on data cursors before that trigger based on the definition of the report. Before the Before Report trigger, Oracle Reports describes the tables involved and opens cursors. Any change to the tables after that will not be seen by the report.
Restrictions
a. If you are sending your report output to the Paper Design view or Previewer, you should note that some or all of the report triggers may be fired before you see the report output. For example, suppose that you use SRW.MESSAGE to issue a message in the Between Pages trigger when a condition is met. If there are forward
references in the report (for example, a total number of pages displayed before the last page), Oracle Reports may have to format ahead to compute the forward references. Hence, even though you have not yet seen a page, it may already have been formatted and the trigger fired.
b. In report triggers, you can use the values of report-level columns and parameters. For example, you might need to use the value of a parameter called COUNT1 in a condition (for example, IF :COUNT1 = 10). Note, though, that you cannot reference any page-dependent columns (that is, a column with a Reset At property set to Page) or columns that rely on page-dependent columns.
c.In the Before and After Parameter Form, and Before and After Report triggers, you can set the values of parameters (for example, give them a value in an assignment statement, :COUNT1 = 15). In the Before and After Report triggers, you can also set the values of report-level, placeholder columns.
d.In the Between Pages trigger, you cannot set the values of any data model objects. Note also that the use of PL/SQL global variables to indirectly set the values of columns or parameters is not recommended. If you do this, you may get unpredictable results.
e.A lexical reference cannot be used to create additional bind variables after the After Parameter Form trigger fires. For example, suppose you have a query like the following (note that the WHERE clause is replaced by a lexical reference): SELECT ENAME, SAL FROM EMP &WHERE_CLAUSE
If the value of the WHERE_CLAUSE parameter contains a reference to a bind variable, you must specify the value in the After Parameter Form trigger or earlier. You would get an error if you supplied the following value for the parameter in the Before Report trigger. If you supplied this same value in the After Parameter Form trigger, the report would run. WHERE SAL = :new_bind
Format triggers
A format trigger is a PL/SQL function executed before an object is formatted. A trigger can be used to dynamically change the formatting attributes of the object. For example, you can use a format trigger to cause a value to display in bold if it is less than zero. Another example is to use a format trigger to use scientific notation for a
field if its value is greater than 1,000,000.
A format trigger can fire multiple times for a given object, whenever Reports Builder attempts to format the object. Consider the case where Reports Builder starts to format the object at the bottom of a page. If the object does not fit on the page, Reports Builder stops formatting and reformats on the following page. In this case, the format trigger will fire twice. It is therefore not advisable to do any kind of "persistence" operation,
such as logging, in this trigger.
The Reports Builder SRW built-in package contains PL/SQL procedures with which you can quickly change the format attributes of an object. These include procedures to:
• change the border pattern and color of an object
• change the interior pattern and color of an object
• change the font size, style, weight, spacing, and justification of a field or boilerplate text
• change the format mask of a field
• access a field's value
Validation triggers are PL/SQL functions that are executed when parameter values are specified on the command line and when you accept the Runtime Parameter Form.
Validation triggers are also used to validate the Initial Value property of the parameter Depending on whether the function returns TRUE or FALSE, the user is returned to the Runtime Parameter Form.
Database triggers
Database triggers are procedures that are stored in the database and implicitly executed when a triggering statement such as INSERT, UPDATE, or DELETE is issued against the associated table. Triggers can be defined only on tables, not on views.
However, triggers on the base table of a view are fired if an INSERT, UPDATE, or DELETE statement is issued against a view. A trigger can include SQL and PL/SQL statements that execute as a unit, and can invoke other stored procedures. Use triggers only when necessary. Excessive use of triggers can result in cascading or recursive triggers. For example, when a trigger is fired, a SQL statement in the trigger body potentially can fire other triggers. By using database triggers, you can enforce complex business rules and ensure that all applications behave in a uniform manner. Use the following guidelines when creating triggers:
Use triggers to guarantee that when a specific operation is performed, related actions are performed.
■ Use database triggers only for centralized, global operations that should be fired for the triggering
statement, regardless of which user or database application issues the statement.
■ Do not define triggers that duplicate the functionality already built into Oracle. For example, do not
define triggers to enforce data integrity rules that can be easily enforced using declarative integrity
constraints.
■ Limit the size of triggers (60 lines or fewer is a good guideline). If the logic for your trigger requires
much more than 60 lines of PL/SQL code, it is better to include most of the code in a stored procedure,
and call the procedure from the trigger.
■ Be careful not to create recursive triggers. For example, creating an AFTER UPDATE statement trigger on
the EMP table that itself issues an UPDATE statement on EMP causes the trigger to fire recursively until it
has run out of memory
FORMULA COLUMN VS PLACE HOLDER COLUMN
FORMULA COLUMN
A formula column performs a user-defined computation on the data of one or more column(s), including placeholder columns. For example, :ITEMTOT *.07 is a formula that performs a computation on one column, while :SAL + :COMM performs a computation using two columns in a record. You create formulas in PL/SQL using the PL/SQL Editor.
Note: Formula columns should not be used to set values for parameters.
PLACE HOLDER COLUMN
A placeholder is a column for which you set the datatype and value in PL/SQL that you define. Placeholder columns are useful when you want to selectively set the value of a column (for example, each time the nth record is fetched, or each time a record containing a specific value is fetched, and so on). You can set the value of a placeholder column in the following places:
• The Before Report trigger, if the placeholder is a report-level column
• A report-level formula column, if the placeholder is a report-level column
• A formula in the placeholder's group or a group below it (the value is set once for each record of the group)
ANCHOR
Anchors fasten an edge of one object to an edge of another object, ensuring that they maintain their relative
positions. For example, you can anchor boilerplate text to the edge of a variable-sized repeating frame,
guaranteeing the boilerplate's distance and position in relation to the repeating frame, no matter how the frame's
size might change.
Anchors determine the vertical and horizontal positioning of a child object relative to its parent. The child object may be either outside of or contained within the parent. Since the size of some layout objects may change when the report runs (and data is actually fetched), you need anchors to define where you want objects to appear relative to one another. An anchor defines the relative position of an object to the object to which it is anchored. Positioning is based on the size of the objects after the data has been fetched rather than on their size in the editor. It should also be noted that the position of the object in the Paper Layout view affects the final position in the report output. Any physical offset in the layout is incorporated into the percentage position
specified in the Anchor properties.
There are two types of anchors:
■ Implicit anchors. At runtime, Reports Builder generates an implicit anchor for each layout object that does not already have an explicit anchor. It determines for each layout object which objects, if any, can overwrite it, then creates an anchor from the layout object to the closest object that can overwrite it. This prevents the object from being overwritten. The implicit anchor functionality saves you from having to define the positioning of each object. Implicit anchors are not visible in the Paper Layout view. However, you can specify in the Object Navigator Options dialog box that the Object Navigator display anchoring information. By default, objects are anchored to the upper left corner of their enclosing object. If this view of the Object Navigator does not show anchoring information for an object, you can assume that the object is anchored to its enclosing object, which might be the frame or the body.
■ Explicit anchors. You can create an anchor in the Layout editor using the Anchor tool, dragging from one edge of the child to the one of the parent's edges. Any anchor you create for an object will override its implicit anchoring. Explicit anchors are always visible in the Paper Layout view unless you specify otherwise in the Layout Options dialog box.
FLEX MODE , CONFINE MODE
To set or override Confine mode:
In the Paper Layout view, click the Confine On button or the Confine Off button in the toolbar to toggle the mode:
On: child objects cannot be moved outside their enclosing parent objects.
Off: child objects can be moved outside their enclosing parent objects.
To set or override Flex mode:
In the Paper Layout view, click the Flex On button or the Flex Off button in the toolbar to toggle the mode:
On: parent borders "stretch" when child objects are moved against them. The child object maintains the same
distance from the side it moves against.
Off: parent borders remain fixed when child objects are moved against them.
HOW MANY LAYOUT IN MATIX REPORT AND MATRIX WITH GROUP?
A matrix layout model must consist of the following layout objects:
• At least three repeating frames: one with the Print Direction property set to Down, one with the Print Direction property set to Across, and one for the cell in the matrix object.
• Several group, header, and footer (if summaries are included) frame.
• A matrix object created for the cross product group, inside of which are the cells of the matrix (for example, the rectangle in the figure above with F_SUMSAL inside it).
Boilerplate for each column and row of values, as well as for summaries (for example, Job and Deptno). Displaying the boilerplate is optional, but Reports Builder will generate it by default.
LEXICAL PARAMETER USE? WHERE WE USE?
Lexical references
Lexical references are placeholders for columns or parameters that you embed in a SELECT statement. You can use lexical references to replace the clauses appearing after SELECT, FROM, WHERE, GROUP BY, ORDER BY, HAVING, CONNECT BY, and START WITH. Use a lexical reference when you want the parameter to substitute multiple
values at runtime.
You cannot make lexical references in a PL/SQL statement. You can, however, use a bind reference in PL/SQL to set the value of a parameter that is then referenced lexically in SQL, as shown in the example below.
You create a lexical reference by typing an ampersand (&) followed immediately by the column or parameter name. A default definition is not provided for lexical references. Therefore, you must do the following:
• Before you create your query, define a column or parameter in the data model for each lexical reference in the query. For columns, you must set the Value if Null property, and, for parameters, you must set the Initial Value property. Reports Builder uses these values to validate a query with a lexical reference.
• Create your query containing lexical references.
Examples
Example 1: SELECT clause
SELECT &P_ENAME NAME, &P_EMPNO ENO, &P_JOB ROLE FROM EMP;
P_ENAME, P_EMPNO, and P_JOB can be used to change the columns selected at runtime. For example, you could enter DEPTNO as the value for P_EMPNO on the Runtime Parameter Form. Note that in this case, you should use aliases for your columns. Otherwise, if you change the columns selected at runtime, the column names in the SELECT list will not match the Reports Builder columns and the report will not run.
Example 2: FROM clause
SELECT ORDID, TOTAL FROM &ATABLE;
ATABLE can be used to change the table from which columns are selected at runtime. For example, you could enter ORD for ATABLE at runtime. If you dynamically change the table name in this way, you may also want to use lexical references for the SELECT clause (look at the previous example) in case the column names differ between tables.
Example 3: WHERE clause
SELECT ORDID, TOTAL FROM ORD WHERE &CUST;
CUST can be used to restrict records retrieved from ORD. Any form of the WHERE clause can be specified at runtime.
Example 4: GROUP BY clause
SELECT NVL(COMMPLAN, DFLTCOMM) CPLAN, SUM(TOTAL) TOTAL FROM ORD GROUP BY &NEWCOMM;
The value of NEWCOMM can be used to define the GROUP BY clause.
Example 5: HAVING clause
SELECT CUSTID, SUM(TOTAL) TOTAL FROM ORD GROUP BY CUSTID HAVING &MINTOTAL;
The value of MINTOTAL could, for example, be used to select customers with a minimum total of orders.
Example 6: ORDER BY clause
SELECT ORDID, SHIPDATE, ORDERDATE, TOTAL FROM ORD ORDER BY &SORT;
The value of SORT can be used to select SHIPDATE, ORDERDATE, ORDID, or any combination as the sort criterion. It could also be used to add on to the query, for example to add a CONNECT BY and START WITH clause.
Example 7: CONNECT BY and START WITH clauses
Parameters in CONNECT BY and START WITH clauses are used in the same way as they are in the WHERE and HAVING clauses.
Example 8: Multiple clauses
SELECT &COLSTABLE;
COLSTABLE could be used to change both the SELECT and FROM clauses at runtime. For example, you could enter DNAME ENAME, LOC SAL FROM DEPT for COLSTABLE at runtime.
SELECT * FROM EMP &WHEREORD;
WHEREORD could be used to change both the WHERE and ORDER BY clauses at runtime. For example, you could enter WHERE SAL > 1000 ORDER BY DEPTNO for &WHEREORD at runtime.
Example 9: PL/SQL and SQL
SELECT &BREAK_COL C1, MAX(SAL) FROM EMP GROUP BY &BREAK_COL;
BREAK_COL is used to change both the SELECT list and the GROUP BY clause at runtime. The Initial Value of the parameter &BREAK_COL is JOB. At runtime, the user of the report can provide a value for a parameter called GROUP_BY_COLUMN (of data type Character).
In the Validation Trigger for GROUP_BY_COLUMN, you call the following PL/SQL procedure and pass it the value of GROUP_BY_COLUMN:
procedure conv_param (in_var IN char) is
begin
if upper(in_var) in ('DEPTNO','EMPNO','HIREDATE') then
:break_col := 'to_char('||in_var||')' ;
else
:break_col := in_var;
end if;
end;
This PL/SQL ensures that, if necessary, a TO_CHAR is placed around the break column the user chooses. Notice how in SQL, you make a lexical reference to BREAK_COL. In PL/SQL, you must make a bind reference to BREAK_COL because lexical references are not allowed in PL/SQL.
LEXICAL PARAMETER VS BIND PARAMETER VS USER DEFINE PARAMETER
2.3.4.3 Differences between bind and lexical references
Bind references are used to replace a single value in SQL or PL/SQL. Specifically, bind references may be used to replace expressions in SELECT, WHERE, GROUP BY, ORDER BY, HAVING, CONNECT BY, and START WITH clauses of queries. Bind references may not be referenced in the FROM clause. An example is:
SELECT ORDID,TOTAL FROM ORD WHERE CUSTID = :CUST
Lexical references are placeholders for text that you embed in a SELECT statement, when you want the parameter to substitute multiple values at runtime. You can use lexical references to replace the clauses appearing after
SELECT, FROM, WHERE, GROUP BY, ORDER BY, HAVING, CONNECT BY, and START WITH. You cannot make lexical
references in PL/SQL. Before you reference a lexical parameter for a column or table, you must have predefined the parameter and given it an initial value. An example is:
SELECT ORDID, TOTAL FROM &ATABLE
SRW.DO_SQL & SRW.DO_SQL_FAILURE
SRW.DO_SQ
If you want to use Data Manipulation Language (DML) or Data Definition Language (DDL) in your PL/SQL, you can use the SRW.DO_SQL built-in procedure. Note that SRW.DO_SQL should only be used for DML and DDL; you should not use it to fetch Data
Description This procedure executes the specified SQL statement from within Report Builder. The SQL statement can be DDL (statements that define data), or DML (statements that manipulate data). DML statements are usually faster when they are in PL/SQL, instead of in SRW.DO_SQL.
Since you cannot perform DDL statements in PL/SQL, the SRW.DO_SQL packaged procedure is especially useful for performing them within Report Builder, instead of via a user exit. For more information on DDL or DML statements.
SRW.DO_SQL (sql_statement CHAR);
Parameters
sql_statement Is any valid SQL statement. Remember to precede any Report Builder object names with a colon(:).
DECLARE
PAGE_NO NUMBER;
PAGE_FOR INDEX NUMBER;
SORT_CHAR CHAR(1);
CMD_LINE CHAR(200);
BEGIN
SORT_CHAR := :SORT_NAME ;
IF :CALLED = 'Y' THEN
SRW.GET_PAGE_NUM(PAGE_FOR_INDEX);
SRW.USER_EXIT('RWECOP PAGE_FOR_INDEX
P_START_PAGENO');
SRW.MESSAGE(2,TO_CHAR(:P_START_PAGENO));
END IF;
SRW.GET_PAGE_NUM(PAGE_NO);
CMD_LINE := 'INSERT INTO SHIP VALUES
('''||SORT_CHAR||''','||TO_CHAR(PAGE_NO)||')';
SRW.MESSAGE(2,CMD_LINE);
SRW.DO_SQL(CMD_LINE);
COMMIT;
EXCEPTION
WHEN DUP_VAL_ON_INDEX THEN
NULL;
WHEN SRW.DO_SQL_FAILURE THEN
SRW.MESSAGE(1,'FAILED TO INSERT ROW INTO SHIP
TABLE');
WHEN OTHERS THEN
COMMIT;
END;
SRW.DO_SQL_FAILURE
Description This exception stops the report execution and raises the following error message:
REP-1425: Error running DO_SQL package - REP-msg ORA-msg
where:
REP-msg Is a Report Builder message.
ORA-msg Is an optional ORACLE message, providing more information on the Report Builder message.
Syntax
SRW.DO_SQL_FAILURE;
Usage Notes Report Builder raises this exception when the SRW.DO_SQL packaged procedure fails (e.g., if the user does not have DDL privileges, yet tries to create a table with SRW.DO_SQL).
/* Suppose you want your own error message raised, instead of the default error message. ** You could handle this exception in the following way: */
EXCEPTION
when SRW.DO_SQL_FAILURE then
srw.message(1000, 'Error occurred while creating
table CHECKS.');
SRW.GET_PAGE_NUM
Description This procedure returns the current page number. This is useful when you want to use the page number in the field's Format Trigger property.
Syntax
SRW.GET_PAGE_NUM (page_num);
Parameters
page_num Is the variable in which you want to place the current page number.
Returns The current page number.
/* Suppose you want to perform a computation based upon a page number. ** In the field's Format Trigger, you could use SRW.GET_PAGE_NUM function: */
BEGIN
DECLARE PAGE_NUM NUMBER;
begin
srw.get_page_num (page_num);
srw.set_field_num (0, page_num + 3);
end;
END;
SRW.SET_FORMAT_MASK
Description This procedure specifies the format mask for the DATE or NUMBER field.
Syntax
SRW.SET_FORMAT_MASK('mask');
Parameters
mask Is a valid format mask.
SRW.RUN_REPORT
Description This procedure invokes RWRUN60 with the string that you specify. This procedure is useful for:
• running drill-down reports (i.e., calling a report from a button's action trigger)
• sending parts of a report to different recipients (e.g., to send a report via e-mail to each manager with just
his or her group's data)
• sending parts of a report to different printers (e.g., to send each manager's report to his or her printer)
• running multiple reports from a single "driver" report
SRW.RUN_REPORT executes the specified RWRUN60 command.
Syntax
SRW.RUN_REPORT (command_line CHAR);
Parameters
command_line Is a valid RWRUN60 command.
FUNCTION FOO RETURN BOOLEAN IS
BEGIN
srw.run_report('report=MAIL_IT
desname='||:ename ||' desformat=dflt batch=yes
mgr_no='|| TO_CHAR(:empno) );
RETURN (TRUE);
EXCEPTION
when srw.run_report_failure then
srw.message(30, 'Error mailing reports.');
raise srw.program_abort;
END;
SRW.TRUNCATED_VALUE
Description This exception will stop the report execution and raise one of two error messages. If the error resulted from a PL/SQL assignment, this message will be displayed:
REP-1435: Value of column
If the error resulted from a user exit IAF PUT, this message will be displayed:
REP-1416: User exit
If the SRW.TRUNCATED_VALUE exception is handled, the value will be truncated and remain assigned to the parameter or column.
Syntax
SRW.TRUNCATED_VALUE;
Usage Notes This exception is raised when a user exit or PL/SQL construct attempts to assign a value to a parameter or column which is larger than the object's maximum width.
/* Suppose you want your own error message raised, instead of the default error message (above). You could handle this exception in the following way: */
EXCEPTION
when SRW.TRUNCATED_VALUE then
srw.message(2000, 'Contact Dan Brown:
SRW.TRUNCATED_VALUE.');
VERTICAL ELASTICITY AND HORIZONTAL ELASTICITY
Description The Vertical Elasticity property is how the vertical size of the object may change at runtime to accommodate the objects or data within it:
• For frames and repeating frames, elasticity defines whether the size of the frame or repeating frame should vary with the objects inside of it.
• For objects containing text, elasticity defines whether the field or boilerplate should vary with the size of the text. Fixed size text will wrap within the defined size of the object and may be truncated if there is not enough room. Number or date data will appear as asterisks if the data cannot fit within the defined size.
• For images, drawings, and chart objects, Report Builder uses proportional scaling. The elasticity options for i
Values
Contract Means the vertical size of the object decreases, if the formatted objects or data within it are short enough, but it cannot increase to a height greater than that shown in the Report Editor. Truncation of data may occur; look at the examples. (You can think of this option as meaning "only contract, do not expand.")
Expand Means the vertical size of the object increases, if the formatted objects or data within it are tall enough, but it cannot decrease to a height less than that shown in the Report Editor. (You can think of this option as meaning "only expand, do not contract.")
Fixed Means the height of the object is the same on each logical page, regardless of the size of the objects or data within it. Truncation of data may occur; look at the examples. The height of the object is defined to be its height in the .
Variable Means the object may expand or contract vertically to accommodate the objects or data within it (with no extra space), which means the height shown in the Report Editor has no effect on the object's height at runtime.
Description The Horizontal Elasticity property is how the horizontal size of the object will change at runtime to accommodate the objects or data within it:
• For frames and repeating frames, elasticity defines whether the size of the frame or repeating frame should vary with the objects inside of it.
• For objects containing text, elasticity defines whether the field or boilerplate should vary with the size of the text. Fixed size text will wrap within the defined size of the object and may be truncated if there is not enough room. Number or date data will appear as asterisks if the data cannot fit within the defined size.
• For images, drawings, and chart objects, Report Builder uses proportional scaling. The elasticity options for images, drawings, and chart objects determine the scaling factor.
Values
Contract Means the horizontal size of the object decreases, if the formatted objects or data within it are
wide enough, but it cannot increase to a width greater than that shown in the Report Editor. Truncation of data may occur; look at the examples. (You can think of this option as meaning "only contract, do not expand.")
Expand Means the horizontal size of the object increases, if the formatted objects or data within it are wide enough, but it cannot decrease to a width less than that shown in the Report Editor. (You can think of this option as meaning "only expand, do not contract.")
Fixed Means the width of the object is the same on each logical page, regardless of the size of the
objects or data within it. Truncation of data may occur; look at the examples. The width of the object is defined to be its width in the Report Editor.
Variable Means the object may expand or contract horizontally to accommodate the objects or data within
it (with no extra space), which means the width shown in the Report Editor has no effect on the object's width at runtime.
Usage Notes
If you create a Graphics object in your report with a Vertical and Horizontal Elasticity of Fixed, Report Builder scales the display to fit within the dimensions you defined for the object.
FILTER (FIRST,LAST AND PL SQL)
Description Filter Type specifies the type of filter Report Builder should use on the records being fetched for the group.
Values
None Means that you are not using a filter for the group.
First Means that the first n records retrieved should be included in the group, where n is a number specified in the Number of Records property.
Last Means that the last n records retrieved should be included in the group, where n is a number specified in the Number of Records property.
PL/SQL Means that a PL/SQL function for determining which records to include in the group will be defined (or referenced).
Filter Type example
Suppose that you have a group named EMP that contains two columns (ENAME and SAL). The parent group of EMP is DEPT, which contains one column (DEPTNO). You specify a Filter Type of First and Number of Records of 3 for DEPT and a Filter Type of First and Number of Records of 5 for EMP. This will return the first three department numbers retrieved by Report Builder with the first five names and salaries retrieved for each department.
HOW TO DEBUGGING IN REPORTS?
