Technical Coding Standard Document

Technical Coding Standard Document
Version 1.0
1 of 43
TABLE OF CONTENTS
Revision History ..........................................................................................................................................................4
Objective .....................................................................................................................................................................5
Guiding Principles .......................................................................................................................................................5
Development Deliverables ..........................................................................................................................................7
The Development Environment ..................................................................................................................................8
Customization/Enhancement Approach ............................................................................................................................... 8
Unix Host Environment ....................................................................................................................................................... 8
Custom Database Schemas .................................................................................................................................................. 9
Custom Tables ..................................................................................................................................................................... 9
Custom Packages and Triggers4 .......................................................................................................................................... 9
Registering Custom Programs ............................................................................................................................................. 9
Customized Code and Objects Registering ........................................................................................................................ 10
Fusion Middleware Development .............................................................................. Error! Bookmark not defined.
Oracle – B2B ....................................................................................................................... Error! Bookmark not defined.
SOA BPEL Process .............................................................................................................. Error! Bookmark not defined.
BAM Reports/Alerts ............................................................................................................. Error! Bookmark not defined.
Interface Development using VGT Interface Framework ........................................................................................ 11
VGT Interface Framework ................................................................................................................................................. 11
Visual Source Safe .................................................................................................................................................. 11
Naming Standards for VGT Custom application ..................................................................................................... 13
File – Code ........................................................................................................................................................................ 13
File – Data ......................................................................................................................................................................... 15
Database Object ................................................................................................................................................................ 15
Workflow Objects ............................................................................................................................................................... 17
AOL Object ........................................................................................................................................................................ 18
Database Objects Creation Standards .................................................................................................................... 19
Tables................................................................................................................................................................................. 19
Views .................................................................................................................................................................................. 21
Packages/Procedures/Functions........................................................................................................................................ 21
Programming Standards .......................................................................................................................................... 22
PL/SQL .............................................................................................................................................................................. 22
Oracle Forms ..................................................................................................................................................................... 25
Oracle Reports ................................................................................................................................................................... 25
SQL*Loader....................................................................................................................................................................... 26
Shell programs ................................................................................................................................................................... 27
Program Headers & Installation scripts ........................................................................................................................... 28
General Guidelines .................................................................................................................................................. 30
Date Format....................................................................................................................................................................... 30
Utilities to Debug, Trace and Tune & other tips ............................................................................................................... 30
Maintenance / Upgrades .................................................................................................................................................... 30
Guidelines for Conversions/Interfaces..................................................................................................................... 31
Conversions ....................................................................................................................................................................... 31
Interfaces ........................................................................................................................................................................... 31
Version 2.0 Created by VGT for VGT, For internal use only
2 of 43
Technical Turnover Document
SQL PERFORMANCE AND TUNING .......................................................................................................................................... 32
Objective: ........................................................................................................................................................................... 32
Access/Security Requirements: .......................................................................................................................................... 32
Steps to prepare performance statistics document: ........................................................................................................... 32
Development Guidelines for Efficient SQL and programs: ............................................................................................... 40
Tips for Efficient SQL and programs:................................................................................................................................ 40
Version 1.0
3 of 43
Revision History
Document Modifications
No Author Date Section Change Description
1 Venkat Peramaneni 18-APR- Created initial version 1.0

2014
Version 1.0
4 of 43
Objective
The objective of this document is to provide development standards to generate and maintain source
code. Please note that though this and the following sections focuses more on development for Oracle
Applications.
By adopting this method VGTwill achieve the following:
1. Standardization on source code development within VGT.
2. Ease in maintenance of source code
3. Ease in Quality Assurance
4. Insure that modifications meet the users' requirements
5. Complete and easily understood documentation
6. Facilitate the transfer of responsibility for code maintenance to the VGTinternal technical support staff
Guiding Principles
Functional changes should not involve modification of ‘off-the-shelf’ code
Functional changes to Oracle Applications should never change core functionality. The standard
functions built into the software should always remain unchanged. If a standard form or report must be
modified, it should be copied to the custom application directory, modified, and then registered under the
custom application. The menu should then be modified to call the new version of the form or report. The
original program should remain in its original location.
Customizations1or enhancements2 must be protected during upgrades

All custom code is stored in a separate directory from production code, even if it is a modification of a
standard program. Likewise, custom tables and lookup codes are created in a separate Oracle user
account XXVGT. You define custom menus and responsibilities to access the custom modules.
Upgrades to the standard product affect only the standSard production code and database objects.
Customizations and enhancements must be easy to re-install

Installation scripts and detailed instructions allow modifications to be easily reinstalled in a new
environment or at another site. This is especially important when modifications are part of a global
solution in a multi-site implementation.
Customizations and enhancements must be thoroughly tested

Unit and integration test plans are prepared during the design stage of a modification. This allows the
design reviewer to confirm that the testing will validate all required functionality before coding is even
started. It is also a useful crosscheck for the developer during the coding phase.
A DBA/Developer other than the code developer will do the code reviews and standards for any of the
modifications. Before the customization is considered complete, users are required to retest the
modification after installation.
1Customization – any direct modification to standard Oracle code. VGT objective is to not perform any
customizations.
2 Enhancements – any RICE item. No modification of standard Oracle code.
Version 1.0
5 of 43
Code adheres to development standards

Standards that should always be followed are:
1. All the forms and reports which are developed should always be multi lingual compliant as this
implementation is being done in many languages other than English.
2. Comment standards.
3. Application Object Library development standards.
4. Source Code Control Standards (SVN), as the project’s strategic direction for source control,
should be used whenever possible.
5. The Korn shell should be used whenever possible. Korn shell scripts will be given the extension
.ksh except for Oracle concurrent programs executed as shell programs. Oracle applications do
not expect an extension for a shell program.
6. Assume Cost based optimizer
7. SQL Loader jobs will be scheduled via concurrent manager
Exceptions include:
1. PL/SQL will be used whenever possible. Where functionality or performance is an issue,
programs may be written in other languages.
2.
In general, any time custom work deviates from the accepted standards, make sure that any
differences are justified. If the deviation is in source code, indicate the differences and reasons
with comments.
Version 1.0
6 of 43
Development Deliverables
Development
Design Reviews Code Reviews
Standards
Check in Code
Requirement
Deliverables
Reviews
Unit Test & Results
Technical
Specification
String Test
Functional
High Level Design Installation
Specification
Instructions
Low Level Design Installation Scripts
Migration Package
Defect Fixes
Design Development
Test
User Procedures
Project Requirements Implementation Maintenance
Selection
Requirements Development Process
Processes
Requirements Management Process
Supplier Agreement Management
Code Migration Process
Code Configuration Management
Defect Tracking Process
Environment Change Control Process
Version 2.0 Created by VGT for VGT, For internal use only
7 of 43
The Development Environment
Customization/Enhancement Approach
One custom application top $XXVGT_TOP will be created for customizations to all modules. Code in standard
application directories may not be modified
Unix Host Environment

