Liren Large Software Subsidy 5

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

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

Wrap

Text File | 1993-02-03 | 26.3 KB | 527 lines

ackage procedures and their equivalent macros as well. The reason for this is that this navigational macro does not make sense in the Pull-down style. In keeping with the standard behavior of a Pull-down menu, after a choice is made, one always return to the main menu. A good analogy would be to think in terms of the Macintosh interface or a DEC workstation. The user clicks on the submenu choice, that item is executed, and then the user is back at the main menu. As a navigational macro, Previous_menu does not make sense in a pull down choice - because after one makes a choice - he/she will be back at the main menu. To accomplish the same action as a Previous_menu in a Pull-down menu style, create an item that is command type 7, has "previous menu" as the item text, and on the command line has the following text "null;". This will get the user back to the main menu accomplishing the same function as [Previous Menu]. Be careful not to use this in Full_screen or Bar style menu applications, as this item will not accomplish anything. The [Previous Menu] key has not changed and works in all three possible menu styles. Since a user cannot dynamically change the style of a menu once he/she is executing it, some planning in the design stage (deciding on which menu style is needed) should enable one to code accordingly (previous_menu vs pl/sql cmd type 7 null;). This restriction on these package procedures and macros did not appear in the documentation (Product Change Request # 40929). Certain macros were maintained in SQL*Menu Version 5.0 simply for upward compatibility reasons. The Pull-down menu display style is Oracle's standard style. DISABLING THE EXIT KEY IN SQL*MENU V5.0 ======================================= In an application designed with SQL*Menu V5.0, it is possible to turn off the [Exit] key. The user will be forced to exit out of the application using one of the menu items during run time (ie. RUNMENU). Before disabling the [Exit] key, each menu within the application must have a menu item to allow them to exit:eg. command type 7 using the EXIT_MENU package procedure. The method will involve modifying the Oracle*Terminal resource file. SQL*Forms applications called by SQL*Menu will not be affected. Note: this technique will NOT work if a SQL*Forms application invokes SQL*Menu. The [Exit] key is controlled by the RUNFORM product mapping even though the cursor is active in the form's menu. Users will still be able to press the [Exit] key to navigate out of the menu and back to the form. To remove the [Exit] key, invoke Oracle*Terminal, open the resource file and selec the appropriate device. In the Product Definition screen, use the [Duplicate Record] to make a copy of RUNFORM-RUNMENU Product Name. Rename the new Product to RUNMENU as shown below: +--------------------------- Product Definition ---------------------------+ +-----------------------------------------------------------------------------+ | Product Name | Description | +----------------------------------+-------------------------------------------| | RUNFORM-RUNMENU | SQL*Forms (Run Form) and SQL*Menu (Run | | RUNMENU | SQL*Forms (Run Form) and SQL*Menu (Run | +------------------------------------------------------------------------------+ In the Key Mapping Definition screen, remove the mapping for [Exit]. Make sure that the status line reflects the correct Product and Device as shown below: Res: oraterm.r Prd: RUNMENU Dev: vt100 <List><Replace> Now the RUNMENU mapping will supersede the RUNFORM-RUNMENU mapping and the [Exit] key will be disabled. The user will be forced to use one of the menu options to exit out of SQL*Menu. Documentation ============= Complete documentation is available with the release. All users are advised to obtain the most current documentation. The Version 5.0 documentation set includes: SQL*Menu User's Guide and Reference V5.0 (Production) 3303-V5.0 SQL*Menu Designer's Quick Reference V5.0 (Production) 5527-V5.0 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 Documentation Bug Notes for 5.0.11.12 ===================================== 52640 SQL*NET login syntax incomplete. The example on p12-2 for logging in to ORACLE through SQL*NET (SQL*Menu User's Guide and Reference V5.0 (0490) shows the following syntax: :node_name The syntax should be: @driver_name:node_name 56161 Undocumented error: MNU-21011: UNHANDLED EXCEPTION [EXCEPTION_NAME]. Cause: A menu application raised the predefined PL/SQL exception indicated. The [EXCEPTION_NAME] is one of the following: PROGRAM_ERROR ORACLE error code ORA-06501. Raised when PL/SQL has an internal problem. Can occur when a menu calls a SQL*Forms packaged procedure when SQL*Menu is linked with SQL*Forms, but no form is currently active. NO_DATA_FOUND ORACLE error code ORA-01403. Raised when a single-row SELECT returns no rows. 57521 Undocumented error: MNU-10259: INVALID NULL ARGUMENT TO PACKAGED PROCEDURE OR FUNCTION Cause: Your menu application called a packaged procedure or function without supplying a required parameter in the parameter list. Action: Recode the procedure or function call to include the required parameter(s). 64064 The syntax for DOCMENU command is incorrect (SQL*Menu User's Guide and Reference V5.0 (0490) p12-8): The -o switch (object reference) described in the documentation is not implemented in SQL*Menu and should not be documented. 78708 SQL*PLUS version dependency undocumented.(VMS) Running SQL*Menu on VMS requires SQL*Plus version 3.0.9.5+. 85638 The syntax for the GENMENU command is incomplete (SQL*Menu User's Guide and Reference V5.0 (0490) p12-6). The descriptions of the following switches are incorrect or missing: -e [filename] Create a SQL*Plus export file named [filename]. -m [#] Create an application library with [#] number of modules. -p [filename] Create a library listing file named [filename]. -u Upgrade a 4.1x menu application to version 5. 98905 Predefined substitution parameter LN undocumented. LN is a predefined substitution parameter (similar to UN and PW) whose value is a two-letter constant that defines the language preference of the current user. Because its value is always known, SQL*Menu does not display the Enter Paramter Values dialog when you use this parameter in a menu-item command statement. Upgrading from Earlier Versions =============================== 1. All menus created prior to Version 5.0.10 must be regenerated to run with SQL*Menu Version 5.0.10. 2. At installation time, all 4.0 or 4.1 menu applications are automatically converted to Version 5.0 (if you select that installation option). At this time, all security information is also automatically upgraded from Version 4.1 work classes to Version 5.0 roles. Security is upgraded as in the following example: Version 4.1 application, SAMPLE, has two work classes, 10 and 20. Once upgraded, Version 5.0 application, SAMPLE, will have two roles: SAMPLE_10 and SAMPLE_20 (application-name_work-class#) All users in the old work classes will be enrolled in the corresponding new role, and the roles unt's password in order to install the designer tables. .<PARTIAL_HELP> Some, but not all, of the tables required by SQL*Menu are present in your database. The designer will not work unless all of them are present. If you wish to correct this, this install can remove the tables currently present and replace them with a full set. Any data in the tables will be lost. Alternatively, you can run MENUINS.CMD. # ********************************************************************** # Update filelist.ora with filenames not found in .FILES commands # ********************************************************************** .<DEINSTALL> %ORACLE_HOME%\PBIN\SQLMENU.COM %ORACLE_HOME%\PBIN\RUNMENU.COM %ORACLE_HOME%\PBIN\GENMENU.COM %ORACLE_HOME%\PBIN\DOCMENU.COM %ORACLE_HOME%\MENU\MENUTABS.LOG %ORACLE_HOME%\MENU\MENUVWS.LOG %ORACLE_HOME%\MENU\MENUGRTS.LOG %ORACLE_HOME%\MENU\MENUIDXS.LOG This is the SQL*Menu 5.0.11.12.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 5.0.11". Additionally, bugs 85960, 102060, 103012, 137452, 137453, and 138333 have been fixed in this version of SQL*Menu. Bugs outstanding: 90144, 132661, 134725, 136081. -------------------------------------------------------------------------------- +------------------------------------------------------+ | 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! | | +------------------------------------------------------+ -------------------------------------------------------------------------------- Release Bulletin SQL*Menu Version 5.0.11 (Production) April, 1992 This bulletin contains important information about the production release of SQL*Menu. It is recommended that you read it before attempting to use this version. This bulletin also directs you to function key mappings for this release for both VT100 and VT220 terminals. New Features since Versions 4.1 and 4.0 ======================================= These new features are described in detail in the SQL*Menu User's Guide and Reference Version 5.0 documentation. o Complete built-in menu integration with SQL*Forms applications o Multiple runtime menu display styles: o Pull-down o Bar o Full-screen o PL/SQL support - Oracle's procedural language extension to SQL o New security structure - using roles (privilege groups) o Comprehensive documentation capabilities: o Application, menus, items, parameters, procedures o Object reference report o Comprehensive or summarized application reports o Mouse support for bitmap environments o Ability to copy and reference objects such as menus and parameters o The SQL*Menu (Design) interface is completely revised o Menu-driven, like SQL*Forms 3.0 o Context-sensitive online help system o Pop-up lists-of-values - with auto-restrict capabilities o Scroll regions - with automatic word-wrapping and scrolling o Editing functions including: o Search and Replace o Cut, Copy, and Paste Changes in SQL*Menu (Design) from 4.1 to 5.0 ============================================ When one was developing an application with SQL*Menu Version 4.1, most of the committing (saving) to the SQL*Menu tables was done during the application building process. Basically there was a 4 step process to building applications in version 4.1. Selecting the first three options off the Menu Information Maintenance menu would define the application information that would be saved to the SQL*Menu tables: 1. Update Application Information - defines the title and directory for the .DMM file. 2. Update Work-class and User Information - defines who is authorized to use this application. 3. Update Menu Information - defines the actual information to appear within the application. As each menu item is defined, it is committed to the SQL*Menu tables. 4. Generate the application - this would create the.DMM library file that gets executed when the application is run. A designer could not leave the above three options without being prompted with "Do you want to commit the changes you have made? Y". SQL*Menu 4.1 designers had to save their work at each of the three points in the development process. In SQL*Menu 5.0, it is possible to create, generate, and execute an application from the design interface, without ever saving the application information to the SQL*Menu 5.0 tables. If you attempt to execute an application or exit the design interface, then the following alert message is issued, "Application locks may be lost. Continue?" Oracle recommends that you save a newly created or modified application before generating the library file. A new application must be saved at least once before it can be executed, otherwise a user will receive the MNU-10249 error (No authorization to run application <application name>). In the SQL*Menu 5.0 Users Guide and Reference (pg 5-25), the following is not emphasized enough "Remember to save the application before you exit SQL*Menu". In version 4.1, a designer would not get the opportunity to execute an application in which he/she was not defined in a Workclass because the application would not show up as an item on that users application menu (which shows all the applications that a user has access to). In SQL*Menu 5.0, Workclasses are replaced by ROLES. A designer could attempt to execute an application in which they are not defined in a ROLE. Your id has been granted access to SQL*Menu as a Designer, but you neglected to include your userid in the appropriate ROLE definition associated with the menu items for the application. Given this scenario, the designer would get the MNU-10249 error at the RUNMENU login screen when he/she attempts to execute. Additionally, if the designer specified an invalid user name and password at this screen, then he/she would be disconnected from Oracle and would be unable to commit any unsaved changes to the application once back in designer mode. The "ORA-03114: not connected to ORACLE" would be issued when the designer attempts to save. To avoid the above scenario, a designer should define at least one ROLE with his/her own userid defined within that ROLE for use in testing the application that is being developed. This ROLE should be set up before any substantial development work is done. In SQL*Menu 4.1, it was possible, though not recommended, to design a menu application that had circular menu references. That is, an item on a submenu might reference another menu and go to that menu using command type 1. A SQL*Menu application with circular menu references will not generate under SQL*Menu 5.0. Changes in Execution of SQL*Menu applications - SQL*Menu (Run Menu) =================================================================== SQL*Menu Version 4.1 full-screen applications are upwardly compatible and will run on Version 5.0 of SQL*Menu after being converted. Two changes in behavior exist that warrant additional explanation. These are explained in the following sections. I. The RUNFORM command line switches with command type 4. In SQL*Menu 4.1, it was possible to specify a different CRT definition when running a SQL*Forms 2.3 application that was linked with DMU (command type 4). SQL*Menu 5.0 uses Oracle*Terminal resource files, not CRT files. Using command type 4 in version 5.0 would attempt to run a linked-in SQL*Forms 3.0 application. The SQL*Menu Users's Guide and Reference explicitly states that the -c command line switch, as well as the -e, -i, -r, and -w switches, for RUNFORM, command type 4, are not supported (pg 8-16). Starting with SQL*Menu Version 5.0.10, the -c command line switch will be allowed for command type 4, as long as the device type does not change. For example, if you went into RUNMENU with a VT100 terminal definition, then you could specify another Oracle*Terminal mapping (eg VT100NEW) with the RUNFORM command. This VT100NEW could contain the same key mappingautomatically given privilege to execute the same menu items that the work class could access. In addition, starting with SQL*Menu Version 5.0.9, SQL*Menu users will be granted access to SQL*Menu Version 5.0 as an installation option. Prior to Version 5.0.9, SQL*Menu users had to be granted access to Version 5.0 by hand, even though the work classes were automatically upgraded to roles. 3. In addition, all menu applications created with SQL*Menu Version 4.1 or 4.0 must have their table structures converted to Version 5.0, using ORA_ROOT:[SQLMENU50]CONVMENU.SQL (application_name) in SQL*Plus. This SQL script will update the SQL*Menu base tables as necessary for Version 5.0. You will then need to run GENMENU on the transferred application to actually generate and create a library file (application_name.DMM). General Restrictions/Notes ========================== 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. When using SQL*Menu in conjunction with SQL*Forms 3.0, be aware that | the SQL*Menu role name that you put in the Menu Security Group Name | field in the Form Definition form in SQL*Forms (Design) WILL | OVERRIDE any SQL*Menu application security that you have set up. This | is a convenience factor that is put in so you can have all your users | see the default menu application you use with your form as the same | user (they see the same options). If you do not fill in this field, | application security will be followed, and SQL*Menu will check the | database for a list of roles to which the current username has | privilege, and will build the menu tree accordingly. Bugs Fixed in 5.0.11 ==================== 33762 Need an error message for when login fails. 36451 Help text prints out wrong for generated application documentation. 40369 Purpose text of the Menu Definition spread table disappears after you hit [Return]. 40691 Lines get reformatted (Carriage returns not preserved) on the command line text for an item when you resequence the items in the spread table. 40975 Access violation when NULL arguments are passed to NEW_APPLICATION packaged procedure. 41493 Reference procedure gets compile error when used on an item's command line. 41998 MENU_FAILURE should be set when OS_COMMAND ('(type=4) runform) does not successfully run a form (e.g., when the .frm field does not exist). 42036 GLDMU and GLMND .com files should create the executable in the current directory and it should setup a symbol to run that executable. 42112 Access violation after hitting Ctrl-C twice when executing a menu from SQL*Menu (Design). 42716 menu hangs in Full-screen and Bar style when a user tries to navigate to a submenu where that user is not defined in any roles for the items of that submenu. 42991 Test: In TESTTABS.sql, second CREATE should be: CREATE TABLE MENU_B_APPL_GRP instead of MENU_B_APPL. 43048 Hitting PF4 to cancel out of the Query Parameter dialog box should fail query_parameter packaged procedure and/or set menu_failure. 43227 Unable to save an application if a role in a reference menu is added. 44026 Cannot specify Oracle*Terminal filename:mapping in the user preference file. 44916 Role definitions are not retained if you use the copy object function on a menu item. Roles are maintained if you copy an application or a menu. 44945 SQL*Menu returns unhandled PL/SQL error to SQL*Forms when SQL*Menu tries to perform PL/SQL operations on a form but passes a NULL argument to PL/SQL. 44959 Cannot generate a library file when a logical in the application directory points to a different node over DECNET - unless the library already exists on that node. 45170 SQL*Forms application hangs when pressing [Menu] function key. 45182 SQL*Menu should prompt user when there are more choice on the menu than can be displayed. 45621 SET_INPUT_FOCUS does not work for Full-screen menus. 45948 Stack dump when Ctrl-C pressed twice from a linked-in menu. 45972 SQL*Menu doesn't work if language in INIT.ORA is Finnish or any other language where JAN is not the proper month name abbreviation. 46021 Referencing the same submenu causes the item text not to be displayed. 46026 Incorrect hint text in SQL*Menu (Run Menu) logon screen. 46595 Global variables are preserved when developing a menu application. 47042 New_user packaged procedure will not function for "/" ops$id. 47072 Access violation running a menu with (Run Menu) product mapping in resource file. 47323 Grants on the SQL*Menu tables are not preserved when migrating from version 4.1 to 5.0. 64692 Identification field not displayed in application menu 61452 Genmenu dmgfre's pointers twice when generate fails 60857 Dmuapl.ok: invalid pointer use in for() loops 60856 Dmdp.c: dmgfre() called with invalid pointer 60259 Should use pointer arithmetic in files Dmuapl.ok, Dmufsm.ok 65457 Memory accretion between SQL*Menu and SQL*Plus 73999 BGM DOES NOT CARE ABOUT ROLES ASSOCIATED WITH ITEMS 95824 Genmenu No Longer Allows Granting Options -GE, -GD, -GA, -R, -U, ? without supplying an application name. 103749 Can't run application if it doesn't have a Background Menu 85947 UNABLE TO ENTER 8-BIT CHARS IN APPLICATION DEFINITION SHORTNAME 104293 ASSIGING VALUE TO FREED MEMORY IN DMUFSM DO COMMAND Notes for 5.0.11 ================ 1. SQL*Menu Version 5.0.11 is compatible with and only with SQL*Forms Version 3.0.16. 2. All menu applications created prior to version 5.0.11 must be regenerated to run under 5.0.11. This is due to several performance enhancements that make start-up faster, and generation significantly faster. Now that 5.0.11 is full production, we will strive to minimize future regeneration needs. Changed Features in 5.0.11 ========================== PLSQL commands in a SQL*Menu item (type 7) which follow a CALL(.,DO_REPLACE) or CALL_QUERY(.,DO_REPLACE) -- which replace the all of the current menu information in the process -- are not executed beginning with SQL*Menu 5.0.11. The fact that they did execute in previous versions was allowed by a loophole in the way that menu information was disposed when the current menu was Replaced. An explanation follows: Each Runform session can have at most one menu application associated with it at any given time. In particular, menus are not stacked as are called forms. In general, this is where confusion lies. When the single menu which exists for each Runform session gets REPLACED, this causes all of the current menu's information (menus, parameter values, items, etc) to be discarded upon reading in the new menu. When one form calls another with the DO_REPLACE option, the single menu is replaced, as the name would imply, and upon returning control back to the calling form, the menu associated to the calling form is reread into memory. The REPLACE_MENU packaged procedure behaves analogously. Only one associated menu is ever "on hand" at a time. Prior to Menu 5.0.11, the currently executing PLSQL context (item, procedure, etc) was not correctly disposed, along with all of the other information during a DO_REPLACE. This lead to problems if a given menu item issued a CALL with the DO_REPLACE option, and later contained references to parameter values which had been subsequently reinitialized upon rereading the original menu when the calling form regained control. Now ALL menu information is disposed of in thes DO_REPLACE scenario, making the CALL(.,DO_REPLACE) in a PLSQL Menu Item effectively behave similar to the NEW_FORM packaged procedure. All commands in the menu item/procedure which follow the CALL(.,DO_REPLACE) are disposed of (during the process of menu Replacement) and are never executed. These comments only apply to the DO_REPLACE option of the CALL/CALL_QUERY commands, and the change of behaviour is specifically for CALL/CALL_QUERY(.,DO_REPLACE) when used from a menu item. Note that DO_REPLACE-ing a menu does not affect the values of Global variables which may already exist. A possible solution to emulate the previous behaviour is to have the SQL*Menu PLSQL item use the EXECUTE_TRIGGER packaged procedure to issue the CALL(., DO_REPLACE) from a trigger in the current form. Since the DO_REPLACE does not dispose of the PLSQL information from the currently running form in the process of replacing the menu, commands following the CALL(.,DO_REPLACE) issued from a form trigger are not affected. 2. 5.0.11.12 has had some slight modifications made to allow it to be used against an ORACLE V7 Database. No changes need to be made to continue to run against earlier versions of the database.