|Oracle E-Business Suite Developer's
Part Number E22961-14
This section provides you with information you need to define all your database and form objects. It provides naming standards and header information for all your objects and files.
The naming standards are grouped into the following sections:
In general, make names meaningful and brief. Do not use generic, all-purpose phrases like "COMMON", "MISC", "OTHER", or "UTILITY" in the name.
In addition to specific naming conventions for particular objects, all database objects should be named without using any special characters. Database object names should use only ASCII letters, numbers, and underscores, and they should always begin with a letter. Note that database object names are case-insensitive, so "Name" would be the same as "NAME".
Include header information when you create your objects. The header should include the following documentation
Special usage notes
Special usage notes
DD-MON-YY J. Doe Created
prod is the product short name, and objects is the name of the objects stored in the table and should be plural. The table name should be 20 characters or less. It can be longer, but you will need to abbreviate it for the table handler package name, which must be 24 characters or less.
|Standard||table_V or table_criteria_V|
table is the name of the root table the view is based on. The criteria is a qualifier of the objects shown by the view. Use the criteria qualifier if using table name alone is not unique, the view is based on a join of 2 or more tables, the view contains a WHERE clause, or the view is unusual.
table is the name of the table on which the trigger is based, and i is a unique ID starting at 1.
Your synonym should have the same name as the table or view it is based on.
Using two different names (the synonym name and the underlying object name) is confusing. If you change object names, you should clean up your code instead of creating synonyms.
|Check||Use Message Dictionary message naming standards.|
table is the name of the table on which the constraint is created, while i is a unique id starting at 1. You should name all of your constraints so that you can enable or disable them easily.
|Standard||prod_module or prod_description|
prod is the product short name, module is a functional module, and description is a one or two word explanation of the purpose. Stored package names should be 24 characters or less. For library packages, your package should be unique within 27 characters. Wrapper packages use a three character prefix. Select a description that helps simplify the names of procedures in the package.
verb_noun is a brief explanation of the purpose. Do not reuse the product short name or any part of the package name in the procedure name. Remember that you will invoke the procedure as package procedure. For example, if the package name is APP_ORDER_BY, then the procedures should simply be named APPEND and REVERT. Be careful you don't name your package procedure a SQL, PL/SQL, Oracle Forms, or other reserved word, or redefine an Oracle Forms built-in.
table is the name of the table on which the package acts (to insert, update, delete, or lock a record, or to check if a record in another table references a record in this table). The package name should be 24 characters or less.
package is the name of the owning package.
prod is the product short name, and verb_noun is a brief explanation of the purpose.
|Standard||variable or X_variable|
variable should be a logical, meaningful, and concise name. Precede variable name with X when the variable is used in a SQL statement, so that there is no possibility of conflicts with database object names or confusion as to which are PL/SQL variables and which are database objects.
variable should be a logical, meaningful, and concise name. Precede variable name with G to distinguish global variables from local variables.
In general, objects that can show multiple items (record groups, LOVs, etc.) should have plural names, while singular objects (modules, blocks) have singular names.
Your form module name should match your form file name. For example, if a form is called POXPOMPO.fmb, make sure the Module Name (visible in the Designer) is POXPOMPO. This is especially important if you reference objects from your form. ZOOM also relies on the Module Name being correct.
object is the name of the object that the record group contains.
prod is the product short name, and variable is the name you would normally give to the variable.
Use logical, meaningful, and concise names. Note that table columns based on LOOKUP_CODES should have a "_CODE" or "_FLAG" suffix, and the displayed meaning item should have the same name but without the suffix.
Mirror Items use the name of the item plus a "_mir" suffix. So if the item in the detail portion is "ename", name the mirror-item "ename_mir".
|Standard||case_short_name or object|
case_short_name is the CASE block short name, and object is the name of the objects in the block. The block name should be 14 characters or less.
|Block containing toolbar||TOOLBAR|
|Block containing control items||CONTROL|
|Block containing display-only, context info||CONTEXT|
|Blocks to submit concurrent requests||program or report|
|Non-database blocks (such as search blocks)||action or action_object|
If the block is shared with other forms, make the block name unique by preceding it with the name of your form.
object is the name of the object shown on the canvas.
The region field belong to block. region describes the fields shown in the region. For example, a block LINES has two alternative regions, one showing price information (base price, discounted price, total price) and the other showing account information. The alternative region stacked canvases are named LINES_PRICE and LINES_ACCOUNT.
To distinguish windows, blocks and canvasses used for Find Windows, prefix the object name with "QF_".
object is the name of the object shown in the window.
object is the name of the object shown in the LOV.
ORDER_SALESREPS, LINE_SALESREPS, FREIGHT_CODES
|Standard||object or object_criteria|
object is the name of the objects in the record group, usually the same as the basic item or LOV name. criteria is a brief description of why specific objects are included in the record group. Use the criteria description only if using object name alone is not unique. Abbreviate the object name or criteria description if object_criteria exceeds 30 characters.
To distinguish between LOVs and record groups used for entry from those used for querying purposes (such as Find Windows), prefix the object name with "QF_". For example, QF_FREIGHT_CODES, QF_DEMAND_CLASSES.
To distinguish the LOVs and record groups invoked when pressing KEY-MENU in an alternative region, append _REGIONS to the block name.
master is the name of the master block in the relation, and detail is the name of the detail block in the relation.
|Package||block or form|
|Item Handler Procedure||item|
block is the name of the block owning the items, form is the name of the form, and item is the name of the item on which the item handler procedure acts.
block is the name of the combination block.
All file names must be no greater than 8 chars in length plus a three character extension (FILENAME.ext). The files names must be all caps except for the extension. This will provide a consistent naming scheme across all platforms.
|Standard||pppggxxx.fmb, pppggxxx.fmx, or pppggxxx.fmt|
ppp is the two or three character product short name, g is a two-character abbreviation for the functional group, and xxx is a three-character abbreviation for the explanation of the purpose.
fmb is the suffix for the source binary file, fmx is the suffix for the executable binary file, and fmt is the suffix for the source text file. The files reside in $prod/forms/US (or the platform equivalent).
The APPSTAND form provides many standard settings and components that other forms reference in. Particular applications and functional groups may create their own standard form that they use for reference.
The naming convention of these APPSTAND equivalents is:
PPP is the two or three character product short name, such as OE for Order Entry (OESTAND) or GL for General Ledger (GLSTAND).
Note that PL/SQL packages and procedures are documented slightly differently: Packages do not have Arguments sections and procedures do not need to have History sections.
Begin all SQL and PL/SQL files with the following lines (after the copyright header):
SET VERIFY OFF WHENEVER SQLERROR EXIT FAILURE ROLLBACK;
End all SQL and PL/SQL files with the following lines:
|Standard||pppgxxxs.pls or pppggxxb.pls|
ppp is the two or three character product short name, g is a one-character abbreviation for the functional group, and xxx is a three-character abbreviation for the explanation of the purpose. If you do not need three characters for that purpose, you may use two characters for the functional group. s indicate a specification file, and b indicates a body file. Each file defines only one package specification or body. The files reside in $prod/install/sql (or the platform equivalent).
|Standard||pppgixxs.pls and pppgixxb.pls|
i indicates (table) "interface."
|Standard||pppggxxx.pll, pppggxxx.plx, and pppggxxx.pld|
The files reside in $prod/plsql and, for run-time, in $au/plsql (or the platform equivalent).
pp is the two-character product short name, and xxxxxx is an icon name up to six characters long. The files reside in $TK2_ICON (or the platform equivalent).
PPP is the two or three character product short name, GG is an abbreviation for the functional group, and XX is an abbreviation for the specific functionality. S indicate a specification file, and B indicates a body file.
In addition to all words reserved by the Oracle database, PL/SQL, and Oracle Forms, do not use any words that begin with the following letters (including the words themselves):
Copyright © 1995, 2016, Oracle and/or its affiliates. All rights reserved.