In Oracle Applications terminology, batch programs and reports are collectively referred to as “Concurrent
Programs”. Concurrent programs are executed on the Unix Host by the Concurrent Manager facility.
The “applmgr” user owns concurrent programs files. This is the user that runs all concurrent manager processes
and concurrent programs.
The custom application files and directories will be managed by the Oracle Applications DBA.
Directories
Table 1 lists the directories that will be created under the XXVGT_TOP directory and the types of files that will be
stored in each.
Directory Contents
Name
bin Executable code of concurrent programs written in a 3GL such as C.

Unix Shell Scripts. SQL*Loader Control Files (.ctl files).
install Installation/migration scripts
Interface/inbou Inbound data files
nd
Interface/outbo Outbound data file
und
out Any output files
log Log files
patch Contains all the source code
mesg Base language and translated message files.
Forms/XX3 Custom Forms (XX is the language code)
Reports/XX Concurrent programs written with Oracle Developer Reports (XX is the
language code)
/usr/tmp Temporary directory
resource Directory for custom libraries
$JAVA_TOP/X All the custom Java class files
XVGT
Table 1 - Server-Side Concurrent Program File Directories

The sub-directory structure of custom Java directory will be same as standard Oracle Java sub-directory
structure. If a standard Oracle java class needs to be modified, it should be copied to custom directory and
modified. Java class path on Application server should have custom java directory as a first entry.
3 XX is defined by Oracle on column/table LANGUAGE_CODE/FND_LANGUAGES

Version 2.0 For internal use only
8 of 43
Custom Database Schemas
Custom Tables4
New tables required by custom programs should be created in an Oracle user created exclusively for
customizations. For convenience, it should match the application short name of your custom application
(XXVGT). Grants and synonyms will allow other Oracle users to access your custom tables. To access
custom forms exclusively, you must register the custom Oracle ID ‘XXVGT’ in the Application Object
Library. If custom forms will be accessed from responsibilities that also access standard forms, simply
create grants and synonyms so that the Oracle user associated with the responsibility can access the
custom tables.
Custom Packages and Triggers4

All the Custom Packages will be owned by ‘APPS’.
Registering Custom Programs

All programs must be registered in order to be executed in the concurrent manager. Once a concurrent
program or report has been registered it does not need to be reregistered after a modification.
Concurrent Programs Execution methods of Host, PL/SQL Stored Procedure, Oracle Reports,
SQL*Loader and SQL*Plus will be attached to Request Sets and executed through the Concurrent
Manager.
Define Concurrent Program Executable (Concurrent=>Program=>Executable)

Execution File Name needs to be entered exactly as the file name located in the XXVGT_TOPsub-directory.
Based on the entered “Application” and “Execution Method” the system determines where to look for the file
named in the “Execution File Name” field.
Follow Standard Naming convention rules
Define Concurrent Program Definition(Concurrent=>Program=>Definition)

Define the program Name and Description that will be referenced when running Concurrent Requests. Program
Definition is based on the executable file.
Follow Standard Naming convention rules.
4 Custom tables and packages and triggers can be setup by the development team in the development
environment. If you need assistance setting this up in a development environment contact your friendly DBA.
Installation scripts will need to be written and reviewed by Applications Lead in order to migrate to a test
environment.
9 of 43
Registering Custom Forms
Do not need to define Concurrent Program Executable or Definition.

1. Custom Form needs to be Registered.
Responsibility- Application Developer=>Application=>Form
Follow Standard Naming Convention rules
2. After Registering the Form, a Function needs to be “registered”.

Responsibility- Application Developer=>Application=>Function
Follow Standard Naming Convention rules
3. After creating the custom function, a new Menu Item needs to be defined for the function.
Responsibility- Application Developer=>Application=>Menu
Customized Code and Objects Registering

