Description of the Five triggers in reprot

Report trigger

1.1 which report trigger to use

As a general rule, any processing that will affect the data retrieved by the report shocould be stored med 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 stored med in the other triggers.

Translation:

Generally, any behavior that can affect the data extracted from the report must be executed in before parameter form and after parameter form triggers, (these two report triggers will be performed before any syntax analysis and data extraction .), Other actions that do not affect the data extracted from the report can be executed in other triggers.

1. Before Report: fires before the report is executed but after queries are parsed.

The before report trigger is triggered after the query statement is parsed and the report is executed.

2. after Report: fires after you exit the previewer, or after report output is sent to a specified destination, such as a file, a printer, or an oracle office userid. 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.

The after report trigger is executed after you exit the preview or the report is output to a specified user, such as a printer or Oracle office. This trigger can be used to clear any completed initialization behaviors, such as deleting a data table (usually a temporary table ). Note that this trigger will always be triggered no matter whether your report runs successfully or not.

3. between pages: fires before each page of the report is formatted, cannot the very first page. this trigger can be used for customized page formatting. in the previewer, 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

The between pages trigger will be triggered before each other page except the first page. This trigger can be used to customize the orchestration of the Report page. During preview, this trigger is only triggered when you go to a page. If you go back to the report page that has been previewed, the trigger will not be triggered. Before parameter form: 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

1. runtime parameter form is suppressed, this trigger still fires. Consequently, you can use this trigger for validation of command line parameters.

The before parameter form trigger is triggered before the runtime parameter form (runtime parameter input table box) is displayed. With this trigger, you can access and change the values of parameters, global variables, and report-level columns in PL/SQL. If the runtime parameter form is terminated, this trigger will still be triggered. Therefore, you can use it to verify the validity of command line parameters.

2. after parameter form: 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.

The After parameter form trigger is triggered after the runtime parameter form (runtime parameter input table box) is displayed. With this trigger, you can access and check the parameter values. When an error occurs, the trigger can change the parameter value and return it to the runtime parameter form. Columns in data model are invisible to this trigger,

If the runtime parameter form is terminated, this trigger will still be triggered. Therefore, you can use it to verify the validity of command line parameters.

1.2 report trigger order of execution (trigger execution sequence)

The order of events when a report is executed is as follows:

Before parameter form trigger is fired.

1. runtime parameter form appears (if not suppressed ).

2. After parameter form trigger is fired (unless the user cancels from the runtime parameter form ).

3. Report is "compiled ."

4. queries are parsed.

5. Before report trigger is fired.

6. Set transaction readonly is executed (if specified via the readonly argument or setting ).

7. the report is executed and the between pages trigger fires for each page should t the last one. (Note that data can be fetched at any time while the report is being formatted .) commits can occur during this time due to any of the following-user exit with DDL, SRW. do_ SQL with DDL, or if onfailure = commit, and the report fails.

8. Commit is executed (if readonly is specified) to end the transaction.

9. After report trigger is fired.

10. Commit/rollback/noaction is executed based on what was specified via the onsuccess argument or setting.

1.3 report trigger restrictions)

1. if you are sending your report output to the runtime previewer or live previewer, you shocould 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 (e.g ., A total number of pages displayed before the last page ),

Report builder 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.

For example, if the condition is met, you use SRW. Message to publish a message in between pages trigger. If a report contains variables referenced in advance (for example, a total number of pages is displayed before the last page), report builder calculates the variables referenced in advance. therefore, even if you do not see a report page, the report page is organized and triggers are triggered.

2. in report triggers, you can use the values of report-level (report level) columns and parameters. for example, you might need to use the value of a parameter called count1 in a condition (e.g ., if: count1 = 10 ). note, though, that you cannot reference any page-dependent columns (I. E ., A column with a reset at of page) or columns that rely on page-dependent columns.

Note that you cannot reference any page-level columns (for example, the columns set to reset at of page) or page-level columns.

3. in the before and after parameter form, and before and after report triggers, you can set the values of parameters (e.g ., give them a value in an assignment statement,: count1 = 15 ). in the before and after report triggers, you can set the values of report-level, placeholder columns.

In before and after report triggers, you can assign values to parameters and report-level ranking.

4. 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.

You cannot assign values to any data model object in between pages trigger. Likewise, it is not recommended to use PL/SQL global variables to indirectly assign values to columns or parameters. If you do that, you may have unexpected results.

If you run a report from report builder Runtime (I. e., not

1. command Line or SRW. run_report), You shocould commit database changes you make in the before parameter form, after parameter form, and validation triggers before the report runs. when running in this way, these triggers will share the parent process 'database connection. when the report is actually executed, however, it will establish its own database connection.

2. 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 wocould 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 wocould run.

Where sal =: new_bind

If the where expression references the bound variable, you must specify its value in the after parameter form trigger or earlier. If you assign the following value to the parameter in before report trigger, an error is returned.