Showing posts with label SRW Package. Show all posts
Showing posts with label SRW Package. Show all posts

SRW.SET_attributes


Description The SRW.SET_<attributes> procedures are used to set the format attributes. Mainly used to make some change in the appearance of the layout objects.

          
Format attributes
Value
Text Color
Red
Font Face
Impact
Font Weight
Bold
Font Style
Italic
Font Pattern
Solid diamond

Example
Function age_mask return Boolean is
Begin
If :age < 25 then
Srw.set_text_color(‘Red’);
Srw.set_font_face(‘Impact’) ;
Srw.set_font_weight(srw.bold_weight) ;
Srw.set_font_style(srw.italic_style);
Srw.set_fill_pattern(‘solid diamond’);
End if;
End;

SRW.SET_MAXROW


Description  This procedure sets the maximum number of records to be fetched for the specified query.  This is useful when your report formats (i.e., displays) fewer records than the query (or queries) that fetch them.  Thus, with SRW.SET_MAXROW, you can conditionally restrict data that is fetched for your report, enabling you to improve the report's performance.

Syntax
SRW.SET_MAXROW (query_name CHAR, maxnum PLS_INTEGER);

Parameters
query_name   Is the query whose fetched records will be limited.
maxnum         Is maximum number of records you want the query to fetch.

Property Palette  To define this attribute using the Property Palette, set the Maximum Rows to Fetch property.

Restrictions
·         SRW.SET_MAXROW is only meaningful in a Before Report trigger (i.e., after the query is parsed).  If SRW.SET_MAXROW is called after the Before Report trigger (i.e., after the queries have been executed), the SRW.MAXROW_UNSET packaged exception is raised.
·         Because this procedure causes only the specified number of records to be fetched, the "unfetched" records of the query are not used in computations, etc.
·         If you specify that 0 records should be fetched, the query will still be parsed.


Example
/* Suppose your report has two queries, Q_Stocks and Q_Bonds.  
** Suppose also, that you have a user-created parameter, named 
** WHICHDATA, that enables users to specify which data they want 
** the report to display:  either stocks or bonds.  In the 
** Before Report trigger, you could use the SRW.SET_MAXROW 
** procedure to ensure that only one query's data is fetched: 
*/

FUNCTION FETCHIT RETURN BOOLEAN IS
BEGIN
   if :whichdata != 1 then
     srw.set_maxrow ('Q_Stocks', 0);
   else
     srw.set_maxrow ('Q_Bonds', 0);
   end if;
RETURN (TRUE);
END;

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.

Restrictions
·         If you want parameter values that are entered on the Runtime Parameter Form to be passed in the RWRUN60 string, you must call SRW.RUN_REPORT after the before form trigger.
·         The string that is specified for or passed to this procedure must follow the syntax and case-sensitivity rules for your operating system.

·         No userid should be specified for the SRW.RUN_REPORT procedure.  The userid is inherited by the "calling" report.

·         If the parent report that invokes SRW.RUN_REPORT is run in batch, then DESTYPE can only be File, Printer, Sysout, or Mail.  Otherwise, DESTYPE can be File, Printer, or Mail.
·        
     If SRW.RUN_REPORT is used in the PL/SQL for a button, the Runtime Parameter Form will not appear by default when the button is selected.  If you want the Runtime Parameter Form to appear, you must specify PARAMFORM=YES in the call to SRW.RUN_REPORT.

·         If you do not specify a path, Report Builder will use its file path search order to find the report.

Example
/* Suppose you have the following two reports: MGR_RUN, which queries manager names, and invokes a second report named MAIL_IT. MAIL_IT, which queries employee names for the manager that MGR_RUN passes it,  and sends the report output to the manager via e-mail. The description of MGR_RUN could be as follows:
** Query: SELECT ENAME, EMPNO FROM EMP WHERE JOB='MANAGER'
** Group Filter:
*/
    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;
 