Objective
To keep the standard Oracle Applications objects separate from the custom objects.
Procedure:
All custom objects should be moved to the custom $XXVGT_TOPdirectory. There are sub-directories for
all of the object types.
All custom objects i.e. tables, database packages, triggers, menus, reports, forms, views, and sequences
should be registered under VGTCustom Applicationapplication name. This is done for Database and
Form objects through the Application Developer Responsibility.
Custom reports will appear in the Application in the same screen as the” Standard” reports, but the code
will reside in $XXVGT_TOPdirectory. When an existing standard report requires modification, a clone of
the report should be made and the name of the report should be included in the custom report name (see
example below. The new report should then be renamed with a VGT- naming convention. The VGTtitle
will help identify the report as custom report.
For example, if a standard report INVIDITM.rdf. The new custom report will be
XXVGT_INVIDITM_<DESCRIPTION>.rdf.
Following are the steps for the same.

1. Register concurrent program executable under 'VGTCustom Application' application.
2. Register the program under the 'VGTCustom Application' application.
3. Add the modified or custom program to a request group.
10 of 43
Interface Development using VGT Interface Framework

VGT Interface Framework
 VGT Interface Framework is a bundle of application created by VGT team which enables interface by
providing a single interface for importing or exporting different file formats and providing error
handling form for any kind of interface.
 Multiple interfaces for VGT have been designed using VGT Interface Framework. Forecast upload,
Firm Work Order Upload, Trade Management Offers Upload, Lockbox, Item Notes upload, Freight
rates upload , GL Paychex interface have been developed using VGT Interface Framework tool.
 This tool is accessible using the “Oracle Interface Admin” responsibility.
 Any modification to this tool should be done only after contacting VGT team to understand the
implications of the modification.
 The details of VGT Interface Frameworkwill be dealt in the “VGT Interface Framework” spec.
Visual Source Safe

All the source code is checked into Visual Source Safe under Production directory. Following
are the directories in the source control under Production Directory:
Directory Contents
Name
FSD
install Installation/migration scripts
Concurrent Concurrent Programs Schedule
Programs
Schedule
Patch/115/imp All the LDT files including the WFT files except the JTF Grid ldts
ort/ XX
Patch/115/jtfgri All the JTF Grid Ldts
d
Patch/115/odf Table, Sequence, Synonym and Index scripts
Patch/115/sql All the custom views, package spec, package body,procedures, any
miscellaneous functions.
Patch/115/form Custom Forms (XX is the language code)
s/XX5
Patch/115/repo Custom Oracle Developer Reports (XX is the language code)
rts/XX
Patch/115/publ All the XML Publisher code like RTF templates, Data XML templates
isher and Bursting control files
Patch/115/sub All the Business event subscriptions
scriptions
Patch/115/spe Functional Specs along with the Technical Specs
cs
5 XX is defined by Oracle on column/table LANGUAGE_CODE/FND_LANGUAGES

11 of 43
Directory Contents
Name
Technical Technical Implementation details like Standards , development process

Turnover followed during the course of the implementation
Document
Naming Convention used for source control:
Object Type Visual Source Safe Naming Convention
Alerts alr_<Alert code>.ldt

Concurrent Program cp_<Concurrent program short name>.ldt
Form definition frm_<Form Short Name>.ldt
Interface File Definition ifd_<interface file definition code>.ldt
Lookups lku_<Lookup Type>.ldt
Menu mnu_<Menu Short Name>.ldt
Forms Personalizations per_<Form Short Name>.ldt
Profile Options prf_<profile option code>.ldt
Request Groups rg_<Request Group Code>.ldt
Request Set rs_<Request Set Cde>.ldt
Request set Links rsl_<Request Set Links>.ldt
Responsibilities rsp_<Resonsibility Key>.ldt
User usr_<user name>.ldt
Value sets vs_<value set code>.ldt
Workflow wft_<Workflow code>.ldt
XML Publisher Definition xdo_<XML Publisher code>.ldt
Forms XXVGT_<Description>.fmb
Java XXVGT<Description>.java (No Underscores or special characters
allowed)
JTF grids <Grid Short Name>.ldt
Odfs <DB Object Name>.sql
Bursting Control File BURSTING_FILE_<Application Short Name>_<LOB Code>.xml
Data Template XML DATA_TEMPLATE_<Application Short Name>_<LOB Code>.xml
RTF Template TEMPLATE_SOURCE_<Application Short Name>_<LOB Code>.rtf
SQL <DB Object Name>.sql
/Package/Procedure/Functi
on
Views <DB Object Name>.vw
Subscriptions XXVGT_<description>.wfx
Specs <Description>.docx

12 of 43
Naming Standards for VGTCustom application

File – Code
 File Name should not contain any special characters i.e. “ ”, -, $, %, #, @, * and others.
 Following holds true for the VGTcustom application
Program Directory File Exten Name

Type Type sion
Custom
Extension:

13 of 43

Type Type sion
Package $XXVGT_TOP/patch/11 Package pks XXVGT_<COPIED

5/sql specificatio OBJECT6>_<DESCRIPTION>.pkb.
n
Package pkb XXVGT_<COPIED

body OBJECT>_<DESCRIPTION>.pkb.
SQL*Loader $XXVGT_TOP/bin Control file ctl XXVGT_<DESCRIPTION>.ctl.
Oracle Forms $XXVGT_TOP/patch/11 Binary fmb XXVGT_<COPIED

5/forms/US OBJECT>_<DESCRIPTION>.fmb.
$XXVGT_TOP/ Executable fmx XXVGT_<COPIED

OBJECT>_<DESCRIPTION>.fmx.
forms/US
Reports $XXVGT_TOP/ Binary rdf XXVGT_<COPIED

OBJECT>_<DESCRIPTION>.rdf.
reports/US
Shell script $XXVGT_TOP/bin Shell NONE XXVGT_<DESCRIPTION>. No

scripts extension.
Views $XXVGT_TOP/patch/11 SQL Vw/sql XXVGT_<COPIED

5/sql scripts OBJECT>_<DESCRIPTION>.vw.
SQL $XXVGT_TOP/sql SQL sql XXVGT_<COPIED

Programs programs OBJECT>_<DESCRIPTION>.sql.
Procedures $XXVGT_TOP/sql Procedure prc XXVGT_<COPIED

OBJECT>_<DESCRIPTION>.prc.
SQL Scripts $XXVGT_TOP/sql SQL tab XXVGT_<DESCRIPTION>.tab.

(tables) scripts
SQL Scripts $XXVGT_TOP/sql SQL ind XXVGT_<DESCRIPTION>.ind.

(indexes) scripts
SQL Scripts $XXVGT_TOP/sql SQL seq XXVGT_<DESCRIPTION>.seq.

(sequences) scripts
SQL Scripts $XXVGT_TOP/admin/s SQL syn XXVGT_<DESCRIPTION>.syn.

(synonyms) ql scripts
6<COPIED OBJECT> should be used for objects that are copies of standard Oracle objects. Objects that are not
copied will not contain this parameter in the naming convention.
14 of 43

Type Type sion
Oracle $XXVGT_TOP/sql Workflow wft XXVGT_<COPIED

Workflow files OBJECT>_<DESCRIPTION>.wft.
Custom Java $XXVGT_TOP/java Java Code class XXVGT_<COPIED

OBJECT>_<DESCRIPTION>.class.
CUSTOM.pll $AU_TOP/resource CUSTOM. pll CUSTOM.pll (This file will be soft

Library pll linked from $AU_TOP/resource)
Custom Web $ XXVGT_TOP / HTML htm XXVGT_<COPIED

Pages Code OBJECT>_<DESCRIPTION>.htm.
html/XX is the language
code
File – Data
 In the file name (except the extension) wherever English alphabet letters are used they should be in
UPPERCASE.
 File Name should not contain any special characters i.e. “ ”, -, $, %, #, @, * and others.
Type Directory File Exten Name

Type sion
Data file $ XXVGT_TOP/inbound Data input Csv/txt XXVGT_<DESCRIPTION>_<MMDD

file YYYYHHMMSS>.csv/.txt
Data file $ XXVGT_TOP Data Csv/txt XXVGT_<DESCRIPTION>_<MMDD

/outbound output file YYYYHHMMSS>.csv/.txt
Log file $ XXVGT_TOP Log file Log XXVGT_<DESCRIPTION>>_<MMDD

/data/log YYYYHHMMSS>.log.
Database Object
A database schema can be composed of various objects i.e. tables, indexes, sequences, views,
synonyms, procedures, triggers, packages and functions and database links. Please ensure the following
naming convention is followed.
Object name can be a maximum of 30 characters long, ideally no more than 15 to 20 characters. The
name should start with XXVGT_The naming convention should facilitate in distinguishing the objects.
The norm to adopt is as follows

15 of 43
Object Type Standard Meaning Example
Table XXVGT_COPIEDOBJECT_DE
SCRIPTION
Index “Xn” X=(U)nique or (N)on- XXVGT

Unique COPIEDOBJECT_DESCRIPTI
ON _Xn
n=Index Sequence Number
View “V” V = View XXVGT_

COPIEDOBJECT_DESCRIPTI
ON_V
Sequence “S” S = Sequence XXVGT_

ON_S
Trigger “TRG” TRG=Trigger XXVGT_COPIEDOBJECT_DE

SCRIPTION _xyz_TRGn
x=”B” Before
“A” After
y=”U” Update
“I” Insert
“D” Delete
z=”S” Statement
“R” Row
n =Sequence Number
Package “PKG” PKG=Package XXVGT_

Specification/Body COPIEDOBJECT_DESCRIPTI
ON_PKG
Function/ Should Not Be Used XXVGT_

Procedure
ON
Synonym Samename as the

databaseobject for which the
synonymiscreated.
Constraints “CC” NN = Not Null XXVGT_

N = Null COPIEDOBJECT_DESCRIPTI
UNQ = Unique ON _CC_COLUMNNAME

16 of 43
PK= Primary Key
FK=Foreign Key
CHKn=Condition Check
n = SequenceNumber
 Object name should not contain any special characters i.e. “ ”, -, $, %, #, @, * and others.
 Object name should be unique within the namespace or schema.
 Object name nomenclature should be self explanatory, having a meaningful name that is understandable by
the end users and IS groups
Workflow Objects
In order to isolate custom objects (Item Types, Item attributes, lookup types etc.) within a workflow, it is important
to have a naming standard for workflow objects too.
Object Type Standards Meaning Example
Item Type – 30 characters Internal name of the XXVGT_<COPIED

Internal Name workflow OBJECT>_<DESCRIPTION>.
Item Attributes – 30 characters Internal name of Item XXVGT _<DESCRIPTION>.

Internal Name attribute
Lookup types – 30 characters Internal name of Lookup XXVGT_<DESCRIPTION>.

Internal name type
Lookup codes – 30 characters Internal name of Lookup XXVGT_<DESCRIPTION>.

Internal name code
Messages – 30 characters Internal name of the XXVGT_<DESCRIPTION>.

Internal name message
Activities – 30 characters Internalname of the XXVGT_<DESCRIPTION>.

Internal name activity
Activity attributes 30 characters Internalname of the XXVGT_<DESCRIPTION>.

– Internal name activityattribute
Processes – 30 characters Internalname of the XXVGT_<DESCRIPTION>.

Internal name process

17 of 43
AOL Object

s
Concurrent Program 30 Executable name of the XXVGT_DESCRIPTION.

executable - Executable characters concurrent program
Concurrent Program 30 Short name of the Keep the same name as the
executable – Short Name Characters concurrent program executable.
executable
Concurrent Program – 80 Program Name Meaningful Name.

Program Characters
Concurrent Program – 30 Short name of the XXVGT_ <Description>.

Short name Characters concurrent program
Concurrent Program – 80 Description of the VGT<Description>

Description Characters concurrent program
Value set – Name 30 Description of the value set XXVGT_<DESCRIPTION>.

Characters
Lookup Type 30 Lookup Type XXVGT_<DESCRIPTION>.

Characters
Messages 30 Message Code that will be XXVGT_<DESCRIPTION>.

Characters used by forms, concurrent
programs etc.
Profile Option – Name 30 Internal profile name used b XXVGT_<DESCRIPTION

Characters y the developer
Profile Option – User 80 User profile name VGT<Description>

Profile Name Characters

s
Form 30 Name of form XXVGT_<DESCRIPTION>.

Characters
Form Function 30 Form Function XXVGT_<DESCRIPTION>.

Characters
User Form Function name 30 User function name VGT<Description>.

Characters

18 of 43
User Form Name 30 User Form Name VGT<Description>.

Characters
Database Objects Creation Standards

Define objects with respect to the schema as follows:
Owner Schema Object
Custom Table
Custom Index
Custom Sequence
Custom Grant
APPS Synonym
APPS Views
APPS Package Procedure
APPS Trigger
APPS Link
Tables
 The sequential order in which the columns need to be defined are:-
Primary key columns
Unique key column
Mandatory columns
Optional columns
Long field column
WHO columns
 Ensure that the WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, UPDATE_DATE)
