Liren Large Software Subsidy 5

home *** CD-ROM | disk | FTP | other *** search

/ Liren Large Software Subsidy 5 / 05.iso / a / a525 / 16.ddi / README.TXT < prev

Wrap

Text File | 1993-02-03 | 31.0 KB | 709 lines

This is the SQL*Forms 3.0.16.11.3 release. (Linked with PL/SQL 1.0.35.1.0) This version was primarily created as a synchronized-release version, but also includes the bug fixes noted below in section "BUGS FIXED IN 3.0.16". Additionally, bugs 91978, 123888, 124022, 124749, 129519, 131235, 132999, 134900, 135121, 135239, 135983, 137235, 138310 have been fixed in this version of SQL*Forms. Bugs outstanding: 115687, 127098, 129342, 138247, 138491. +------------------------------------------------------+ | CAUTION: | | Installation of this patch on an OS/2 system with a | | local ORACLE database requires that the database | | and Required Support Files be updated to 6.0.36.1.0 | | BEFORE this patch can be applied! Failure to do so | | may result in making the RDBMS inoperable! | | | | Installation of this patch on a client-only system | | (no local database) requires that Required Support | | Files (16-bit) 6.0.36.1.0 be installed on the client | | system BEFORE this patch can be applied! | | +------------------------------------------------------+ Attached below is the standard README text file which discusses bug fixes and functionality changes. This text file is a cumulative file for all 3.0.16 versions of SQL*Forms. -------------------------------------------------------------------------------- Release Bulletin SQL*Forms Version 3.0.16 (Production) April 13, 1992 This bulletin contains important information about this release of SQL*Forms. It is recommended that you familiarize yourself with the contents of this bulletin before attempting to use this version. The bulletin includes function key mappings for this release for VT100 and VT220 terminals. New Features since Versions 2.0 and 2.3 ======================================= A complete list of new and changed features can be found in Appendix A of the SQL*Forms Designer's Reference Version 3.0. Major new features include: o Enhanced User Interface Portability o The SQL*Forms (Design) interface is completely revised and includes: o Streamlined Menu structure with pull-down menus o Ability to reference and copy application objects such as triggers o Ability to enforce referential integrity constraints o Context-sensitive online help o Enhanced Debug Mode o Integrated text editor o Automatic master-detail block coordination o PL/SQL Integration o Ability to integrate pull-down menus built with SQL*Menu o Enhanced SQL*Forms (Run Form) Capabilities: o Pop-up Pages, List-of-Values, and Field Editor o Format masks for formatting field contents o Dynamic field and display attributes o Mouse support for bitmap environments Documentation ============= Complete documentation is available with the release. All users are advised to obtain the most current documentation. The Version 3.0 documentation set includes: SQL*Forms Operator's Guide 3301-V3.0 SQL*Forms Operator's Quick Reference 3704-V3.0 SQL*Forms Designer's Tutorial 3302-V3.0 SQL*Forms Designer's Quick Reference 3708-V3.0 SQL*Forms Designer's Reference 3304-V3.0 | NEW! Advanced SQL*Forms Techniques 5763-V3.0 Introduction to SQL*Forms and SQL*Menu 19192-V3 NEW! Advanced SQL*Forms designers are encouraged to get the new Advanced SQL*Forms Techniques book, now available showing you how to implement specific SQL*Forms functionality in your applications. For information on mapping function keys and video attributes or customizing key mappings, consult the Oracle*Terminal User's Guide, part no. 5206-V1.0. For complete information on PL/SQL, refer to the PL/SQL User's Guide and Reference, part no. 800-V1.0. Keyboard cards are available for designers and operators: SQL*Forms Designer's Keyboard Card 755-V3.0 SQL*Forms Operator's Keyboard Card 3906-V3.0 Upgrading from Earlier Versions =============================== 1. All forms created prior to Version 3.0.15 must be regenerated to run with SQL*Forms Version 3.0.15. This was due to a PL/SQL problem that was fixed, that required regeneration on the SQL*Forms side. Now that version 3.0.16 is full production, we will strive to minimize future regeneration needs. 2. Forms created prior to SQL*Forms Version 3.0 must have their .INP files converted, using CONVFORM -vXX inp_filename formname username/password, where: XX is either 20 or 23, depending on if you are converting from Version 2.0 or 2.3 of SQL*Forms inp_filename is the name (without the .INP suffix) of the old INP file that you are converting to Version 3.0 - not the name of the new INP file that you want to create as stated on page 23-4 of the SQL*Forms Designer's Reference Version 3.0. This documentation bug has been fixed in the latest reprint of the document. Once the .INP files are converted to the Version 3.0 format, forms must be regenerated by using GENERATE inp_filename username/password. 3. When you use the CONVFORM utility to convert an INP file which you have been running under Version 2.0, Oracle Corporation recommends that you specify the -f switch in order to preserve the forms's functionality. The -f parameter inserts the NOFAIL key-word after #exemacro in all trigger steps. For more information on the NOFAIL key-word, refer to the SQL*Forms Documentation Addendum Version 2.3. If you decide to take advantage of Version 3.0's success/failure logic, you should not specify the -f switch. However, be advised that the resulting form's changed behavior might require you to perform additional modification and testing. Also, when converting directly from Version 2.0 to 3.0, you need to convert the CRT files in order for your forms to interpret box characters. This is not the case when going from Version 2.3 to 3.0. If you do not have CRT installed when you run the CONVFORM utility from Version 2.0 to 3.0 you either need to copy the necessary CRT files into the SQLFORMS30 directory, or you need to reassign the logicals ora_crt30 and ora_crtdef30 to point to the location of the CRT files. 4. For information on using Version 2 CRT files and key mappings with SQL*Forms 3.0, refer to the Key Mappings section below and the Oracle*Terminal Release Bulletin. 5. To aid in your migration from SQL*Forms 2.3 to SQL*Forms 3.0, some of the symbols used to invoke SQL*Forms 2.3 have been retained for SQL*Forms 3.0. These symbols are IAC, IAD, IAG, IAP, RUNFORM, SQLFORMS, CONVFORM, and GENERATE. While this prevents users from having to learn new ways to invoke SQL*Forms 3.0, it can cause problems for Oracle products which require SQL*Forms 2.3. These products include: CASE*Dictionary 4.1 CASE*Generator for SQL*Forms 1.0 CASE*Designer 1.1 SQL*Menu 4.1 Easy*SQL 2.3 SQL*Plus 3.0 SQL*TextRetrieval 1.1 Before using any of these products, the user must type: @ORA_SQLFORMS:SQLFORMSUSER It might be convenient to have your system manager define this command as a symbol. After using this command and before using SQL*Forms 3.0 or SQL*Menu 5.0, the user must type: @ORA_SQLFORMS30:SQLFORMS30USER Alternatively, if you specify a "30" at the end of the above symbols (e.g. sqlforms30), they will run SQL*Forms 3.0, while a "23" will invoke SQL*Forms 2.3 (e.g. sqlforms23). 6. In SQL*Forms Version 2.3, it was possible, though not recommended, to have a column defined as a CHAR in a database table and have the corresponding field defined as a NUMBER or a DATE within the SQL*Forms applications. In most cases, this was done to perform some type of formatting for the field. SQL*Forms Version 3.0 processes NUMBER and DATE fields as true NUMBER and DATE datatypes - not character strings. A form developed on Version 2.3 that used this convention will not behave the same in SQL*Forms 3.0. For example, leading zeroes would be truncated on a Zip Code field that was defined as CHAR in the database and NUMBER in the form. Format masks are an easier way to enforce changes in the display format of a field and to ensure that valid data gets entered. In previous versions of SQL*Forms, RMONEY fields would round fields when data retrieved had more than 2 decimal places. In SQL*Forms 3.0, an error message is issued that informs the user that too many decimal places have been entered (bug fix 31586). If rounding is desired, a format mask can be used to enforce rounding. This should be done on a field defined with a NUMBER datatype - not RMONEY. General Notes/Restrictions ========================== 1. All Oracle*Terminal key mappings are stored in ORA_ROOT:[SQLFORMS30]. Default mappings can be found in the ORATERM.R resource file, and should not be deleted nor moved from the [SQLFORMS30] directory. 2. On VMS systems, when SQL*Forms 3.0 is installed, the CONVFORM and CONVFORM30 symbols are created to invoke the SQL*Forms convert utility. Note that the SQL*Forms Designer's Reference only refers to CONVFORM and not CONVFORM30. 3. On page 23-4 of some versions of the SQL*Forms 3.0 Designer's Reference, in the section named 'INP to INP Conversion' the text and the example are wrong. The example should read: CONVFORM -v23 OLD OLD [username/password] where: the first 'OLD' is the name of the INP file that you want to convert (without the .INP suffix) - not the name of the INP file you want to create. the second 'OLD' is the name of the old form that you want to convert, not the name of the new form you want to create. These documentation bugs have been fixed in the latest reprints of the documentation. 4. When using SQL*Forms on the PC, a form is limited to 744 fields per form. Also on the PC, all form text, V2 trigger text, trigger procedures, and compiled PL/SQL code is now unlimited. 5. The DEMOBLD.COM file has been revised. In Version 3.0.15 and above, when demobld.com is executed, it will inform the user that certain demo tables will be dropped and then asks if the user wants to proceed (as opposed to not informing the user and just dropping the demo tables). PL/SQL Notes/Restrictions ========================= 1. PL/SQL CHECKS ~~~~~~~~~~~~ In the course of applications development using SQL*Forms and PL/SQL, infrequently an error message such as: PL/SQL Check 12345 -- Please inform your Oracle Representative may present itself at trigger/procedure-compilation time. In most cases these "Check" errors are the result of inadvertently using a PL/SQL object in an unexpected or unsupported manner, or even more often by an error in syntax which confuses the PL/SQL compiler. An example might be the (invalid) attempt to assign a value to a user-defined exception, or an (incorrect) attempt to RAISE a local PL/SQL variable. In nearly all cases, a systematic use of comments /* ... */ can quickly narrow down the problem to a particular statement in the PL/SQL block. This simpler case can then be examined more closely to see which syntactic or semantic error is causing the "Check" error. 2. INTERNAL SQL*FORMS CONSTANTS ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The arguments to many of the SQL*Forms packaged procedures and packaged functions occasionally cause confusion. One may wonder why sometimes values are enclosed in single quotes, while other values are simply given without quotes. An example of a packaged function that illustrates this point is: BLOCK_CHARACTERISTIC( 'blockname', FIRST_FIELD ) Or consider the packaged procedure: EXIT_FORM( ASK_COMMIT , NO_ROLLBACK ); These "special words" like ASK_COMMIT, NO_ROLLBACK, and FIRST_FIELD do not require quotes because they are actually PL/SQL numeric constants which are declared automatically by SQL*Forms at startup. Each one of these PL/SQL constants corresponds to a unique integer, whose *actual* numeric value is of no practical use to the Forms designer. With this in mind, it is easy to see how a Form-Level procedure could actually "receive" the value ASK_COMMIT in a *NUMBER* parameter. In fact some of the automatically-generated Master/Detail procedures DO use this technique. Currently there is no mechanism for designers to declare their own such numeric constants, so the internally declared ones are the only ones which exist in Forms 3.0. 3. DEFAULT PARAMETER VALUES FOR PL/SQL PROCEDURES ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When declaring a PL/SQL procedure, it is possible to assign default values to the formal parameters declared. The default value (either a constant or an expression) must, of course, correspond in datatype with the type declared for the formal parameter with which it is associated. For example, consider the procedure below: PROCEDURE fp_raise_sal ( pp_sal IN OUT NUMBER, pp_percent_raise IN NUMBER) IS BEGIN pp_sal := pp_sal * ( pp_percent_raise / 100 ); END; To raise the salary of the current employee in the EMP block by thirty (30) percent, we would then use the command: fp_raise_sal( :EMP.SAL , 30 ); However, if ten (10) percent was the default raise, we could build this fact into the procedure itself by giving the PL/SQL parameter 'pp_percent_raise' a deafult value of ten (10). We use the intuitive syntax: PROCEDURE fp_raise_sal ( pp_sal IN OUT NUMBER, pp_percent_raise IN NUMBER := 10 ) IS ... ~~~~~ +--------+ / __ Default ________/ Value +--------+ This allows us to call the 'FP_RAISE_SAL' procedure with either of the following two syntaxes: fp_raise_sal ( :EMP.SAL ); /* Trailing parameter */ /* which has a default */ /* may be omitted. */ fp_raise_sal ( :EMP.SAL , 20 ); /* Providing a value for */ /* the 2nd parameter */ /* overrides the default */ This technique could also be used to enhance existing procedures to accept additional parameters *without* having to alter any of the existing invocations of that procedure -- provided each of the new parameters has a Default Value associated to it. 4. RESTRICTIONS ~~~~~~~~~~~~ (+) Default values for formal parameters are allowed exclusively for 'IN' parameters. Both 'OUT' and 'IN OUT' parameters must have a place to copy their value on the way "out" of the procedure, and hence cannot be omitted from the procedure's parameter list. (+) Only *TRAILING* parameters having default values may be omitted from the procedure call. For example, if a procedure is declared with two formal parameters having default values as follows: PROCEDURE fp_proc ( pp_one IN CHAR, pp_two IN CHAR := 'Hello', pp_three IN CHAR := 'World') IS ... Then we have the following behaviour when omitting one parameter. fp_proc( 'FirstVal', 'SecondVal'); | | V V fp_proc( pp_one , pp_two , pp_three ); | | | V V V 'FirstVal' 'SecondVal' 'World' and definitely NEVER : ~~~~~ fp_proc( 'FirstVal', 'SecondVal'); | \_______ V \ fp_proc( pp_one , pp_two , pp_three ); | | | V V V 'FirstVal' 'Hello' 'SecondVal' In short, in this example, to specify a value for the third parameter, you *MUST* also supply a value for the second parameter. 5. DECLARING AND USING PL/SQL FUNCTIONS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In addition to (Form-Level) procedures, SQL*Forms also supports the use of PL/SQL functions. Any designer who has used both the built-in packaged procedures and packaged functions will understand the simple differences between the two. Below we compare the two: Procedure Function ------------------------- -------------------------- (+) Defined in the SQL*Forms (+) Defined in the SQL*Forms 'Procedure Definition' 'Procedure Definition' Screen Screen (+) May be referenced or (+) May be referenced or copied from "library" copied from "library" form form, as if it were a procedure (+) Is a Named PL/SQL Block (+) Is a named PL/SQL Block which performs a task which represents an expression when invoked of an explicit datatype when evaluated (+) May accept parameters (+) May accept parameters (+) Has no return value, but (+) MUST return one value, and May pass back results May pass back results in OUT parameters in OUT parameters (+) May have default values (+) May have default values for formal parameters for formal parameters (+) Allows trailing params (+) Allows trailing params possessing deault values possessing default values to be omitted when to be omitted when invoking evaluating (+) For exception handling, (+) For exception handling, Behaves like embedded Behaves like embedded PL/SQL block when invoked PL/SQL block when evaluated The syntax for declaring a PL/SQL function parallels that of a Procedure, with the addition of the 'RETURN datatype' clause which identifies the type of value which the function returns: -------------------------------------------------------------- FUNCTION function_name ( parameter_name mode [:= value], ... ) ~~~~ ~~~~~ RETURN datatype ~~~~~~~~ IS BEGIN : RETURN( expression ); : ~~~~~~~~~~ EXCEPTION : RETURN( expression ); : ~~~~~~~~~~ END; -------------------------------------------------------------- MODE: Is one of IN, OUT, or IN OUT. ~~~~ VALUE: Optional constant or expression of the same ~~~~~ datatype as the associated parameter to specify a default value for the formal parameter. An explicit value passed-in at evaluation time overrides the default value. DATATYPE: Any of the datatypes that are supported for PL/SQL ~~~~~~~~ formal parameters are supported for the RETURN value of a PL/SQL function. These include DATE, NUMBER, CHAR, and BOOLEAN. Recall that LONG is not a supported datatype of either parameters or return values. EXPRESSION: A constant or expression of the same datatype as ~~~~~~~~~~ declared in the Function Specification's 'RETURN datatype' clause. It is an *ERROR* if a PL/SQL function does *NOT* return a value on exit. The PL/SQL instruction 'RETURN( expr )' returns the given expression as the value of the function and exits with success. Since a function represents an expression of a given datatype, it may be used in precisely the same way that a constant or local variable of the same datatype would be used. One notable exception to this rule is the use of PL/SQL functions in DML statements. Only constants or local variables may be used in the role of 'bind variables' in DML statements. A function value can always be assigned to a local variable of appropriate datatype, and this local variable used in the DML statement, to accomplish the same result. An example of a function, FF_DEPT_SIZE, which returns the total number of employees in a given department follows: +-------------------------------------------------------- | Procedure Name: FF_DEPT_SIZE +-------------------------------------------------------- | ---- Procedure Text ---- | | /* FF_DEPT_SIZE | ** ~~~~~~~~~~~~~ | ** Returns the number of employees in | ** the department whose number is passed in as | ** a parameter. | */ | FUNCTION ff_dept_size ( pp_deptno IN NUMBER ) | | RETURN NUMBER /* Funct. Return Type */ | | IS | lv_temp_count NUMBER; /* Declaration Section */ | | BEGIN | SELECT COUNT(*) | INTO lv_temp_count | FROM EMP | WHERE DEPTNO = pp_deptno; | RETURN ( lv_temp_count ); /* Return Function Val */ | | EXCEPTION | WHEN OTHERS THEN | RETURN ( -1 ); /* Return minus one */ | END; /* if problems arise */ +-------------------------------------------------------- Then, a trigger could use this function in the following way: +-------------------------------------------------------- | Trigger Name: ON-VALIDATE-FIELD +-------------------------------------------------------- | /* | ** If the Total Number of Employees in | ** the current department exceeds 100, | ** then disallow this entry | */ | IF ( ff_dept_size(:DEPT.DEPTNO) > 100 ) THEN | ------------ | MESSAGE('WOW! Current Department is too big now...'); | RAISE FORM_TRIGGER_FAILURE; | ELSE | :CONTROL.TOTAL_EMPS := ff_dept_size( :DEPT.DEPTNO ); | END IF; +-------------------------------------------------------- While the above trigger is not the most efficient way of accomplishing the goal -- i.e. we call the function twice when we could have coded it such that we only used the function once -- it does demonstrate that functions can be used in IF...THEN and assignment statements. NOTE: Anything that can be done with a Function, can also be done with a Procedure which includes an OUT parameter to return the desired value. Anything that can be done with a Procedure, can also be performed with a Function whose RETURN value reports the status of the task performed. So, while the syntax of a Procedure and a Function differs slightly, a particular task can be done via a PL/SQL Procedure or Function based on the syntax which the designer deems most convenient. 6. PLANNING AHEAD FOR BUILT-IN PROCEDURES (FORMS 4.0 AND HIGHER) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SQL*Forms 4.0 will introduce a number of new packaged procedures, or "built-ins", that will enhance the current set of functionality available to the Forms Designer. Future versions of SQL*Forms (4.0 and higher) will all use these built-ins. When these new procedures (and functions) are introduced in the software, these new names will become reserved words and would conflict with any Form-Level procedures with the same names in your application. To plan ahead, we have provided a tentative list of "built-in" procedure names which should not be used for names of Form-Level Procedures and Functions of your own creation. Any conflicts that you identify can be changed now to avoid problems later. Adopting a naming convention for your procedures and functions in your applications like: FP_PROCNAME for Forms Procedure FF_FUNCTNAME for Forms Function PP_PARMNAME for PL/SQL Parameter can insure that your future development will not encounter any naming conflicts as SQL*Forms is enhanced. The tentative list for 4.0 includes: ------------------------------------ Add_Association_List_Pair Add_Group_Column Add_Group_Row Cancel_Dialog Change_Alert_Message Clear_Message_Line Close_Query Convert_Other_Value Create_Association_List Create_Group Create_Group_From_Query Create_Queried_Record Delete_Association_List Delete_Group Delete_Group_Row Delete_Group_Rows Delete_Timer Disable_Item Fetch_Record Find_Alert Find_BColumn Find_CColumn Find_DColumn Find_Editor Find_Group Find_LOV Find_NColumn Find_Window Get_Editor_Value Get_Group_Cell Get_Group_Row Get_Group_Row_Count Get_Group_Select_Count Get_Group_Selection Get_LOV_Selection Get_Menu_Item Get_Menu_Radio_Group Group_Rows_Fetched Hide_Window Image_Add Image_And Image_Or Image_Subtract Image_UnZoom Image_Xor Image_Zoom Insert_Record Logon Logon_Screen Logout Move_Window OracleGraphics_Available Populate_Group Read_Image_Database Read_Image_File Read_Sound_Database Read_Sound_File Replace_Content Repopulate_Group_With_Query Reset_Group_Selection Resize_Window Run_OracleGraphics Run_SQLReportWriter Scroll_Canvas Select_Records Set_Block Set_Form Set_Group_Cell Set_Group_Selection Set_Group_Row Set_Menu_Item Set_Timer Set_Record_Status Set_Window_Content Show_Alert Show_Dialog Show_Editor Show_LOV Show_Window SQLReportWriter_Available Update_Record Write_Image_Database Write_Image_File Write_Sound_Database Write_Sound_File Built-ins planned for 5.0: -------------------------- Add_Button Add_Checkbox Add_Edit_Item Add_Image Add_Radio_Group Add_Radio_Item Add_Rectangle Add_Sound Add_Text Add_Text_List Create_Alert Create_Editor Create_LOV Create_Window Delete_Alert Delete_LOV_Selection Delete_Editor Delete_Window Pecs_Event Pecs_Facility