/* This PL/SQL invokes MAIL_IT, specifies that MAIL_IT's output 
** should be sent to the manager via Oracle Mail, and passes the 
** manager number, so that the MAIL_IT report can query only the 
** manager's employees.
** Note: EMPNO's values must be converted to characters 
** (TO_CHAR in the PL/SQL above), because SRW.RUN_REPORT 
** requires a character string.
** Layout: None is needed, because this report only fetches data, 
** then passes it to a second report.
** The description of MAIL_IT could be as follows:
** Query: SELECT DEPTNO, ENAME, SAL FROM EMP WHERE MGR=:MGR_NO
** Layout: Master/Detail
*/

/* Suppose that you have three reports that you almost always run together.
** The reports are named SALARY, COMMISS, and TAXES.  To run these reports 
** with one RWRUN60 command, you create a driver report named PAYROLL. 
** The description of PAYROLL could be as follows:
** Query: SELECT DEPTNO FROM DEPT
** Before Report Trigger:
*/


   FUNCTION FOO RETURN BOOLEAN IS
   BEGIN
     srw.run_report('batch=yes report=SALARY
      destype=file desformat=dflt desname=salary.lis');
     srw.run_report('batch=yes report=COMMISS
      destype=file desformat=dflt desname=comiss.lis');
     srw.run_report('batch=yes report=TAXES
      destype=file desformat=dflt desname=comiss.lis');
   RETURN (TRUE);
   END; 


/* Layout:  Tabular
** When you run PAYROLL from the designer or RWRUN60, the other three
** reports will all be run.  (Note that, in this case, the query and 
** the layout for Payroll could be anything.  They are only used here 
** in order to make it possible to run PAYROLL.)
*/

SRW.USER_EXIT



Description  This procedure calls the user exit named in user_exit_string.  It is useful when you want to pass control to a 3GL program during a report's execution.

Syntax           SRW.USER_EXIT (user_exit_string CHAR);

Parameters
user_exit_string        Is the name of the user exit you want to call and any columns or parameters that you want to pass to the user exit program.

Restrictions
User exits are not portable.  If your report must be portable, and you need to add conditional logic to it, use PL/SQL.

If the user exit string passes a column or parameter to the user exit program, SRW.REFERENCE 
must be called before this procedure.

Example
/* Suppose you have a user exit named STORE to which you want ** to pass salary values from Report Builder.  To do so, you ** could write the following formula.  For more information on ** how to call user exits, see Calling a user exit. */
FUNCTION FOO RETURN BOOLEAN IS
BEGIN
IF :SAL >= 0 THEN
   SRW.REFERENCE(:SAL);
   SRW.USER_EXIT('STORE SAL');
ELSE
   SRW.MESSAGE(100, 'FOUND A NEGATIVE SALARY. CHECK THE
          EMP TABLE.');
END IF;
EXCEPTION
    WHEN SRW.UNKNOWN_USER_EXIT THEN
         SRW.MESSAGE(200, 'STORE USER EXIT WAS UNKNOWN.
                     CHECK IF IT''S LINKED.');
    WHEN SRW.USER_EXIT_FAILURE THEN
         SRW.MESSAGE(200, 'STORE USER EXIT FAILED.
                     CHECK ITS CODE.');
RETURN(TRUE);
END;

SRW.REFERENCE


Description  This procedure causes Report Builder to add the referenced object to the PL/SQL construct's dependency list.  This causes Report Builder to determine the object's value just before firing the PL/SQL construct.  This is useful when you want to ensure that a column value 
passed to a user exit is the most recently computed or fetched value.

Syntax           SRW.REFERENCE (:object CHAR|DATE|NUMBER);

Parameters
object Is the Report Builder parameter or column whose value needs to be ascertained before the 
construct fires.

Restrictions
The colon is required before the object name.
SRW.REFERENCE is unnecessary when the object is already referenced in the current PL/SQL construct.

Example
/* Suppose you want to pass the temperature and pressure values ** to a user exit called SUPERHEAT.  Suppose, also, that if the ** temperature is too low, you want to raise a customized error message.  ** To do so, you could write the following formula:*/
FUNCTION EXIT RETURN BOOLEAN IS
BEGIN
  if :temp > 0 then
     srw.reference (:temp); -- unnecessary reference
     srw.reference (:pressure);
     srw.user_exit('superheat temp pressure');
  else srw.message(1000, 'Temperature is below
     normal. Is machine off?');
     raise srw.program_abort;
  end if;
RETURN(TRUE);
END;

SRW.PROGRAM_ABORT


Description  This exception stops the report execution and raises the following error message:
REP-1419: PL/SQL program aborted.

SRW.PROGRAM_ABORT stops report execution when you raise it.

Syntax           SRW.PROGRAM_ABORT;

Usage Notes  You must raise the exception from within your PL/SQL.

Example
/* Suppose you want to put a border around the salary if it is greater than 0.  
** Suppose, also, that if the report fetches a salary less than 0, you want to 
** raise a customized error message (i.e., "FOUND A NEGATIVE SALARY. . ."), 
** then terminate the report execution.  To do so, you could write the 
** following format trigger for F_SAL.
*/

FUNCTION foo return boolean is
BEGIN
if :sal >= 0 then
   srw.attr.mask         := SRW.BORDERWIDTH_ATTR;
   srw.attr.borderwidth  := 1;
   srw.set_attr (0, srw.attr);
else
   srw.message(100, 'FOUND A NEGATIVE SALARY.
   CHECK THE EMP TABLE.');
   raise srw.program_abort;
end if;
RETURN (TRUE);
END;

SRW.MESSAGE


Description  This procedure displays a message with the message number and text that you specify.  The message is displayed in the format below.  After the message is raised and you accept it, the report execution will continue.
MSG-msg_number:  msg_text.

Syntax
SRW.MESSAGE (msg_number NUMBER, msg_text CHAR);

Parameters
msg_number   Is a number from one to ten digits, to be displayed on the message line.  Numbers less than five digits will be padded with zeros out to five digits.  For example, if you specify 123, it will be displayed as SRW-00123.

msg_text       Is at most 190 minus the msg_number alphanumeric characters to be displayed on the message line.

Restrictions
·         You cannot trap nor change Report Builder error messages.
·         SRW.MESSAGE does not terminate the report execution; if you want to terminate a report after raising a message, use SRW.PROGRAM_ABORT.
·         Any extra spaces in the message string will be displayed in the message; extra spaces are not removed by Report Builder.

Example
/* Suppose you have a user exit named MYEXIT to which you want to 
** pass the values of the SAL column.  Suppose, also, that you want
** to raise your own error if the user exit is not found (e.g., because 
** it is not linked, compiled, etc.).  To do these things, you could 
** write the following PL/SQL in the Format Trigger of the F_SAL field:
*/

/* This trigger will raise your message as follows: 
** MSG-1000: User exit MYEXIT failed. Call Karen Smith x3455.
*/

FUNCTION FOO RETURN BOOLEAN IS
BEGIN
    srw.reference(:SAL);
    srw.user_exit('myexit sal');
EXCEPTION
    when srw.unknown_user_exit then
    srw.message(1000, 'User exit MYEXIT failed.
 Call Karen Smith x3455.');
    raise srw.program_abort;
RETURN (TRUE);
END;

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.

Restrictions
SRW.GET_PAGE_NUM is only meaningful in a format trigger.  It has no effect when entered in other places.


Example
/* 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.GETERR_RUN


Description  This function returns an error message if Report Builder detects an error while running the SRW.RUN_REPORT procedure.
Syntax           SRW.GETERR_RUN;
Returns  An error message.

Example
/* Suppose you are sending parts of a report to users via Oracle*Mail.  ** For more information, see "SRW.RUN_REPORT".   Also, ** suppose that if SRW.RUN_REPORT fails, you want to display a message ** that explains why it failed.  Your PL/SQL could look like this:*/
BEGIN
DECLARE TMP CHAR(100);
  begin
     srw.run_report('batch=yes report=send.rdf
     destype=file desname=send.lis desformat=dflt');
  exception when srw.run_report_failure then
     tmp := srw.geterr_run;
     srw.message(1000, tmp);
  end;
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).

Example
/* 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.DO_SQL


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, see the ORACLE8 Server SQL Language Reference Manual. 

Syntax           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 (:).

Restrictions
·         In Report trigger order of execution, notice where the SET TRANSACTION READONLY occurs.

·         A bind variable's value can be at most 64,000 bytes.  (When the value exceeds that limit, it will be truncated to the left-most 64,000 bytes.)

·         If you use a parameter as the destination of a character column for an INTO clause, you should ensure that the parameter is wide enough to contain the selected values.  For example, suppose that you have the SRW.DO_SQL statement below:  The destination parameter (my_ename) needs a width that is equal to the maximum width of the ENAME column.  The reason for this is that the selected value contains trailing spaces up to the assumed size of the value.  If the parameter is not large enough, you will get a truncation exception.  If you are not sure about the maximum width of the SELECT list item, then you should use 2000 as the width for the parameter.

srw.do_sql('SELECT ENAME INTO :my_ename FROM EMP');


Example
/* Suppose you want your report to create a table named CHECK ** just before the Runtime Parameter Form is displayed.  ** Because CREATE TABLE is a SQL DDL statement (and PL/SQL ** cannot perform DDL statements), you need to use SRW.DO_SQL.  ** Therefore, your PL/SQL could look like this in the Before Form trigger:*/
/* Additional Information: If you use a table created in this way for your** report output, the table must exist before you create your query in the ** data model.  Otherwise, Report Builder would not be able to parse your query.*/

FUNCTION CREATETAB RETURN BOOLEAN IS
BEGIN
SRW.DO_SQL('CREATE TABLE CHECK (EMPNO NUMBER NOT NULL
            PRIMARY KEY, SAL NUMBER (10,2)) PCTFREE 5
            PCTUSED 75');
RETURN(TRUE);
EXCEPTION
WHEN SRW.DO_SQL_FAILURE THEN
 SRW.MESSAGE(100, 'ERROR WHILE CREATING CHECK TABLE.');
 SRW.MESSAGE(50, 'REPORT WAS STOPPED BEFORE THE RUNTIME
 PARAMETER FORM.');
 RAISE SRW.PROGRAM_ABORT;
END; 



SRW.CONTEXT_FAILURE


Description  This exception stops the report execution and raises the following error message:
REP-1426: Running <construct_name> from incorrect context.

Syntax           SRW.CONTEXT_FAILURE;

Usage Notes  Report Builder raises this exception when a Report Builder packaged function or procedure is called in the wrong context (see the chart below).
In this chart, NO means that the function or procedure cannot be called in that context; YES means it can.

Name
Parameter Form
Data Model
Format Trigger
Report Trigger
srw.break
NO
YES
YES
NO
srw.do_sql
YES
YES
YES
YES
srw.geterr_run
YES
YES
YES
YES
srw.get_page_num
NO
NO
YES
NO
srw.message
YES
YES
YES
YES
srw.reference
YES
YES
YES
YES
srw.run_report
YES
YES
YES
YES
srw.set_attr
NO
NO
YES
NO
srw.set_field_char
NO
NO
YES
NO
srw.set_field_date
NO
NO
YES
NO
srw.set_field_num
NO
NO
YES
NO
srw.set_maxrow
NO
YES
YES
YES
srw.user_exit
YES
YES
YES
YES


Example

/* 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.CONTEXT_FAILURE then
  srw.message(4000, 'Contact the Application
    Development group regarding SRW.CONTEXT_FAILURE.');
  raise srw.program_abort;