exist.
 Ensure that columns to flag error messages (PROCESSED_FLAG) exist in cases where there is an interface
requirement.
Following are the possible values of processed_flag we will use, to signify what it means:
I : Not Processed/Waiting to be processed

R: Intermediate value used by the program
S : Successfully processed
E : Errored (Failed Validation)
P : Processed by another application
X : Do not process
The interfaces might have different values than the ones mentioned above which will be explained in
the technical document for that interface.
 All in all, ensure that the following columns exist as below.
No. Column Data Type Description
1 RECORD_ID NUMBER (not null) Unique Id of the record
2 CREATED_BY NUMBER (not null) Std. Who columns

19 of 43
3 CREATION_DATE DATE (not null) Std. Who columns
4 LAST_UPDATED_BY NUMBER (not null) Std. Who columns
5 LAST_UPDATE_DATE DATE (not null) Std. Who columns
8 PROCESSED_FLAG VARCHAR(1) not null Process Flag
7 BATCH_ID NUMBER Batch Id
Tables
Table Dos
Columns
1. Qualify the column definition to denote its purpose. For e.g.

_FLAG
_CODE
_TYPE
_DATE
_NAME
_ID
_VALUE
2. Ensure that a primary key exists and is of Number data type
3. Use the following data types to qualify a column in a table VARCHAR2, NUMBER, DATE,
BOOLEAN etc.
4. If the data to be stored in the table is partitioned on the Operating unit then an ORG_ID column
with the default definition must exist. Similarly, if the data to be stored in the table is portioned on
the inventory organization, then an ORGANIZATION_ID must exist.
5. Ensure that the columns are classified as NULL or NOT NULL. By default the column definition is
NULL.
6. Use the constraint/default definitions and referential integrity definitions for the columns of the table
Names
7. Whenever appropriate qualify the table name to denote it’s purpose i.e. 1)_STG (Table that holds
data before been sent out of Apps to other subscribing applications. Table that holds data before
been pushed into the open interface tables for data conversion purposes). 2) _TEMP (Table that
holds temporary data for calculation, any further processing. A table that holds the data after the
initial load from a flat file, which has a combined record, based on multiple tables. For e.g. Vendor
and vendor site records could come in a single record in the flat file and it will be convenient to hold
them in an initial TEMP table before splitting them into multiple STG tables)

20 of 43
8. Register custom tables using AD_DD package, if it needs to be used by Application Object Library
Table Don’ts
General
9. Do not specify storage clause when you create the table unless it is specially required. Only
specify the tablespace name. The table will derive the defaults from the tablespace.
Columns
10. Avoid using Long, if your column length is within 4000 characters. Use Varchar2(4000) instead
11. Do not create columns of type LONG or Long Raw. Use BLOB/CLOB instead
Views
View on a partitioned table needs to be created in the “APPS” schema. Use the WHERE CLAUSE within the view
definition to dynamically partition the data on user access.
Dos
1. Include the ROWID pseudo column of the root table of the select statement as the first
column of the view aliased to “ROWID”
2. If a form is going to use the view as the “base table”, include each column of the foreign
key tables likely to be displayed and/or manipulated by a form into the view.
Packages/Procedures/Functions
Dos
1. Define packages and procedures as far as possible against SQL scripts. You would only use
sql scripts for anything one-off
2. The package specification and body will be in separate files with extension “pks”, “pkb”.
3. If the custom package is based out of a standard package, make sure the changes that are
done are well commented. It needs to be in the following format
/* VGTCustomizations begin */
/* <sysdate> */

21 of 43
/* Comments …..*/
/* VGTCustomizations end */
Don’ts
General
4. Anonymous PL/SQL procedure definitions are not acceptable
Programming Standards
PL/SQL
Dos
General
1. The PL/SQL packages or code written in 3GL must be modular and structured.
2. The PL/SQL design to take into account how to re-commence a terminated job, and not re-
process the processed records unless there is an explicit requirement.
3. Extensive comments need to be incorporated into the code.
4. Source code indentation is essential.
5. If the PLSQL is based out of a standard PLSQL package, make sure the changes that are
done are well commented. It needs to be in the following format
/* <sysdate> */
/* Comments …..*/
SQL Statements
6. Reserved words and key Oracle words to be Capitalized

SELECT
FROM
WHERE

