Oracle Forms and Reports: Complete Explanation of Every Section

This guide explains the headings and technical terms of Oracle Forms and Reports one by one, including what each concept means, why it is used, and a practical example. It combines concepts from older Oracle Forms and Reports documentation with general user-interface design principles, and includes important corrections for accuracy (Oracle, n.d.-a, n.d.-b).

The main distinction is:

Oracle Forms is primarily used to build interactive applications where users enter, update, query, and manage data.
Oracle Reports is used to retrieve data and present it in formatted reports, such as invoices, summaries, and financial statements.

Oracle documents these as separate development tools with different design objects and responsibilities (Oracle, n.d.-a, n.d.-b).

Part 1: The Design Process

This section explains how to plan an application before developing it.

1. Understanding the Process

This means understanding the business activity that the application must support. Before creating a form, ask:

Who will use the application?
What information will they enter?
What information do they need to see?
What business rules must be applied?
What happens after the user submits the information?

Example: Imagine a user wants to submit a change request. The business process might be:

The requester enters a change description.
The system validates the information.
A reviewer examines the request.
An approver accepts or rejects it.
An authorized administrator deploys the change.

If you understand this process first, you can design the appropriate forms and screens.

2. Building the User Interface (UI) Elements

UI means User Interface: everything the user sees and interacts with. Examples include text fields, buttons, checkboxes, lists, tables, menus, and windows.

For example, a Change Request form might contain:

UI Element	Purpose
Request ID	Displays the request identifier
Description	Allows the user to enter details
Priority	Allows selection of priority
Submit button	Submits the request
Status	Displays the current status

The objective is to translate business requirements into controls that users can understand and operate.

3. Gathering User Feedback

This means showing users an early version of the application and asking them to evaluate it. For example, a developer might create a preliminary Change Request form and ask the requester:

Is the description field large enough?
Are the buttons easy to find?
Is the information arranged logically?
Are the error messages understandable?

You then improve the design based on the feedback. Important: This is not the same as testing whether the SQL code works. It is evaluating whether the application is convenient and understandable for its users.

Part 2: Creating an Effective Form

This section explains how to organize the visual and functional elements of an Oracle Forms application.

1. Understanding Forms and Modules

Module: A module is a development unit in Oracle Forms. A Form Module contains the definition of a form, including its data blocks, items, triggers, canvases, windows, and other objects. For example, you might have: CHANGE_REQUESTS.fmb, CHANGE_APPROVALS.fmb, and CHANGE_DEPLOYMENTS.fmb. A form module is not the same thing as a database table. It is the application component that provides the user interface and associated logic.

Form: A form is the application component through which users interact with data. For example, a Change Request form allows users to create or modify change requests. A form module can contain multiple windows and canvases. Therefore, it is not technically accurate to describe a form as simply "the window itself."

Block: A block is a logical container for related items. Oracle Forms has two important block types:

Data Block: Associated with a data source, such as a database table or view.
Control Block: Not directly associated with a database table; it is commonly used for search criteria, buttons, and temporary user input.

For example, a data block could be associated with the CHANGE_REQUESTS table. It might contain REQUEST_ID, DESCRIPTION, STATUS, and PRIORITY. A control block might contain a search field and a Search button.

Item: An item is an individual field or control inside a block. Examples include a Text Item (allows the user to enter a description), Check Box, Radio Group, and Push Button.

Region: In the older Oracle Forms design terminology, a region is a visual area or boundary that separates a logical group of fields from other fields in the same block. For example, a form might visually separate Request Information, Approval Information, and Deployment Information. A region is not the same thing as a database object or a data block. Also, a tabbed canvas is a particular canvas arrangement, not simply another name for a region (Oracle, n.d.-a).

Frame: A frame is a layout object used to arrange items within a block. For example, you might use a frame to align Request ID and Request Date, Requester Name and Department, or Priority and Status. It helps maintain consistent positioning and spacing.

2. Windows and Canvases

These two concepts are particularly important because they are often confused.

Window: A window is a container that displays visual elements of the form. For example, an application could have a Main Window (displays the main request form), Approval Window (displays approval details), and Search Window (displays search criteria). A Forms window is an Oracle Forms application object; it should not be confused with the operating system's entire desktop window.

Canvas: A canvas is the surface on which visual items are displayed. Think of it this way:

Window = The container.
Canvas = The surface displayed inside the container.
Items = The controls placed on that surface.

Oracle Forms supports several canvas types:

Canvas Type	Purpose
Content Canvas	Main canvas displayed in a window
Stacked Canvas	Displays additional content over an existing canvas
Tab Canvas	Organizes information into tabbed pages
Toolbar Canvas	Displays toolbar controls

Example: Imagine a Change Management application. The main window displays a content canvas. When the user clicks an additional-details button, a stacked canvas can display more information without replacing the main canvas. A window can display more than one canvas, depending on the design (Oracle, n.d.-a).

3. Guidelines for Building Forms

Basic Design Principles: These are general visual-design principles.

Consistency: Use the same font, colors, and button styles throughout the application.
Alignment: Align fields and labels to create an organized appearance.
Proximity: Place related fields close to each other.
White Space: Leave enough empty space so the screen does not look crowded.

Adding Color: Color should communicate meaning, not merely decorate the application. For example:

Color	Possible Meaning
Red	Error or rejected request
Green	Approved or successful
Yellow	Pending or requires attention
Blue	General information

Do not depend on color alone. A status should also have a readable text label, such as APPROVED or REJECTED.

Object Libraries: An Object Library allows developers to reuse standard objects across multiple forms. Instead of designing the same toolbar (Save, Exit, Search, New Record) independently in every form, you can create reusable objects in an Object Library. This helps maintain consistency and reduces duplicated development work. Oracle identifies Object Libraries as an important mechanism for reuse and standardization (Oracle, n.d.-a).

Designing Messages and Online Help: A poor error message says: Error occurred. A better error message says: Request description is required. Please enter a description before submitting. The second message explains what went wrong, why the operation cannot continue, and what the user should do. Online Help provides additional guidance within the application without making the user leave the screen.

Building Effective Menus: Menus organize the application's available functions logically so users can find them easily.

File → New Request, Save, Exit
Requests → Search Requests, My Requests, Pending Requests
Administration → Users, Roles

Part 3: Creating an Effective Report

Oracle Reports is designed to produce formatted output from database data, such as invoices, financial statements, and approval history reports. Unlike Oracle Forms, where the user interacts with fields and buttons, Oracle Reports focuses on how information is retrieved, arranged, and presented.

1. Templates and Layout Objects

Templates: A template defines a standard visual design that can be reused across reports (company logo, fonts, colors, page numbers). Think of a template as a reusable report design.

Layout Objects: These are the elements that control how data and visual components appear in the report.

Frame: Surrounds other objects and helps organize them (e.g., the customer information section of an invoice). It helps prevent objects from overlapping.
Repeating Frame: This is particularly important. It repeats its contents for each record in a data group. For example, if a query returns three change requests, a repeating frame displays the request information three times, once for each returned record.
Field: A layout object that displays a value (e.g., Request ID, Request Status, Priority). A field can display a database column or a calculated value.

2. Controlling Layout Objects

This is one of the most technical parts of the guide. The objective is to control where objects appear, how they resize, and how they behave when a report spans multiple pages.

Anchors: An anchor defines the positioning relationship between two layout objects, treating them as having a parent-child relationship. If the parent becomes larger, the anchor helps determine how the child should be positioned relative to it. There are two types:

Implicit Anchor: Created automatically by Oracle Reports when an explicit anchor has not been defined.
Explicit Anchor: Created manually by the developer for more precise control over the layout (Oracle, n.d.-b).

Print Object On / Base Printing On: These are two related properties that do different jobs. Print Object On determines when an object should be triggered to print (e.g., All Pages, First Page, Last Page). Base Printing On determines which other object provides the reference for that printing frequency.

Example: If Print Object On = All Pages and Base Printing On = Anchoring Object, the object is triggered to print on every logical page on which its anchoring object appears. These properties determine printing behavior relative to logical pages and other layout objects; they do not simply mean "print on page 1" in every situation (Oracle, n.d.-c).

Horizontal and Vertical Elasticity: Elasticity controls how an object's width or height can change at runtime. Imagine a report field displaying a comment that can be short or long. Elasticity helps determine whether the field or its containing frame can resize to accommodate the data.

Setting	Meaning
Fixed	The object's size remains fixed
Expand	The object can grow
Contract	The object can shrink
Variable	The object can grow or shrink

Horizontal elasticity controls width; vertical elasticity controls height. Elasticity applies to the dimensions of the layout object, not simply to the length of the database column (Oracle, n.d.-c).

Page Break Before / After: These properties control where a report starts or continues on a new page. For example, in a financial report containing Revenue, Expense, and Profit sections, you might want the Profit Analysis to start on a separate page using Page Break Before.

