Please find good oracle material @ http://download.35mb.com/kvreddy83
Alert : An alert is a modal window that displays a message notifying the operator of some application condition.
There are three styles of alerts: Stop, Caution, and Note
Attach Library: Attached library object
This object is a read-only library module that represents a collection of subprograms, including user-named procedures, functions, and packages, that can be called from other modules in the application.
Object group:
An object group is a container for a group of objects. You define an object group when you want to package related objects so you can copy or subclass them in another module.
Object groups provide a way to bundle objects into higher-level building blocks that can be used in other parts of an application and in subsequent development projects.
For example, you might build an appointment scheduler in a form and then decide to make it available from other forms in your applications. The scheduler would probably be built from several types of objects, including a window and canvas, blocks, and items that display dates and appointments, and triggers that contain the logic for scheduling and other functionality. If you packaged these objects into an object group, you could then copy them to any number of other forms in one simple operation.
You can create object groups in form and menu modules. Once you create an object group, you can add and remove objects to it as desired.
Object Library: n any development environment, you will always have standards to which you want your developers to adhere as well as common objects which can be reused throughout the development effort.
The Object Library provides an easy method of reusing objects and enforcing standards across the entire development organization.
You can use the Object Library to:
n create, store, maintain, and distribute standard and reusable objects.
n rapidly create applications by dragging and dropping predefined objects to your form.
There are several advantages to using object libraries to develop applications:
n Object libraries are automatically re-opened when you startup Form Builder, making your reusable objects immediately accessible.
n You can associate multiple object libraries with an application. For example, you can create an object library specfically for corporate standards, and you can create an object library to satisfy project-specific requirements.
n Object libraries feature SmartClasses-- objects that you define as being the standard. You use SmartClasses to convert objects to standard objects.
A property class is a named object that contains a list of properties and their settings. Once you create a property class you can base other objects on it. An object based on a property class can inherit the setting of any property in the class that makes sense for that object.
Property class inheritance is an instance of subclassing. Conceptually, you can consider a property class as a universal subclassing parent.
There can be any number of properties in a property class, and the properties in a class can apply to different types of objects. For example, a property class might contain some properties that are common to all types of items, some that apply only to text items, and some that apply only to check boxes.
When you base an object on a property class, you have complete control over which properties the object should inherit from the class, and which should be overridden locally.
Property classes are separate objects, and, as such, can be copied between modules as needed. Perhaps more importantly, property classes can be subclassed in any number of modules.
Visual attributes are the font, color, and pattern properties that you set for form and menu objects that appear in your application's interface. Visual attributes can include the following properties:
n Font properties: Font Name, Font Size, Font Style, Font Width, Font Weight
n Color and pattern properties: Foreground Color, Background Color, Fill Pattern, Charmode Logical Attribute, White on Black
Every interface object has a Visual Attribute Group property that determines how the object's individual visual attribute settings (Font Size, Foreground Color, etc.) are derived. The Visual Attribute Group property can be set to Default, NULL, or the name of a named visual attribute defined in the same module.
There are several ways to set the visual attributes of objects:
n In the Property Palette, set the Visual Attribute Group property as desired, then set the individual attributes (Font Name, Foreground Color, etc.) to the desired settings.
n In the Layout Editor, select an item or a canvas and then choose the desired font, color, and pattern attributes from the Font dialog and Fill Color and Text Color palettes.
n Define a named visual attribute object with the appropriate font, color, and pattern settings and then apply it to one or more objects in the same module. You can programmatically change an object's named visual attribute setting to change the font, color, and pattern of the object at runtime.
n Subclass a visual attribute that includes visual attribute properties and then base objects on it that inherit those properties.
n Create a property class that includes visual attribute properties and then base objects on it that inherit those properties.
A ref cursor is a pointer to a server-side cursor variable. It is analogous to a pointer in "C" in that it is an address to a location in memory. The stored procedure returns a reference to a cursor that is open and populated by a SELECT statement to be used as a block datasource.
A stored procedure that uses a reference cursor can only be used as a query block datasource; it cannot be used for DML block datasource. Using a ref cursor is ideal for queries that are dependent only on variations in SQL statements and not PL/SQL.
When deciding whether to use a ref cursor or a table of records, consider that:
n a stored procedure that uses a ref cursor can only be used as a query block datasource
n a stored procedure that uses a table of records can be used as both a query and DML block datasource
PL/SQL Library:
This PL/SQL library contains a function to write out the contents of a block.
TRIGGER:Form Builder recognizes a predefined set of runtime events, each of which has a corresponding built in trigger. When you add code to an application by writing a trigger, it is important to decide what event should fire the trigger. The event you choose determines the name assigned to the trigger.
Interface Events
When selecting triggers, it is important to understand precisely when events occur, both in relation to other events, and in relation to form processing. Some events are external interface events, and their occurrence is immediately apparent. Examples of such events, and their corresponding triggers, include the following:
Event Trigger Name
Pressing a button When-Button-Pressed
Clicking a check box When-Checkbox-Changed
Pressing the Tab key KEY-FN
Internal Processing Events
Internal events occur as a result of runtime processing. These events occur according to the Form Builder processing model.
Consider a form with two blocks, Block A and Block B, with text items in each block. On GUI platforms, operators can move the input focus from a text item in Block A to a text item in Block B by clicking the target item with a mouse. Although this operation involves only one interface action (the mouse-click in the target item), it actually sets off a series of internal processing events, each of which has one or more corresponding triggers:
Event Trigger Name
Validate the item When -Validate-Item
Leave the item Post -Text-Item
Validate the record - When-Validate-Record
Leave the record Post -Record
Leave the block Post -Block
Enter the block Pre -Block
Enter the record Pre -Record
Enter the Item Pre-Text-Item
Ready block for input When-New-Block-Instance
Ready record for input When-New-Record-Instance
Ready item for input When-New-Item-Instance
It is important to understand that navigational events such as "Leave the Item" and "Enter the Block" occur as a result of internal form processing navigation. These events occur as Form Builder validates data in the form and "navigates" through the object hierarchy to move from one item to another.
In the example, to move the input focus from a source item in one block to a target item in another, Form Builder first validates the value in the source item, then "enters the record" to validate all of the items in the record, then leaves the record and "enters the block," and so on, finally ending up in the target item.
The Form Builder processing model enforces the integrity of data at the item, record, block, and form level. The rich assortment of events to which can be responded with trigger code gives complete control over every aspect of an application.
Processes and Sub-Processes A process is a series of individual, related events that occurs during a specific Form Builder Runform operation. The previous example described a navigational process. Other processes involve validation and database transactions. For example, the Post and Commit Transaction process includes a complex series of events and sub-processes.
Difference between POST-QUERY/PRE-QUERY:Query-time triggers fire just before and just after the operator or the application executes a query in a block.
Trigger Typical Usage
Pre-Query Validate the current query criteria or provide additional query criteria programmatically, just before sending the SELECT statement to the database.
Post-Query Perform an action after fetching a record, such as looking up values in other tables based on a value in the current record. Fires once for each record fetched into the block.
Navigational triggers fire in response to navigational events. For instance, when the operator clicks on a text item in another block, navigational events occur as Form Builder moves the input focus from the current item to the target item.
Navigational events occur at different levels of the Form Builder object hierarchy (Form, Block, Record, Item). Navigational triggers can be further sub-divided into two categories: Pre- and Post- triggers, and When-New-Instance triggers.
Pre- and Post- Triggers fire as Form Builder navigates internally through different levels of the object hierarchy. As you might expect, these triggers fire in response to navigation initiated by an operator, such as pressing the [Next Item] key. However, be aware that these triggers also fire in response to internal navigation that Form Builder performs during default processing. To avoid unexpected results, you must consider such internal navigation when you use these triggers.
Trigger Typical Usage
Pre-Form Perform an action just before Form Builder navigates to the form from "outside" the form, such as at form startup.
Pre-Block Perform an action before Form Builder navigates to the block level from the form level.
Pre-Record Perform an action before Form Builder navigates to the record level from the block level.
Pre-Text-Item Perform an action before Form Builder navigates to a text item from the record level.
Post-Text-Item Manipulate an item when Form Builder leaves a text item and navigates to the record level.
Post-Record Manipulate a record when Form Builder leaves a record and navigates to the block level.
Post-Block Manipulate the current record when Form Builder leaves a block and navigates to the form level.
Post-Form Perform an action before Form Builder navigates to "outside" the form, such as when exiting the form.
When-New-Instance-Triggers fire at the end of a navigational sequence that places the input focus on a different item. Specifically, these triggers fire just after Form Builder moves the input focus to a different item, when the form returns to a quiet state to wait for operator input.
Unlike the Pre- and Post- navigational triggers, the When-New-Instance triggers do not fire in response to internal navigational events that occur during default form processing.
Trigger Typical Usage
When-New-Form-Instance Perform an action at form start-up. (Occurs after the Pre-Form trigger fires).
When-New-Block-Instance Perform an action immediately after the input focus moves to an item in a block other than the block that previously had input focus.
When-New-Record-Instance Perform an action immediately after the input focus moves to an item in a different record. If the new record is in a different block, fires after the When-New-Block-Instance trigger, but before the When-New-Item-Instance trigger.
When-New-Item-Instance Perform an action immediately after the input focus moves to a different item. If the new item is in a different block, fires after the When-New-Block-Instance trigger.
Transactional triggers fire in response to a wide variety of events that occur as a form interacts with the data source.
Trigger Typical Usage
On-Delete Replace the default Form Builder processing for handling deleted records during transaction posting.
On-Insert Replace the default Form Builder processing for handling inserted records during transaction posting.
On-Lock Replace the default Form Builder processing for locking rows in the database.
On-Logon Replace the default Form Builder processing for connecting to ORACLE, especially for a form that does not require a database connection or for connecting to a non-ORACLE data source.
On-Logout Replace the default Form Builder processing for logout from ORACLE.
On-Update Replace the default Form Builder processing for handling updated records during transaction posting.
Post-Database-Commit Augment default Form Builder processing following a database commit.
Post-Delete Audit transactions following the deletion of a row from the database.
Post-Forms-Commit Augment the default Form Builder commit statement prior to committing a transaction.
Post-Insert Audit transactions following the insertion of a row in the database.
Post-Update Audit transactions following the updating of a row in the database.
Pre-Commit Perform an action immediately before the Post and Commit Transactions process, when Form Builder determines that there are changes in the form to post or to commit.
Pre-Delete Manipulate a record prior to its being deleted from the database during the default Post and Commit Transactions process; for example, to prevent deletion of the record if certain conditions exist.
Pre-Insert Manipulate a record prior to its being inserted in the database during the default Post and Commit Transactions process.
Pre-Update Validate or modify a record prior to its being updated in the database during the default Post and Commit Transactions process.
Note: This is only a partial list of the transactional triggers available. Many of the triggers not shown here are On-event triggers that exist primarily for applications that will run against a non-ORACLE data source.
Form Builder provides the following predefined packages:Standard Extensions The STANDARD Extensions package contains Form Builder built-in procedures and functions.
TOOL_ENV The TOOL_ENV package allows you to interact with Oracle environment variables.
ORA_NLS The ORA_NLS package enables you to extract high-level information about your current language environment.
TOOL_RES The TOOL_RES package allows you to extract string resources from a resource file.
ORA_FFI The ORA_FFI package allows you to access foreign (3GL) functions.
ORA_DE The ORA_DE is an internal package. Do not use this package.
STPROC The STPROC is an internal package. Do not use this package.
TEXT_IO The TEXT_IO package allows you to read and write information to a file in the file system.
PECS The PECS package allows you to evaluate form performance.
FORMS_OLE The FORMS_OLE package contains Form Builder OLE functions and procedures.
VBX The VBX package contains Form Builder VBX functions and procedures.
Standard The Standard package contains PL/SQL procedures and functions.
Note: PL/SQL also offers some supplied packages, and those procedures can be called from within PL/SQL code in a Forms application. However, any such procedure with a name beginning DBMS_ is available only on the server (not on the client).
Master-Detail Triggers:Form Builder generates master/detail triggers automatically when a master/detail relation is defined between blocks. The default master/detail triggers enforce coordination between records in a detail block and the master record in a master block. Unless developing custom block-coordination schemes, you do not need to define these triggers. Instead, simply create a relation object, and let Form Builder generate the triggers required to manage coordination between the master and detail blocks in the relation.
Trigger Typical UsageOn-Check-Delete-Master Fires when Form Builder attempts to delete a record in a block that is a master block in a master/detail relation.
On-Clear-Details Fires when Form Builder needs to clear records in a block that is a detail block in a master/detail relation because those records no longer correspond to the current record in the master block.
On-Populate-Details Fires when Form Builder needs to fetch records into a block that is the detail block in a master/detail relation so that detail records are synchronized with the current record in the master block.
Message -Handling Triggers:
orm Builder automatically issues appropriate error and informational messages in response to runtime events. Message handling triggers fire in response to these default messaging events.
Trigger Typical Usage
On-Error Replace a default error message with a custom error message, or to trap and recover from an error.
On-Message To trap and respond to a message; for example, to replace a default message issued by Form Builder with a custom message.
REPORT
FLEX MODE :
On: child objects cannot be moved outside their enclosing parent objects.
Off: child objects can be moved outside their enclosing parent objects.
A placeholder is a column for which you set the datatype and value in PL/SQL that you define. You can set the value of a placeholder column in the following places:
n the Before Report Trigger, if the placeholder is a report-level column
n a report-level formula column, if the placeholder is a report-level column
n a formula in the placeholder's group or a group below it (the value is set once for each record of the group)
A formula column performs a user-defined computation on another column(s) data, including placeholder columns. Note
A summary column performs a computation on another column's data. Using the Report Wizard or Data Wizard, you can create the following summaries: sum, average, count, minimum, maximum, % total. You can also create a summary column manually in the Data Model view, and use the Property Palette to create the following additional summaries: first, last, standard deviation, variance.
Note: For group reports, the Report Wizard and Data Wizard create n summary fields in the data model for each summary column you define: one at each group level above the column being summarized, and one at the report level. For example, if a report is grouped by division, and further grouped by department, then a summary column defined for a salary total would create fields for the sum of salaries for each division and each department group (group-level summaries), and the sum of all salaries (report-level summary).
SYTEM PARAMETER:
BACKGROUND Is whether the report should run in the foreground or the background.
COPIES Is the number of report copies that should be made when the report is printed.
CURRENCY Is the symbol for the currency indicator (e.g., "$").
DECIMAL Is the symbol for the decimal indicator (e.g., ".").
DESFORMAT Is the definition of the output device's format (e.g., landscape mode for a printer). This parameter is used when running a report in a character-mode environment, and when sending a bitmap report to a file (e.g. to create PDF or HTML output).
DESNAME Is the name of the output device (e.g., the file name, printer's name, mail userid).
DESTYPE Is the type of device to which to send the report output (screen, file, mail, printer, or screen using PostScript format).
MODE Is whether the report should run in character mode or bitmap.
ORIENTATION Is the print direction for the report (landscape, portrait, default).
PRINTJOB Is whether the Print Job dialog box should appear before the report is run.
THOUSANDS Is the symbol for the thousand's indicator (e.g., ",").
DATA LINK:
Data links relate the results of multiple queries. A data link (or parent-child relationship) causes the child query to be executed once for each instance of its parent group. When you create a data link in the Data Model view of your report, Report Builder constructs a clause (as specified in the link's Property Palette) that will be added to the child query's SELECT statement at runtime. You can view the SELECT statements for the individual parent and child queries in the Builder, but can not view the SELECT statement that includes the clause created by the data link you define.
General rule, any processing that will affect the data retrieved by the report should be performed in the Before Parameter Form or After Parameter Form triggers. (These are the two report triggers that fire before anything is parsed or fetched.) Any processing that will not affect the data retrieved by the report can be performed in the other triggers.
Report Builder has five global report triggers. You cannot create new global report triggers. The trigger names indicate at what point the trigger fires:
Before Report Fires before the report is executed but after queries are parsed.
After Report Fires after you exit the Previewer, or after report output is sent to a specified destination, such as a file, a printer, or an Oracle Office userid. This trigger can be used to clean up any initial processing that was done, such as deleting tables. Note, however, that this trigger always fires, whether or not your report completed successfully.
Between Pages Fires before each page of the report is formatted, except the very first page. This trigger can be used for customized page formatting. In the Previewer, this trigger only fires the first time that you go to a page. If you subsequently return to the page, the trigger does not fire again.
Before Parameter Form Fires before the Runtime Parameter Form is displayed. From this trigger, you can access and change the values of parameters, PL/SQL global variables, and report-level columns. If the Runtime Parameter Form is suppressed, this trigger still fires. Consequently, you can use this trigger for validation of command line parameters.
After Parameter Form Fires after the Runtime Parameter Form is displayed. From this trigger, you can access parameters and check their values. This trigger can also be used to change parameter values or, if an error occurs, return to the Runtime Parameter Form. Columns from the data model are not accessible from this trigger. If the Runtime Parameter Form is suppressed, the After Parameter Form trigger still fires. Consequently, you can use this trigger for validation of command line parameters or other data.
Matrix Report:
A matrix (crosstab) report contains one row of labels, one column of labels, and information in a grid format that is related to the row and column labels. A distinguishing feature of matrix reports is that the number of columns is not known until the data is fetched from the database.
To create a matrix report, you need at least four groups: one group must be a cross-product group, two of the groups must be within the cross-product group to furnish the "labels," and at least one group must provide the information to fill the cells. The groups can belong to a single query or to multiple queries.