22 of 43
7. Your INSERT statement needs to specify the fields and values. Only one field can be on one
line and only one value can be on one line.
INSERT INTO TABLE table_name
(field1,
field2,
field3)
VALUES
(value1, --field1
value2, --field2
value3); --field3
Cursors
8. Wherever possible use FOR Record in Cursor LOOP rather than OPEN CURSOR statement
9. Cursor to refer to object name(s) on which it is defined and to be initcap. Cursor to be prefixed
with ‘Cur’
Variables/ Parameters
All PL/SQL procedure/function parameters will be prefixed with ‘P_’ so that there is no
10. possibility of conflicts with database object names or confusion as to which are PL/SQL
variables and which are database objects. It will also avoid confusion between local variables
and parameters.
Example: P_header_id
All PL/SQL variables will be prefixed with ‘X_’.
11. Example: X_header_id
All PL/SQL constants will be prefixed with ‘C_’ Example: C_record_count
12.
All PL/SQL Global variables will be prefixed with ‘G_’ to distinguish global variables from local
13. variables.
14. Variable data type declaration to be associated to appropriate schema.object.field

X_Organization_Id mtl_system_items.organzition_id%TYPE;
Procedure Calls
15. Invoke a procedure by passing parameter name and associated parameter value
VALIDATE (P_ORG=> X_ORG, P_SOB=> X_SOB)
Exception Handling
16. Ensure that at least the following exception are handled in the PL/SQL constructs
NO_DATA_FOUND
TOO_MANY_ROWS
OTHERS

23 of 43
Don’ts
General
17. Avoid the use of GO TO
18. Do not include explicit commits within the package. In case the package requires processing
of records that can create rollback segment problem, please put commits at logical transaction
points with SAVEPOINT and ROLLBACK functions.
19. Do not use DBMS_OUTPUT to generate flat files or reports
Triggers
20. Avoid triggers that duplicate the functionality already built in Oracle (example enforce data
integrity by using declarative integrity constraints rather than a DB trigger)
21. Within a trigger DDL statements are not allowed. Also no transaction control statements are
allowed in a trigger (ROLLBACK, SAVEPOINT, COMMIT)
22. Do not have trigger with greater than 60 lines of code. Create PL/sql package instead and call
it from the trigger.
23. SQL statements in a trigger body may not read from or modify (DML) any table of the triggering
statement. This includes the triggering table itself. This will cause “mutating table” error.
24. SQL statements in a trigger body may not read from or modify the primary, unique or foreign
key column of a constraining table of the triggering table.
SQL Statements
25. Do not create insert statements without column names. For e.g. Do not specify the insert
statement in the following way:
INSERT INTO TABLE
VALUES
26. Do not have insert statement with all fields in one line. For e.g. do not write your insert
statement the following way
INSERT INTO TABLE table_name (field1, field2, field3, field4)
Values
(value1, value2, value3,value4)
27. Do not invoke a procedure by passing just parameter values. Do not call the procedure the
following way: VALIDATE (X_ORG,X_SOB)

24 of 43
Oracle Forms
Dos
1. Use the TEMPLATE form to develop new forms
2. Please ensure to populate the WHO columns

Call standard FND_STANDARD.SET_WHO routine in the trigger to set the WHO values
Use standard FND_MESSAGE routines to display and retrieve messages
3.
Always follow Oracle corporation’s FORMS CODING STANDARDS for building custom
4.
forms.
5. Extensive comments are recommended
6. If the custom form is based out of a standard form, make sure the changes that are done are
well commented. It needs to be in the following format
/* <sysdate> */
/* Comments …..*/
/*VGTCustomizations end */
Don’ts
7. Do not modify standard forms. Determine the use of custom.pll before customizing forms
Oracle Reports
Dos
General
1. Unit Test BOTH report display and printing from within the Oracle Applications Framework
2. Instead of writing extensive logic within the report, write a PL/SQL Package and call it within
the report. The advantage is maintenance becomes simple and other programs may use the
same routine.
3. Include P_CONC_REQUEST_ID in the User Parameters
4. In order to debug the report use the SRW.MESSAGE routine
5. If the custom report is based out of a standard report, make sure the changes that are done
are well commented. It needs to be in the following format

25 of 43
/* <sysdate> */
/* Comments …..*/
Triggers7
6. Include the SRWINIT in BEFORE REPORT TRIGGER

Include SRWEXIT in AFTER REPORT TRIGGER
Don’ts
General
7. Do not just test report display and printing from Developer tools. The report output from
developer tools will be VASTLY different to the output from Oracle Applications framework.
8. Avoid any data manipulation (DML) within the report.
Triggers
9. No logic must exist in the After Parameter form. If the logic exists, then move it to the BEFORE
REPORT TRIGGER. The logic should be incorporated after the call to SRWINIT function.
This encapsulates all code in one place.
SQL*Loader
The basic SQLLOAD command is
SQLLOAD or SQLLDR
USERID = Oracle Username/password
CONTROL = Control file name
LOG = Log file name
BAD = Bad file name
DATA = Data file name
DISCARD = Discard file name
DISCARDMAX = Number of discard allowed – default is ‘ALL’
SKIP = Number of records to skip – default is 0
LOAD = Number of records to load – default is ‘ALL’
ERRORS = Number of errors allowed – default is 50
7 Triggers and alerts can be setup by the development team in the development environment. If you need
assistance setting this up in a development environment contact your friendly DBA. Installation scripts will need
to be written and reviewed by DBA in order to migrate to a test environment.

26 of 43
SILENT = Suppress messages during run
Dos
SQLLOAD Command
1. Default # of error records = 50. Set the value to a high value, otherwise processing would stop
once error record reach 50
2. Make sure the log, bad and data options have proper file names with full directory path so that
these files are generated in the correct directory.
3. If the data file is comma delimited, make sure you have the optionally enclosed by ‘”’
statement. This will ensure that the comma will not be treated as a delimiter, whenever comma
is part of a description column. It does need to be ensured that description is enclosed by “ –
double quote. By default, Microsoft Excel encloses Text field with “ when you create a csv file
from a XLS file whenever comma is part of the text field.
FIELDS TERMINATED BY ","
OPTIONALLY ENCLOSED BY '"'
Data Load option
4. Use append ( as against insert or replace ) to load records
CTL file
5. Standard who columns must have a default in the ctl file
Don’ts
SQLLOAD Command
6. Do not hard code the password.
CTL File
7. Do not use “Constant NULL“ to assign null to a column. To set a column to NULL do not
specify the column
Shell programs
Dos
1. All shell programs for ftp-ing files, loading data etc., must be run under the framework of Oracle
applications. It needs to be registered as a concurrent program and executed as one. Our
standard is to run all shell programs as concurrent programs so they can managed centrally.

27 of 43
2. Make the following command part of the first statement in the file
#!/bin/ksh. This is so that the shell will execute as a Korn shell.
Korn shell is a super set of bourne shell. Ksh has the best features of both C shell and Bourne
shell and many features of its own. You can write programs to run faster with ksh than with
either Bourne or c shell.
3. All shell scripts must have a .ksh extension except oracle concurrent programs that are
executed as shell programs.
Program Headers & Installation scripts