Page Protect: Page Protect helps keep an object and its contents together on the same logical page. For example, an approval summary containing the Approver Name, Approval Date, Decision, and Comments should not be split across two pages. Page Protect attempts to keep them together; if there is insufficient space, Oracle Reports may move the object to the next page. It is not a guarantee that every combination of objects will always fit (Oracle, n.d.-b).

Keep with Anchoring Object: This property controls whether an object should remain on the same logical page as the object to which it is anchored. For example, if the Parent (Approval Details frame) is moved to another page because of pagination, this property helps keep the Child (Approval Status field) with it.

The Difference:

Page Protect: Keeps an object and its contents together.
Keep with Anchoring Object: Keeps an object with its anchor parent.

Part 4: Creating an Effective Display (Graphs)

A report does not always need to display data as rows and columns. Sometimes a graph makes the information much easier to understand.

1. Bar Charts

A bar chart compares values between separate categories. Example: Comparing sales for IT (100,000), Finance (70,000), and HR (40,000). Best used for: Comparing categories, departments, products, or request statuses.

2. Line Charts

A line chart shows how a value changes over time. Example: Monthly revenue from January to April, making it easier to see whether revenue is increasing or decreasing. Best used for: Monthly revenue, yearly expenses, system performance, or the number of requests submitted over time.

3. Pie Charts

A pie chart shows how individual categories contribute to a total. Example: If a system has 100 change requests, a pie chart can show Approved (60%), Pending (25%), and Rejected (15%). Best used for: Showing a small number of categories that make up one total. Avoid using a pie chart when there are too many categories or when the differences between values are very small. A bar chart is often easier to compare accurately (Few, 2012).

4. Labels, Titles, and Legends

These elements make graphs understandable: Title (explains what the graph represents), Labels (identify categories or values), Legend (explains the meaning of different colors or series), and Axis (provides the scale used to interpret values).

Conclusion: What Makes a Good Forms and Reports Application?

A good Oracle Forms application should:

Allow users to complete business tasks easily.
Organize related information logically.
Provide understandable messages and instructions.
Maintain a consistent visual design.
Make data entry and navigation efficient.

A good Oracle Reports application should:

Present information accurately.
Use appropriate frames and repeating frames.
Control object positioning with anchors.
Handle variable-length data using elasticity.
Manage page breaks and pagination correctly.
Use graphs when they make the information easier to understand.

For an Oracle developer, the important thing is to understand that Forms design and Reports layout design are different skills. Forms focuses on user interaction, while Reports focuses on the presentation and pagination of retrieved data.

Important Corrections and Points to Improve

These corrections should be noted for accuracy:

"Form = The main container (the window itself)": A Form Module is the application development unit. It can contain multiple windows and canvases.
"Region = Like a tabbed page": A region is a visual grouping or boundary in the terminology of the older Forms guide. A Tab Canvas is a separate canvas type.
"Window = Operating system window": It should be described as an Oracle Forms application container.
"Print Object On = Where and how often an object prints": It determines printing frequency relative to the object specified by Base Printing On.
"Page Protect = Keeps an entire block together": More precisely, it attempts to keep the protected object and its contents on the same logical page.
"Pie Charts = Show parts of a whole": This is correct, but you should recommend limiting the number of slices and using bar charts when accurate comparisons matter.

Version Consideration: Oracle's current product page lists Oracle Forms and Reports 14c (14.1.2.0). This article uses terminology found in older Oracle Developer documentation. Readers should check the documentation for their installed release when working with specific properties and features (Oracle, n.d.-d).

References

Few, S. (2012). Show me the numbers: Designing tables and graphs to enlighten (2nd ed.). Analytics Press.

Oracle. (n.d.-a). Designing visually effective applications. Oracle Forms Developer documentation. https://docs.oracle.com/html/A73073_01/gui.htm

Oracle. (n.d.-b). Layout objects. Oracle Reports documentation. https://docs.oracle.com/middleware/12213/formsandreports/build-reports/orbr_concepts2004.htm

Oracle. (n.d.-c). Designing visually effective applications. Oracle Forms Developer and Oracle Reports Developer documentation. https://docs.oracle.com/cd/A97338_01/doc/forms.6i/a73073/A73073_02.pdf

Oracle. (n.d.-d). Oracle Forms. https://www.oracle.com/application-development/technologies/forms/forms.html

Pages

Forms and Reports