FRM 10214 - No authorisation to run any application
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 2 of 2

Thread: FRM 10214 - No authorisation to run any application

Hybrid View

  1. #1
    Join Date
    May 2001
    Location
    Philippines
    Posts
    42

    Angry

    encoutered the ff on Forms 6i:

    FRM 10214 - No authorisation to run any application
    and
    FRM 41810 - Error creating menu.

    when logged in as USR1.

    USR1 is not the owner of objects, etc.

    OWN1 owns the objects, etc, OWN1 only Grants all objects to USR1.
    Forms Admin Grant was also granted to PUBLIC.

    Will appreciate any help from you guys.

    thanks

  2. #2
    Join Date
    Oct 2001
    Location
    Madrid, Spain
    Posts
    763
    Hi,

    Check this from metalink:

    Understanding Menu Roles and Access Authority
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    1. Using the RUNMENU executable.

    The RUNMENU executable will ALWAYS read information about a user's access rights
    to a module (not the menu items) from the Forms tables. This is even true when it
    is run specifying a module on the command line. For this reason access to the tables
    TOOLS* is required. See section 4 for information on doing this. If the user does
    not have access to these tables then they will get the following error:


    FRM 10256 - User is not authorized to run Oracle Forms Menu.


    If however, a module is specified on the command line but it doesn't exist in the
    tables, or it is owned by another user and no access has been granted to it, then the following error is issued:

    FRM 10249 - No authorization to run application [application]


    Access rights to individual items is discussed in section 3.


    2. Using the RUNFORM executable.

    The RUNFORM executable comes with the DEFAULT menu build into it. As such, this
    menu is not a standard menu application and cannot be restricted using
    SET_MENU_ITEM_PROPERTY. A menu application definition is supplied with the
    Forms product, this is the file menudef.mmb, which may be attached to a form as a
    custom menu and access restrictions applied using roles or
    SET_MENU_ITEM_PROPERTY.

    There are three ways in which a Forms application can use a custom menu application:-

    2.1 Enter the details of the menu in the form's module property
    sheet and then invoke runform or issue a CALL_FORM specifying
    DO_REPLACE.

    2.2 Issuing a CALL_FORM, specifying NO_REPLACE (the default), with
    the calling form already using the custom menu, in which case
    the menu application isn't changed.

    2.3 Execute the built-in REPLACE_MENU to force a
    menu application to be loaded. This can include the current
    menu.


    The menu can be located by either looking at the file system or the Forms
    tables. The default is to look in the Forms tables for the menu module
    definition and from there find the location of the .MMX file. If this default is
    assumed or specified but you don't have access to the FRM40* and TOOLS* tables then you will get the error:-


    FRM 10256 - User is not authorized to run Oracle Forms Menu.


    If his default is assumed or specified but the menu is not stored in the tables or
    you have not been granted access to it you will get the error:


    FRM 10249 - No authorization to run application [application]


    If you specify the use file option, which can be done with the "Use file"
    checkbox in the form module property sheet (in the case of 2.1 above) or the USE_FILE
    parameter to REPLACE_MENU (in the case of 2.3 above), and the .MMX file can't be
    located (the actual search paths are platform dependent) then the following error is issued:


    FRM 10221 - Could not read file


    Up to this point no account has been taken of ROLE information as all that has happened
    is that the correct .MMX has been located. Most aspects of the ROLE information
    are generic to whether RUNFORM or RUNMENU executables are being used. However, RUNFORM
    can use a facility not available to RUNMENU which is the direct specification of
    a menu role name to use for security checking. This can be done by specifying a
    "Menu Role" attribute on the form module property sheet. This allows a menu application
    to be executed by a user who has no role privileges whatsoever and negates the need
    for access to the Forms definition tables as outlined in Section 4. Should the specified
    role not exist in the .MMX file then the following error is issued:-


    FRM 10214 - No authorisation to run any application



    3 Roles and Security within Forms.

    Security definitions for the Forms and menus are defined within the
    File->Grant menu. The designer is presented with up to three menu items, depending upon their privileges:


    Module...
    Roles...
    Role Access...


    "Module..." security allows the designer to grant other designers copy and reference
    privilages to their objects stored within the database. A designer can only grant
    access to modules created by them, all others modules are hidden. If a menu is stored
    in the tables, any user can execute this menu without being granted permission directly.

    User and group privileges to the menu application are provided via "Roles...". The
    roles are stored within the Forms definition tables, are specific to the Forms product,
    are independant of any menu application, and are, at time of writing, not related
    to roles within the Oracle7 databases created using:


    CREATE ROLE etc.


    Roles should be defined in the Forms4.0 designer using File->Grant->Roles, for which
    you must be connected to the database, and have DBA privilages or be granted this
    function via "Role Access". This will list the currently defined roles. New roles
    may be added or existing roles modified to add or remove users etc. The roles should
    be given meaningful names like ADMIN, MANAGERS etc. Creation of roles is covered
    in more detail within the Oracle Forms User Guide.

    Once the roles have been defined they can be incorporated into the
    Menu->Module definition as roles used to control security within the menu module.
    NB. any role names may be entered, invalid role names eg. those not defined to Forms
    designer, will not cause an exception - role membership information is checked at
    runtime not at design time, if a role does not exist no errors will be raised. To
    enable the roles, at the application level, the "Use Security" box must be checked.
    Checking this box forces the application to check the database at runtime for roles,
    otherwise they are ignored, and access is not restricted.

    When declared the roles will appear in the Security Roles List window within the
    Menu Editor and can be enabled/disabled at all levels below the application definition,
    TREE level. An item may be associated with many roles but will not appear if assigned
    a non-existent role or to no roles at all, when security is being enforced. Checking
    the "Disp w/o priv" box will display the item greyed out if no privilege is granted.

    If the top level menu, as defined either by the application root menu or the starting
    menu specified when using REPLACE_MENU, no items definitions have any roles granted permissions then:

    RUNMENU will display an error message:


    FRM 10247 - No active items in root menu application.


    and display a default menu:


    Application Window
    ...
    Exit ...


    where is the menu module to which you are attempting to
    connect.

    RUNFORM displays the errors:


    FRM 10247 - No active items in root menu application.

    FRM 41810 - Error creating menu.


    and displays the standard "Window" menu for a Graphical User Interface version of
    Oracle Forms, or no menu at all for a character mode version.

    The "Role Access..." function allows the system administrator to grant users the
    ability to create and modify existing roles within the Forms system. This user may
    then grant the role privileges to subsequent users. If a designer does not have
    the roles privileges, the "Roles..." and "Role Access..." menu items will appeared greyed out.


    4. Granting Users access to Forms Tables

    The Forms tables are needed for various tasks, such as the ability to save
    modules to the db, but in the context of this article they are interesting
    because a normal USER of a menu application needs access to them if role
    information is taken from the database.

    For users to be able to use RUNMENU, and RUNFORM with attached menus with role restrictions,
    they must be given access to the definition tables. This requires two scripts:

    $ORACLE_HOME/dbs/toolgrnt.sql
    $ORACLE_HOME/forms40/frm4grnt.sql

    These scripts should be run from within Sql*Plus, each prompting for a user
    name.

    eg. (from within orawin directory)

    SQLPLUS / @dbs/toolgrnt.sql

    Next time try to search a little bit. It is not too hard to search before asking I think

    Cheers

    Angel

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width