A program header is required for the Unix scripts, Installation scripts, SQL*PLUS scripts, PL/SQL Packages
scripts, Procedures scripts, Function scripts, Database Trigger scripts, SQL*LOADER scripts
Dos
1. Make sure there is a header for every program and follows the following example
2. Every installation script must have enough comments to call out what it is doing
3. Every installation script must create a log file to call out what was performed as part of the
installation.
4. Make sure the installation script has “set echo on” and “set feedback on” to display the SQL
that is been executed and to display the results of the SQL command
5. Do not use the WHENEVER SQLERROR CONTINUE statement in any script.
6. Do not specify DROP statements in any scripts. If a table, sequence or an index needs to be
dropped or changed, the DBA group needs to be notified about the change because they want
to evaluate any impacts of drop table statements and changes to table indexes.
7. Use the CREATE OR REPLACE syntax whenever possible. (This includes synonym, package
specification, package body, view, and database trigger scripts).
EXAMPLE:
/* $Header: package_name.pks version date time object_type module $

======================================================================
Copyright (c) 2011 VGT
All rights reserved.
======================================================================
Name: XXVGT_NNNN.pks
Design Reference: XXXNNNN
Program Type: Package Specification

28 of 43
Purpose: Create database objects for the creation of design…
Original Author:
Notes:
History:
=======================================================================
| DATE | Author | Activity
=======================================================================
| DD-MON-YY | Venkat P | Created initial script.
|
|
|
=======================================================================
*/
Installation Scripts
Installation scripts to contain the following details

--
PROMPT ******************************************************
PROMPT Creating Table table_name...
PROMPT ******************************************************
CREATE TABLE statement;
PROMPT ******************************************************
PROMPT Creating sequence...
PROMPT ******************************************************
CREATE SEQUENCE statement;
PROMPT ******************************************************
PROMPT Inserting records into table_name
PROMPT ******************************************************
DEFINE dflt_user_id = -1
DEFINE dflt_date = "'DD-MON-RRRR'"
DEFINE dflt_login = NULL
INSERT INTO statement;
PROMPT ******************************************************
PROMPT Create Grants ...
PROMPT ******************************************************
GRANT statement;
PROMPT ******************************************************
PROMPT Create DB Links ...
PROMPT ******************************************************
Create DB Link statement;
PROMPT ******************************************************
PROMPT Create synonyms ...
PROMPT ******************************************************
CREATE OR REPLACE SYNONYM statement;
29 of 43
PROMPT ******************************************************
PROMPT Create views ...
PROMPT ******************************************************
CREATE ORE REPLACE VIEW statement;
PROMPT ******************************************************
PROMPT Creating package procedure ...
PROMPT ******************************************************
CREATE OR REPLACE PACKAGE PROCEDURE Statement
General Guidelines
Date Format
 Ensure that the input date format conforms to DD-MON-RRRR format on the forms, reports, PL/SQL
packages, SQL and loader scripts. If there are space constraints on the report or constraints placed by
legacy systems in extracting the data in this format, then you could use DD-MON-RR
 If dates are stored in character columns, use a pre-defined format ‘RRRRMMDDHH24MISS’. These
definitions may be in the value set definitions, flexfield definitions, and others.
 Avoid string conversion issues by using the DATE data type. If conversion is required, then explicitly
convert into a pre-defined format of ‘RRRRMMDDHH24MISS’. Do not perform implicit conversion - as the
format may be governed by the NLS_DATE_FORMAT.
Utilities to Debug, Trace and Tune& other tips

 The following non-proprietary utility alternatives may also be used:
 Write to Log: FND_FILE.PUT_LINE(FND_FILE.LOG, ‘ ‘)
 Write to Output: DBMS_OUTPUT.PUT_LINE(‘ ‘)
 FND_MESSAGE in Oracle Forms
 SRW.MESSAGE in Oracle Reports
 EXPLAIN /PLAN in SQL*Plus
 TKPROF for trace files from the Operating System
 Do not perform a function on the table field that is being used in the WHERE clause of a SELECT
statement. This may hit performance, if an index exist on the field
SELECT transaction_type_id
FROM oe_order_headers_all
WHERE order_number = TO_NUMBER(Parameter)
 To understand the meaning of the ORA error messages, you may go to the Operating System prompt
and type in the following:-
Prompt>oerroraerror_message_number
 It is recommended to use the EXIST function instead of the IN function while using correlated/sub-queries.
Maintenance / Upgrades
 If a component (Form/Report/Procedure..) requires changes due to change in the scope, then the approval
and review process has to be followed again for the Requirements document and the Design document.
 Software configuration and revision control tools (e.g., PVCS) are required for storing the various versions
of the components.
 Migration tools when available will be used (e.g., Kintana for Oracle Apps) for moving the components
across various instances (e.g., from development instance to the testing instance).
30 of 43
Guidelines for Conversions/Interfaces

Conversions
The following should be considered while designing conversion components:
 The lifespan of the component (one time execution, once a month, etc..)
 The platform, programming language, database, table names for the source data
 Number of data records being processed
 Nature of data (static, dynamic)
 State of the data (validation, translation, duplicate record removal, timeline for cleaning the data)
 Tools needed to process the data (e.g. SQL*Loader, SmartDB, Webupload, Dataloader etc..)
 Setups that need to be done in the target system
 Dependencies with other conversions
 Validation that need to be done after the component runs to determine if the run was successful
 Processes for Error handling
 Translation Framework
Interfaces
Please refer to the Interface Standards and Guidelines, as well as the Oracle developer Application Standards
document

31 of 43
SQL Performance and Tuning
Objective:
One of the most important challenges faced by oracle developers and administrators is the need to tune SQL
statements. Poorly designed applications can cause issues like 1.excessive CPU consumption (too many
logical I/Os), 2.excessive disk reads as a result of missing indexes 3.excessive contention for shared
resources.
This section of the standards document lays out the guidelines to be followed to identify and avoid poor
performing SQL’s as well as some tips to be followed to write optimal SQL based programs.
Access/Security Requirements:
1. Developer database accounts should have full access to table PLAN_TABLE in development instances.
2. Developer database account should have ALTER SESSION privileges so that they can run following
command
ALTER SESSION SET sql_trace=TRUE
3. Developer UNIX accounts should have privileges to run 'tkprof' utility on development UNIX servers.
4. Developers UNIX accounts should have read access to the directory and trace files on development
UNIX servers.
Steps to prepare performance statistics document:

1. For all in-house developed custom applications / programs that have SQL or PL/SQL generate a trace file
for the entire program and run tkprof utility against it. Both raw trace file and tkprof file should be
attached to ‘xxxx.xx Rice Description PS.Doc’ as files. TKPROF stands for transient kernel profiler. A
trace file should be generated and tkprof command should be used to generate a tkprof file.
a. Following are the steps that will help in generation of trace files for various types of programs.
i. If it is a concurrent program (Report / PL SQL Interface), go to the concurrent program
definition screen and check the ‘Enable Trace’ check box. This will generate the trace file
in the user dump directory each time this concurrent program is run (please uncheck the
option enable trace before the concurrent program is migrated to other environments).

