Series Introduction

In this series of posts, I will discuss in detail the changes that R12.2 bring to the life of a developer.

Understanding the differences is important to ensure that on-line patching works for your RICE items and that you stay in compliance with Oracle’s development standards. In many cases, the way you prepare and deploy your code today in R11 and R12.1.X will simply not work in R12.2.

Adding to the complexity, Oracle’s own Developer Guide for R12.2 is supplemented with references to Metalink notes for entire sections, which are changing on a regular basis. But don’t panic, I will try and guide you through these new waters and get you to the other side fully ready to take on R12.2. During this series of BLOGS, I will cover the following topics:


When it comes to R12.2, for the impressive online patching to work (apart from the DBA activities of configuring the instance) the developers have their work cut out as well. RICE objects need to be built and deployed keeping in mind the editioning as well as other R12.2 features.


Let’s start by making sure we are all on the same page when it comes to editions.
  • Editions are a feature in the 11G database that allows different versions of a same object to be stored.
  • Editions are like two sets of a Venn diagram.  Users see the objects in Set 1 while the changes are being done in Set 2.
  • The custom code in the database and the file system is copied into different EDITIONS.
  • The Editions can be switched thus, allowing almost instantaneous cut-over.
  • Per the Oracle documentation on R12.2, the Editions are of two kinds:
    • The “Run Edition” is the code and data used by the running application. The points of note are:
      • Run Edition includes a complete application-tier file system along with all objects and data visible in the default edition of the database.
      • As a developer, you will connect to the Run Edition whenever you are engaged in normal development activity on the system.
    • The “Patch Edition” is an alternate copy of Oracle E-Business Suite code and seed data that is updated by Online Patching. The salient points include –
      • The Patch Edition includes a complete copy of the application-tier file system and editioned database code objects.
      • The Patch Edition is only usable when an Online Patching session is in progress.
      • End users cannot access the Oracle E-Business Suite Patch Edition, but as a developer you may need to connect to the Patch Edition of a system when applying patches or debugging problems with Online Patch execution.
  • When the code updates/patches are ready, users disconnect from the Run Edition and switch to patch applied edition.
  • Cross Editioned Triggers are R12.2’s bridges between different editions. They can be written to keep custom objects in sync in different editions.

Do’s and Don’ts of R12.2

The following should be kept in mind when building RICE for R12.2:
  • The DBAs and developers should work closely during the first migration to any non-DEV instance. This goes a long way in ensuring easy packaging and migration of the code.
  • Do read the documentation, including the R12.2 Developer Guide as well as the related Oracle Support Notes.
  • Do create your Custom Application Using adsplice. Reference: Creating a Custom Application in Oracle E-Business Suite Release 12.2 (Doc ID 1577707.1). This will ensure that:
    • Editions are enabled for your custom schema and enables Edition-Based Redefinition (EBR) for the custom objects.
    • Your custom schema is registered with Oracle EBS.
  • Do make sure that your custom schema was registered:
    • select * from dba_users where username = ‘XXMZ’;
  • Do make sure your custom application was registered:
    • select * from fnd_application where application_short_name = ‘XXMZ’;
  • Do use the Oracle provided patching utilities to load and modify customizations (which will be discussed in subsequent posts)
  • Do ensure the use of APPS synonyms for objects and then reference the objects with those synonyms. e.g. Select * from per_all_people_f if the package referencing the table is being compiled in apps else use the synonym apps.per_all_people_f.
  • Always create a unique Index on a table and include the ZD_EDITION_NAME.
  • For editioning to be enabled successfully there must be no dependencies of non-editioned objects on editioned objects.
  • The PUBLIC schema is one of several internal database schemas that cannot be editioned, and so no PUBLIC objects are editioned. PUBLIC Synonyms that point to editioned objects must be dropped, and any reference to them must be replaced with equivalent private synonyms in the referencing schemas.
  • Custom schemas that depend on editioned Oracle E-Business Suite objects must be registered with Oracle E-Business Suite, and will be themselves editioned.
  • User defined Types must be created in the non-editioned schema (APPS_NE)
The following are the DON’TS in R12.2 development scenario:
  • Do not reference the DB objects directly from their home schema. In the example above, do not use hr.per_all_people_f.
  • Like the custom objects, never query standard table directly from your code, instead use the synonym.
  • There is no need to explicitly drop a custom table if you are changing its structure. The patch application will handle this.
  • An existing table should not be renamed using the rename feature in the database. Instead the table should be dropped and re-created.

Custom Objects

The following list represents all of the custom objects that you may/may not* need to handle differently in R12.2.X than you did in R11 or R12.1.X . The changes range from simply compiling the objects in a different schema to using a completely different tool for migrating code to other instances. We will be covering all of these in the BLOG series so stay tuned.
Object Impacted ?
DB Table / Global Temp Table Yes
DB Synonym Yes
Grant Yes
DB Index Yes
DB Sequence Yes
DB View No
DB Table Constraint Yes
DB User Defined Types Yes
DB Triggers Yes
DB Package No
DB Function No
DB Procedure No
DB Materialized View Yes
OS Oracle Form No
OS Oracle Report No
OS SQL*Loader No
OS Shell Script No
DB FND Load No
DB Workflow No
XML Publisher No
Web ADI No
  *Note: Though there are few non-impacted objects in the list, they will still need to follow the DO’s and mandates of R12.2.x e.g. referencing base tables with synonyms.  

Related Posts

Let us fetch you the latest from Oracle!

Not a robot?
Enter the sum of 8 + 9 below:

* Indicates required field.

Success! Thank you!