Skip to Main Content

Oracle Forms

Oracle Forms, a component of the Oracle Developer Suite, is a Rapid Application Development (RAD) environment for developing database applications using Oracle's PL/SQL database language. Oracle Forms accesses the Oracle database and generates a default form that presents and manipulates the data. The source form (*.fmb) is compiled into an "executable" (*.fmx), that is interpreted by the forms runtime module. Various GUI elements, such as buttons, menus, scrollbars, and graphics can be placed on the form. 

 

This document briefly describes the techniques of running forms locally and our programming standards.

Preliminary Setup

  1. Place the modified form file in a directory on your PC called C:\forms10g, which is defined by the Environmental Variable - FORMS_PATH.  To set the  FORMS_PATH modify the ‘default.env’ file in c:\DevSuiteHome_1\forms\server.  Change the FORMS_PATH to the following:

    FORMS_PATH=C:\forms10g;Q:\Oraformlibs\fmx;C:\DevSuiteHome_1\forms    

    The FORMS_PATH variable contains the search paths for Forms applications (.fmx files, PL/SQL libraries).  If you need to include more than one directory, they should be separated by a semi-colon (e.g. c:\test\dir1;c:\test\dir2).

    q:\oraformlibs\fmx is where the compiled version of the forms and libraries reside

    c:\form10g is where the modified forms reside

     
  2. Start the OC4J on the developer's computer by:

    Go to Start>Programs > Oracle Developer Suite – DevSuiteHome1 > Forms Developer > Start OC4J Instance

     
  3. DBA needs to check each form’s seed numbers.  The seed numbers should correspond to the ones stored in the database.  The form’s seed numbers can be found at the form-level trigger:

    G$_VERIFY_ACCESS.   The seed numbers are in the BANSECR schema in the GUBIPRF table.  
     
  4. Compile the form file using the ‘Forms Compiler’ to create an .fmx file. The file will be created at C:\forms10g.

    Go to Start > Programs > Oracle Developer Suite – DevSuiteHome1 > Forms Developer > Forms compiler

    Specify the file name (fmb), your userid, password, and database where the form will be tested

  5. Once the OC4J instance is started, open the URL using the following:

    http://localhost:8889/forms/frmservlet&form=yourform&debug=true

    This will bring up a database login screen.  Input your user name, password, and database name. 

     
  6. Run the form in the Banner.  

Forms Interface

Banner forms are generally divided into validation forms, application forms and inquiry forms:

  • A validation form generally has one navigable block without a key block
  • An application form has a key block and at least one navigable block
  • An inquiry form does not allow you to create, change or delete records 

Here is an example of a typical Form Builder window:

 A typical form builder window contains:

  • Window title, which includes the form’s name and version
  • Menu bar and pull-down menus
  • Buttons and other control items that do not correspond to the data
  • Data items in the blocks
  • Console, which includes the message line and status line

 The table below contains common items placed on blocks:


Common Items placed on blocks:

Item

When to use

Text items

Use for data entry and display of character values.

Buttons (non-iconic)

Use as dialog responses (in modal windows) and for item-related actions.

Check boxes

Use only when the label on the check box can clearly be thought of as having "true" (checked) and "false" (unchecked) states.  Otherwise, use a radio button group with two items.

Display items

Use for display-only fields in which the user can never type; for example, the Total field in a financial application.

LOVs

Use when the user must select from a list of more than 15 rows or to show several columns of data.

Poplists

Use when only one value is applicable and the list of choices is 15 or less.

Prompts

Use as labels for fields, check boxes, lists, etc.

Radio groups

Use to present mutually exclusive choices.

 

Programming Standard

  1. All modified Banner forms or USF forms should have a version number that starts with “N”, plus the previous version number. DBA needs to input the form’s appropriate version on a Banner form called  GUASECR. (For development and testing purpose, developer can go to BANSECR.GURAOBJ table to change the version number. ) The form’s version number can be found at the form-level trigger called “Load_Current_Release”.
  2. For auditing purpose, comments for the modified code should be added to the ‘Program Units’ called ‘UNF_AUDIT_TRAIL’.  At the beginning of the modified part, insert a comment line “UNF Begin”; at the end of the modified part, insert a comment line “UNF End”.
  3. Forms code executes as the result of a triggering event. While the trigger may call other program units in the form, in an attached library, or in the database, the unit of code execution is the trigger.  The called forms procedures, functions or packages are created under “Program Units”. If a form needs to call a database procedure or function, create a package to contain the objects in the NFINS schema. The DBA needs to grant execute privilege on the package to roles BAN_DEFAULT_M and BAN_DEFAULT_Q. An example is shown below:  

Grant execute on NFINS.wkigmch to BAN_DEFAULT_M;
Grant execute on NFINS.wkigmch to BAN_DEFAULT_Q;

GOQOLIB is a Banner form that is used as a repository to store triggers, blocks, windows, canvases, visual attributes, items, and classes that can be referenced. All the triggers of GOQOLIB are embedded into classes.  Many of these triggers in turn execute procedures and functions that are stored in the GOQRPLS, EOQRPLS, GOQWFLW, and GOQGMNU libraries. Changes made to the libraries will be reflected in all forms that reference it whenever they are regenerated.