32 of 43
Run the concurrent program and use the Request ID in the following SQL statement to
identify the trace file details.
SELECT 'Request id: '||request_id ,
'Trace id: '||oracle_Process_id,
'Trace Flag: '||req.enable_trace,
'Trace Name:
'||dest.value||'/'||lower(dbnm.value)||'_ora_'||oracle_process_id||'.trc'
TRACE_FILE_NAME,
'Prog. Name: '||prog.user_concurrent_program_name,
'File Name: '||execname.execution_file_name|| execname.subroutine_name ,
'Status : '||decode(phase_code,'R','Running')
||'-'||decode(status_code,'R','Normal'),
'SID Serial: '||ses.sid||','|| ses.serial#,
'Module : '||ses.module
from fnd_concurrent_requestsreq, v$sessionses, v$processproc,
v$parameterdest, v$parameterdbnm, fnd_concurrent_programs_vlprog,
fnd_executablesexecname
where 1=1
33 of 43
and req.request_id = :request
and req.oracle_process_id=proc.spid(+)
and proc.addr = ses.paddr(+)
and dest.name='user_dump_dest'
and dbnm.name='db_name'
and req.concurrent_program_id = prog.concurrent_program_id
and req.program_application_id = prog.application_id
and prog.application_id = execname.application_id
and prog.executable_id=execname.executable_id;
ii. To generate a trace file for a PL/SQL block that is not a concurrent program please follow
the below steps.
1. Enable Timed Statistics by running following command: ALTER Session SET

TIMED_STATISTICS = TRUE;
2. set trace on by running following command: ALTER SESSION SET SQL_TRACE
= TRUE;
3. Run the SQL or PL/SQL program
4. Run following SQL to identify the trace file for this database session.
select c.value || '\' || lower(d.value) || '_ora_' ||
to_char(a.spid, 'fm00000') || '.trc' "TRACE FILE"
from v$process a, v$session b, v$parameter c, v$parameter d
where a.addr = b.paddr
and b.audsid = userenv('sessionid')
and c.name = 'user_dump_dest'
and d.name = 'db_name';
iii. To trace a forms session please perform following steps.
1. Navigate to corresponding oracle form and set the ‘Trace with bind’ option by
going to Help  Diagnostics  Trace Trace with Binds.

34 of 43
2. The trace file name and location will be displayed on the screen.

35 of 43
3. Perform all necessary actions that you want to generate trace file for. Once all
actions are captured, turn off the trace by going to Help  Diagnostics  Trace
 No Trace.
iv. Location and name of the trace file is displayed on the screen
b. Run tkprof against the trace file to generate a tkprof file. Tkprof command should be executed
from Unix command prompt. Use telnet or putty to login to unix box and run following command:
 tkprof<input_file><output_file> sort=fchqry
2. For all poor performing SQL’s identified in tkprof, and for any stand alone SQL’s (Discoverer) do the
explain plan exercise. Two key metrics that are used for evaluating the performance of a SQL statement
are the explain plan and the number of consistent gets.
 Guidelines for Consistent Gets

Table 1.1 outlines the performance of a SQL statement in a grade format by the number of consistent
gets. Use this table as a guideline for evaluating a SQL statement’s performance. The anticipated
number of executions and number of row returned will have a factor in the grading scale. This is
meant to be a general guideline.
Consistent Gets SQL Grade

CG < 100 A+
100 > CG > 1,000 A
1,000 > CG > 25,000 B

36 of 43
25,000 > CG > 50,000 C
50,000 > CG > 100,000 D
CG > 100,000 F
Table 1.1
CG = Number of Consistent gets from Autotrace
 Guidelines for Explain Plans
FULL TABLE SCAN is acceptable in scenarios like
 A SQL query is returning more than 40% of the rows from a particular table.
 A table has less than 1000 rows.
 Capturing SQL Statement Performance Statistics
The following outlines the steps required to obtain the information using TOAD.
Prerequisite: Make sure plan table is created in your schema or have privileges on it.
Step 1 – Open TOAD
Step 2 – Enable AutoTrace
1. Right click on the SQL Editor window and select “AutoTrace” or click on the Auto Trace tab, and
answer ‘Yes’ to enable it.
Step 3 – Execute SQL Statement
1. Type SQL Statement in edit field (Illustrated in Figure 1)
2. Execute SQL Statement

37 of 43
Figure 1
Step 4 – Capture the Explain Plan and trace information
1. Select the ambulance icon or choose explain plan tab to see explain plan info and go to auto
trace tab to see trace information.

38 of 43
Step 5 – Capture the Information and record it.

 Execution Time -In the bottom left, you will see the time it took to execute the
statement.
 Consistent Gets - Click on the Auto Trace tab and capture the values
 Physical Reads - Click on the Auto Trace tab and capture the values
 Rows Returned - Click on the Data tab right click in the window and select “Record
Count”.
Copy and paste sql statement, explain plan info, and trace info into the ‘xxx.xx Rice Description PS.Doc’

39 of 43
Development Guidelines for Efficient SQL and programs:
1. While using views.

a. Don’t use views where possible. Use base tables.
b. If you are using a complex view which joins many tables and you are getting columns from one or
two tables may be it is wise to just join the base tables in your sql instead of using the view.
2. Issue a commit periodically when processing large volume of data
3. For summarizations, use incremental approach instead of summarizing everything for each run.
4. Avoid using ‘Like’ on predicates of a where clause if possible. Use =’explicit value’
5. Avoid using functions on the predicates of a where clause. If you have to use a function, create a function
based index.
6. Always use Bind variables. No literals.
7. All index creation statements should include following clauses: (I think DBA’s do this on a regular basis)
i. Analyze compute
ii. Parallel degree 4
iii. Tablespace CASX
8. For loading data use sqlldr – 9i version.
9. For your interfaces or complex reports you may be using staging tables. Typically a complex oracle report
would be populating an intermediate table via PL/SQL procedure call, and layout will be built based on a
simple sql on top of that intermediate table. Or, you may be populating data into staging table first and
then populate into main table after further validation. Consider following in sequence for options:
 Evaluate usage of Global temporary tables. Global temporary tables are
great alternative for staging or intermediate tables. The data in these tables
is private to the session..
c. If Global temporary tables is not an option and you need to create a staging table, then do
following:
i. Purge all temp tables at the end of program.
ii. Use truncate instead of delete.
iii. If truncate is not an option, delete rows in batches.
Tips for Efficient SQL and programs:

SQL is a flexible language. More than one SQL statement may meet the needs of your application. Although two
SQL statements may produce the same result, Oracle may process one faster than the other. Following are some
tips which help in writing efficient queries.
1. Use DECODE when you want to scan same rows repetitively or join the same table repetitively.
Example:
--------
SELECT COUNT(*) , SUM(SAL)

40 of 43
FROM EMP
WHERE DEPTNO = 10
AND ENAME LIKE 'MILLER' ;
SELECT COUNT(*) , SUM(SAL)

FROM EMP
WHERE DEPTNO = 20
AND ENAME LIKE 'MILLER' ;
The same result can be achieved using a single query as follows:
SELECT COUNT(DECODE(DEPTNO,20,'X')) DEPT20_COUNT,

COUNT(DECODE(DEPTNO,10,'X')) DEPT10_COUNT,
SUM(DECODE(DEPTNO,20,SAL)) DEPT20_SAL,
SUM(DECODE(DEPTNO,10,SAL)) DEPT10_SAL
FROM EMP
WHERE ENAME LIKE 'MILLER' ;
2. Always use table alias and prefix all column names with the aliases when you are using more than one table.
3. Use NOT EXISTS in place of NOT IN.
In sub-query statement such as the following NOT IN clause causes an internal Sort/Merge.
SELECT *
FROM emp e
WHERE e.deptno NOT IN ( SELECT d.deptno
FROM dept d
WHERE d.dname like %S% ) ;
To improve performance, use the following code.
SELECT *
FROM emp e
WHERE NOT EXISTS ( SELECT d.deptno
FROM dept d
WHERE d.deptno = e.deptno
AND d.dname LIKE '%S%' ) ;
This would allow such statements to use an index, if one exists.
4. Use Joins in place of EXISTS.
In general, join tables rather than specifying sub-queries.
SELECT *
FROM emp e
WHERE EXISTS ( SELECT d.deptno
FROM dept d
WHERE e.deptno = d.deptno
AND d.dname = 'RESEARCH') ;
To improve performance, use the following:

41 of 43
SELECT *
FROM emp e, dept d
WHERE e.deptno = d.deptno
AND d.dname = 'RESEARCH' ;
5. Use EXISTS in place of DISTINCT.
Use EXISTS in place of DISTINCT if you want the result set to contain distinct values while joining tables.
SELECT DISTINCT d.deptno ,

d.dname ,
FROM dept d ,
emp e
WHERE d.deptno = e.deptno ;
The following SQL statement is a better alternative.
SELECT d.deptno ,
d.dname
FROM dept d
WHERE EXISTS ( SELECT e.deptno
FROM emp e
WHERE d.deptno = e.deptno ) ;
6. Never use NOT on an indexed column. Whenever Oracle encounters a NOT on an index column, it will
perform full-table scan.
SELECT *
FROM emp
WHERE NOT deptno = 0;
Instead use the following.
SELECT *
FROM emp
WHERE deptno> 0;
7. Never use a function / calculation on an indexed column. If there is any function is used on an index column,
optimizer will not use index. Use some other alternative. If your evaluation demands to use functions, then create
function based indexes.
Examples:
/** Do Not use **/
SELECT *
FROM emp
WHERE SUBSTR(ENAME,1,3) = 'MIL' ;

42 of 43
/** Suggested Alternative **/
Note: Optimizer uses the index only when optimizer_goal is set to

FIRST_ROWS.
SELECT *
FROM emp
WHERE ENAME LIKE 'MIL%' ;
/** Do Not use **/
SELECT *
FROM emp
WHERE sal != 0 ;
SELECT *
FROM emp
WHERE sal> 0 ;
/** Do Not use **/
SELECT *
FROM emp
WHERE ename || job = 'MILLERCLERK' ;
SELECT *
FROM emp
WHERE ename = 'MILLER'
AND job = 'CLERK' ;
/** Do Not use **/
SELECT *
FROM emp
WHERE sal*12 > 24000 ;
SELECT *
FROM emp
WHERE sal> 24000/12 ;

43 of 43

Technical Coding Standard Document

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Technical Coding Standard Document

Caricato da

Copyright:

Formati disponibili

Technical Coding Standard Document

No Author Date Section Change Description

1 Venkat Peramaneni 18-APR- Created initial version 1.0

Customizations1or enhancements2 must be protected during upgrades

Customizations and enhancements must be easy to re-install

Customizations and enhancements must be thoroughly tested

2 Enhancements – any RICE item. No modification of standard Oracle code.

Code adheres to development standards

Low Level Design Installation Scripts

Requirements Management Process

Supplier Agreement Management

Code Migration Process

Code Configuration Management

Defect Tracking Process

Environment Change Control Process

The Development Environment

Unix Host Environment

bin Executable code of concurrent programs written in a 3GL such as C.

Table 1 - Server-Side Concurrent Program File Directories

3 XX is defined by Oracle on column/table LANGUAGE_CODE/FND_LANGUAGES

Custom Database Schemas

Custom Packages and Triggers4

Registering Custom Programs

Define Concurrent Program Executable (Concurrent=>Program=>Executable)

Define Concurrent Program Definition(Concurrent=>Program=>Definition)

Registering Custom Forms

Do not need to define Concurrent Program Executable or Definition.

Follow Standard Naming Convention rules

2. After Registering the Form, a Function needs to be “registered”.

Follow Standard Naming Convention rules

Customized Code and Objects Registering

Following are the steps for the same.

Interface Development using VGT Interface Framework

Visual Source Safe

5 XX is defined by Oracle on column/table LANGUAGE_CODE/FND_LANGUAGES

Technical Technical Implementation details like Standards , development process

Naming Convention used for source control:

Object Type Visual Source Safe Naming Convention

Alerts alr_<Alert code>.ldt

Version 2.0 For internal use only

Naming Standards for VGTCustom application

Program Directory File Exten Name

Version 2.0 For internal use only

Program Directory File Exten Name

Package $XXVGT_TOP/patch/11 Package pks XXVGT_<COPIED

Package pkb XXVGT_<COPIED

SQL*Loader $XXVGT_TOP/bin Control file ctl XXVGT_<DESCRIPTION>.ctl.

Oracle Forms $XXVGT_TOP/patch/11 Binary fmb XXVGT_<COPIED

$XXVGT_TOP/ Executable fmx XXVGT_<COPIED

Reports $XXVGT_TOP/ Binary rdf XXVGT_<COPIED

Shell script $XXVGT_TOP/bin Shell NONE XXVGT_<DESCRIPTION>. No

Views $XXVGT_TOP/patch/11 SQL Vw/sql XXVGT_<COPIED

SQL $XXVGT_TOP/sql SQL sql XXVGT_<COPIED

Procedures $XXVGT_TOP/sql Procedure prc XXVGT_<COPIED

SQL Scripts $XXVGT_TOP/sql SQL tab XXVGT_<DESCRIPTION>.tab.

SQL Scripts $XXVGT_TOP/sql SQL ind XXVGT_<DESCRIPTION>.ind.

SQL Scripts $XXVGT_TOP/sql SQL seq XXVGT_<DESCRIPTION>.seq.

SQL Scripts $XXVGT_TOP/admin/s SQL syn XXVGT_<DESCRIPTION>.syn.

Program Directory File Exten Name

Oracle $XXVGT_TOP/sql Workflow wft XXVGT_<COPIED

Custom Java $XXVGT_TOP/java Java Code class XXVGT_<COPIED

CUSTOM.pll $AU_TOP/resource CUSTOM. pll CUSTOM.pll (This file will be soft

Custom Web $ XXVGT_TOP / HTML htm XXVGT_<COPIED

Type Directory File Exten Name