A comparative analysis between SQL*LOADER and UTL_FILE utility

In implementing new systems we come across problems of importing "alien" data. This may be coming from a legacy system or an on-going system. This data is transported via extract files from the legacy system to the Oracle system. The gateway to Oracle for this data is SQL*Loader and data is loaded into tables via a control script into tables.

Typically, the older systems do not have very normalized data, nor have they been operating with fully implemented database constraints. The lack of constraints over the years in legacy system can lead to bad data that has crept in. Therefore, while bringing external data into oracle system we need a refined set of checks and balances to ensure that we get good data. This requires a lot of programmatic control in the process of data-loading.

The approach applied in case of SQL* Loader is as follows :
   1. Load the data into temporary tables via SQL*Loader via control file and make the data native to ORACLE.
   2. Write a PL/SQL program to do the processing.
   3. Load the data into live tables.

This approach has a lot of dependencies as well as a strong lack of integration of steps and programmatic control. To overcome this, we have analyzed another facility in that has been release Oracle 7.3.x onwards. It is called the UTL_FILE package. With some creative use of this package we can achieve whatever  SQL*LOADER offers and in addition to that do some high level validation and complex data loading. In the following discussion a study of two tools is done.

A BRIEF OVERVIEW OF SQL*Loader:
SQL*Loader is a server utility for loading data from external data files into Oracle database. The basic advantage of using SQL*Loader is for simple loads and fast loading of data. It can load data into myriad data formats, perform elementary filtering, load data into multiple tables, and create one logical record from one or more physical records.

It creates a detailed log file, a bad file that contains rejected records and a discard file to hold the records that are selectively not loaded. The tool is executed from a command line and a username and password and the control file name and location are required to run it.

A BRIEF OVERVIEW OF UTL_FILE:
PL/SQL does not have text file input output capabilities but acquires it via UTL_FILE package. It provides rudimentary utility for reading ( as well as writing) files from within a PL/SQL program. The lines in the file are read sequentially and hence it effects the performance of the program.

The UTL_FILE package can be wrapped around with a PL/SQL program and since this package is integrated with PL/SQL it provides us the tremendous ability for flexing our "programming muscles." Some procedures and functions can be added to this wrapper program that serve as a handy "tool" for doing normal file reading operations. With this approach we can achieve whatever SQL*Loader can do and much more. The security mechanism for UTL_FILE is achieved by defining a parameter in INIT.ora file called utl_file_dir parameter. The directories that UTL_FILE can read from and write to need to have permissions of Oracle
instance owner and the user running the package.

CONCLUSIONS:
The comparative analysis of SQL*Loader and UTL_FILE reveals that these tools are suitable to our environment subject to the conditions of our needs.

If the data load is complex (as is the case in relational databases) UTL_FILE seems to be the tool of choice. This tool does require programmatic effort in terms of writing a wrapper package but the subsequent effort in this direction is greatly reduced once the initial tool kit is built for your environment.

The UTL_FILE tightly integrates the file input with the programmatic control and the data manipulation inside a single PL/SQL unit. There are disadvantages of speed in loading in case of UTL_FILE but these are totally offset by the programmatic control it offers and the integration it brings in.

Thus we find that UTL_FILE tool bridges the gap left by SQL*Loader for complex data loads.

Thanks & Regards,
Anto Joe Natesh

Dual Table

Cool discussion about Dual on asktom

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1562813956388

Tips in Oracle 6i report customizations:

1. Setup client info if views are involved, setup organization context if inventory items are involved.
2. Ensure that report builder/designer is in character mode.
3. Ensure constraints are off for stretching, grid is on, snap to grid is on/off
4. use srw.message frequently
5. Port the rdf in Binary Mode.
6. Set the trace on for the concurrent program to actually see the sql code executed.
7. Bring the query out and changes should be tested in simple SQLs
8. Set the trace on if there are &lexical parameters if you need to check the query that is changing dynamically.
9. Use srw.message to print the value of lexical parameters after their evaluation
10. Use of Concsub to submit your report concurrent program from UNIX faster.

Workflow Table Information

WF_ITEM_TYPES - It defines an item that is transitioning through a workflow process. NAME (PK), PROTECT_LEVEL, CUSTOM_LEVEL, PERSISTENCE_TYPE

WF_ITEM_ATTRIBUTES - stores definitions of attributes associated with a process. Each row includes the sequence in which the attribute is used as well as the format of the attribute data. ITEM_TYPE (PK), NAME (PK), SEQUENCE, TYPE, PROTECT_LEVEL, CUSTOM_LEVEL

WF_ACTIVITIES -table stores the definition of an activity. Activities can be processes, notifications, functions or folders.ITEM_TYPE (PK), NAME (PK), VERSION(PK), TYPE, RERUN, EXPAND_ROLE, PROTECT_LEVEL, CUSTOM_LEVEL, BEGIN_DATE, RROR_ITEM_TYPE, RUNNABLE_FLAG

WF_ACTIVITY_ATTRIBUTES - table defines attributes which behave as parameters for an activity. Activity attributes are only used by function activities.Examples of valid attribute types are DATE, DOCUMENT, FORM, ITEMATTR, LOOKUP, and VARCHAR2.
ACTIVITY_ITEM_TYPE (PK), ACTIVITY_NAME (PK), ACTIVITY_VERSION (PK), NAME (PK), SEQUENCE, TYPE, VALUE_TYPE, PROTECT_LEVEL, CUSTOM_LEVEL

WF_MESSAGES - contains the definitions of messages which may be sent out as notifications. TYPE (PK), NAME (PK), PROTECT_LEVEL, CUSTOM_LEVEL

WF_MESSAGE_ATTRIBUTES contains message attribute definitions.

WF_NOTIFICATIONS holds the runtime information about a specific instance of a sent message. A new row is created in the table each time a message is sent.

WF_NOTIFICATION_ATTRIBUTES holds rows created for attributes of a notification. When each new notification is created, a notification attribute row is created for each message attribute in the message definition. Initially, the values of the notification attributes are set to the default values specified in the message attribute definition.

WF_ITEMS is the runtime table for workflow processes. Each row defines one work item within the system. ITEM_TYPE (PK), ITEM_KEY (PK), ROOT_ACTIVITY, ROOT_ACTIVITY_VERSION, BEGIN_DATE

WF_ITEM_ACTIVITY_STATUSES TABLE is the runtime table for a work item. Each row includes the start and end date, result code, and any error information an activity generates. ITEM_TYPE (PK), ITEM_KEY (PK), PROCESS_ACTIVITY (PK)

WF_ITEM_ACTIVITY_STATUSES_H - table stores the history of the WF_ITEM_ACTIVITY_STATUSES table. ITEM_TYPE, ITEM_KEY, PROCESS_ACTIVITY

WF_PROCESS_ACTIVITIES stores the data for an activity within a specific process. PROCESS_ITEM_TYPE, PROCESS_NAME, PROCESS_VERSION, ACTIVITY_ITEM_TYPE, ACTIVITY_NAME, INSTANCE_ID (PK), INSTANCE_LABEL, PERFORM_ROLE_TYPE, PROTECT_LEVEL, CUSTOM_LEVEL

WF_ACTIVITY_TRANSITIONS table defines the transitions from one activity to another in a process. Each row includes the activities at the beginning and end of the transition, as well as the result code and physical location of the transition in the process window. FROM_PROCESS_ACTIVITY (PK), RESULT_CODE (PK), TO_PROCESS_ACTIVITY (PK), PROTECT_LEVEL,CUSTOM_LEVEL

WF_ACTIVITY_ATTR_VALUES table contains the data for the activity attributes. Each row includes the process activity id and the associated value for the attribute. PROCESS_ACTIVITY_ID (PK), NAME (PK), VALUE_TYPE, PROTECT_LEVEL, CUSTOM_LEVEL

Script to delete the concurrent program from Oracle

Begin
fnd_program.delete_program('program short name','schema');
fnd_program.delete_executable('program short name','schema');
commit;
End;

How to close/respond to a FYI notification from PL/SQL

Closing/Responding to a FYI notification is pretty straight forward. You need to just run the following API:

begin
wf_notification.CLOSE (nid => --Notification ID--,
responder => --Responder Name--
);
commit;
end;

Note: The Responder Name should be the same as the 'User Name' which the user uses to login the Oracle applications.

Diff bet ad_bugs and ad_appiled_patches tables

AD_BUGS - AD_BUGS holds information about the various Oracle Applications bugs whose fixes have been applied (ie.patched) in the Oracle Applications installation.

AD_APPLIED_PATCHES - gives information only abt the bugs/patches those we applied after installation
- holds information about the "distinct" Oracle Applications patches that have been applied. If 2 patches happen to have the same name but are different in content (eg. "merged" patches), then they are considered distinct and this table will therefore hold 2 records.

API to Purge an person from Oracle HRMS

http://retoscripts.blogspot.com/2009/10/api-to-purge-person-from-oracle-hrms.html

Tracing techniques in oracle applications

Hi All,

This is one of the good reference documents from metalink.

WHAT TO SET UP BEFORE GENERATING THE TRACE

These steps must be performed by the DBA on the database server.

1. Set TIMED_STATISTICS to TRUE.
   For performance issues, make sure TIMED_STATISTICS is turned on, before attempting to generate the trace.

   Set the following in the init.ora file:
      TIMED_STATISTICS=TRUE
      OR
      in SQL*Plus: ALTER SYSTEM SET TIMED_STATISTICS=TRUE;

2. Set the location of the trace output.
   Set the following in the init.ora file: USER_DUMP_DEST =

3. Create the PLAN_TABLE to hold the output of the explain plan. Run the SQL script called UTLXPLAN.SQL to create this in the apps schema. This script is usually in $ORACLE_HOME/rdbms/admin.

4. If the init.ora file has been updated, you must shut down and restart the database before the changes will take effect.
   TYPES OF TRACE - HOW TO TURN TRACE ON
   Regardless of the type of trace file you create, make sure you note the time that you create it.

1] Form Trace

Toggle trace on/off on the form, to trace specific application functions. Make sure you go in fresh (sign off/on to the application), since somequeries are cached and may not be executed on subsequent visits to theform.

From the menu, select Help-->Diagnostics-->Trace to turn trace on (when checked, it is on).
   Perform the action to be traced.
   From the menu, turn trace off, by selecting Help-->Diagnostics-->Trace (it should now be unchecked).

2] Concurrent Program Trace
   A. This will turn trace on for each execution of this program. In Release 11.0 and lli, check the Enable Trace checkbox for the concurrent program on the Concurrent Programs form. After running the program to be traced, make sure you uncheck the Enable Trace checkbox.
   Select the System Administrator responsibility.
   Navigation = Concurrent -> Programs -> Define. Query the concurrent program you want to trace. Check the Enable Trace checkbox and save.
   OR
   B. How to generate a raw trace file with binds and/or waits for 11.5.10:
1. Log into applications as System Administrator and Navigate to the System Profile Values Form. Select the profile called Concurrent: Allow Debugging and change the value to Yes at the appropriate level.
2. Allow pop-ups on your browser.
3. Navigate to the Submit a New Request form and select a job and enter all parameters for that job
4. Select the Debug Options Button and this will take you to Create Debug Rule in Oracle Application Manager
5. Select the appropriate Debug Option Value for SQL Trace only and then check the box
6. Hit OK twice and then Submit the job
7. Raw trace file with options selected will be located in the appropriate directory.

3] Database Level Trace
   This will turn trace on for all processes that are running in the instance and should only have to be used in Release 10.7, for concurrent programs. (This has to be done by the DBA.)
   Set the following in the init.ora file:SQL_TRACE=TRUE
   Shut down and restart the database.After generating the trace file, shut down and restart the database with the original init.ora.

4] Report Trace
If you are on 10.7 and need to trace an Oracle Report, you can modify the report to turn trace on for that session.
   a. Convert the report from rdf to rex: $ORACLE_HOME/bin/r25convm batch=yes userid=> stype=rdffile source=REPORT_NAME.rdf dtype=rexfile overwrite=yes 
   b. Edit the rexfile and search for the beforerep trigger in the report.
      Locate the following code:
         IF (:p_trace_switch = 'Y') THEN
            SRW.DO_SQL('alter session set sql_trace TRUE');
         END IF;
      Comment out the IF and END IF lines.
   c. Save the report.
   d. Convert the report from rex to rdf: $ORACLE_HOME/bin/r25convm batch=yes userid= \ > stype=rexfile source=REPORT_NAME.rex dtype=rdffile overwrite=yes 


5] Self Service page (like a Forms trace, but for self service web apps)
   a. Set the FND:Diagnostics profile: Responsibility = System Administrator
      Navigation: Profile > System User: Enter User name
      Query the Profile: 'FND:Diagnostics'
      Set the 'FND:Diagnostics' profile to Yes at User level

   b. Login to Self Service under the same user the profile was set for.
   c. Turn Trace on: Click the Diagnostic link at the top of the page.
      It shows two options: Show Log and Set Trace Level
      Select 'Set Trace Level'
      Click Go.
      Select one of the following options:
      Disable Trace - used to end the trace
         Trace (Regular) - just like a forms trace
         Trace with Binds - record the bind variables in the trace
         Trace with waits - Good for performance issues
         Trace with binds and waits - combines both of the above
      Click Save.
    
   d. Perform the action to be traced in Self Service.
      Multiple trace files may be generated in the usual trace directory.
   e. Turn trace off: Select the Diagnostic link
      Click on option: Set Trace Level
      Note all of the trace numbers listed
      Click Go
      Select: Disable Trace
      Click Save

WHAT TO DO AFTER GENERATING THE TRACE FILE

These steps should be performed by the DBA, on the database server.

1. Find the trace directory. Get the location of user_dump_dest. Log into SQL*Plus as the apps user.
   select value from V$PARAMETER where name = 'user_dump_dest'
2. Find the trace file for your process.Go to the directory you found in step 1 (in UNIX, use cd). Look for a file (.trc) that was created at the time you started your process (in UNIX, use ls -ltr).
3. Run tkprof with explain plan. Go to a directory in which you have write privilege (in UNIX, use cd).

Run tkprof:
tkprof

explain=

HOW TO GET AN EXPLAIN PLAN FOR A SQL STATEMENT

Sometimes you may have a need to get an explain plan for a specific SQL statement. If you have the sql statement, you can get the explain plan for it.
This should be run on the same instance that the sql statement came from.
In your apps account ---
Run the following script:
delete from plan_table
where statement_id = 'tmp'

explain plan

set statement_id = 'tmp'
for

/
set pages 100
col operation format a36
col options format a11
col object_name format a30

select lpad(' ',2*(level-1))operation operation,


options, object_name
from plan_table
where statement_id = 'tmp'
connect by prior id = parent_id
and statement_id = 'tmp'
start with id = 1
and statement_id = 'tmp'
order by id
/
delete from plan_table
where statement_id = 'tmp'
/
commit;

How to Integrate Applications Release R12 with Custom Applications

This is our requirement.



SCHEMA NAME : XXCUST
TOP NAME : XXCUST_TOP
Application : XXCUST Custom Application
Data Group : Standard
Request Group : XXCUST Request Group
Menu : XXCUST_CUSTOM_MENU
Responsibility : XXCUST Custom



Assumptions:
APPL_TOP: /d01/oracle/VIS/apps/apps_st/appl
Instance Name: VIS
Server OS: linux

There are 14 simple steps to achieve this.

1) Make the directory structure for your custom application files.

cd $APPL_TOP

mkdir XXCUST

mkdir XXCUST/12.0.0

mkdir XXCUST/12.0.0/admin

mkdir XXCUST/12.0.0/admin/sql

mkdir XXCUST/12.0.0/admin/odf

mkdir XXCUST/12.0.0/sql

mkdir XXCUST/12.0.0/bin

mkdir XXCUST/12.0.0/reports

mkdir XXCUST/12.0.0/reports/US

mkdir XXCUST/12.0.0/forms

mkdir XXCUST/12.0.0/forms/US

mkdir XXCUST/12.0.0/lib

mkdir XXCUST/12.0.0/out

mkdir XXCUST/12.0.0/log

2) Add the custom module into the environment

cd $APPL_TOP

echo "XXCUST_TOP=/d01/oracle/VIS/apps/apps_st/appl/XXCUST/12.0.0" >customVIS_linux.env

echo "export XXCUST_TOP " >> customVIS_linux.env

Source the environment file (/d01/oracle/VIS/apps/apps_st/appl/APPSVIS_linux.env )

Make entry to the application context file

vi $INST_TOP/appl/admin/VIS_linux.xml

/d01/oracle/VIS/apps/apps_st/appl/XXCUST/12.0.0

cd $INST_TOP/admin/install

sh adgentopfile.sh

3) create tablespace XXCUST datafile '/d01/oracle/VIS/db/apps_st/data/XXCUST01.dbf'

size 500M

4) create user XXCUST identified by XXCUST

default tablespace XXCUST

temporary tablespace temp

quota unlimited on XXCUST;

grant connect, resource to XXCUST;

5) Register your Oracle Schema.

Login to Applications with System Administrator responsibility

Navigate to Application-->Register

Application = XXCUST Custom Application

Short Name = XXCUST

Basepath = XXCUST_TOP

Description = XXCUST Custom Application

6) Register Oracle User

Naviate to Security-->Oracle-->Register

Database User Name = XXCUST

Password = XXCUST

Privilege = Enabled

Install Group = 0

Description = XXCUST Custom Application User

7) Add Application to a Data Group

Navigate to Security-->Oracle-->DataGroup

8) Create custom request group

This will act as a placeholder for any custom reports we wish to make available for the Custom Responsibility (which is defined at a later stage)

Navigate to Security-->responsibility-->Request

Group = XXCUST Request Group

Application = XXCUST Custom

Code = XXCUST

Description = XXCUST Custom Requests

At this statge, We are not going to define any requests, but you can add request in the later point of time if its required.

9) Create custom menu

This will act as a placeholder for any menu items we wish to make available for the Custom Responsibility (which is defined at a later stage).

Navigate to Application-->Menu

Menu = XXCUST_CUSTOM_MENU

User Menu Name = XXCUST Custom Application Menu

Menu Type =

Description = XXCUST Custom Application Menu

Seq = 100

Prompt = View Requests

Submenu =

Function = View All Concurrent Requests

Description = View Requests

Seq = 110

Prompt = Run Requests

Submenu =

Function = Requests: Submit

Description = Submit Requests

10) Create new responsibility. Navigate to Security-->Responsibility-->Define

Responsibility Name = XXCUST Custom

Application = XXCUST Custom

Responsibility Key = XXCUSTRESP

Description = XXCUST Custom Responsibility

Available From = Oracle Applications

Data Group Name = Standard

Data Group Application = XXCUST Custom Application

Menu = XXCUST Custom Application Menu

Request Group Name = XXCUST Request Group

11) Add responsibility to user

Navigate to Security-->User-->Define

Add XXCUST Custom responsibility to users as required.

12) Other considerations

You are now ready to create your database Objects, custom Reports, Forms, Packages, etc

Create the source code files in the XXCUST_TOP directory appropriate for the type of object. For example forms would be located in $XXCUST_TOP/forms/US or

package source code in $XXCUST_TOP/admin/sql for example.

Database Objects, such as tables, indexes and sequences should be created in the XXCUST schema, and then you need to

   a) Grant all privilege from each custom data object to the APPS schema.

      For example : logged in as XXCUST user

      grant all privileges on XX_TABLE to apps;

   b) Create a synonym in APPS for each custom data object

      For example : logged in as APPS user

      create synonym XX_TABLE for XXCUST.XX_TABLE;

13) Login to sysadmin, Application Developer Responsibility

In the backend compile your form

su - applmgr

cd $AU_TOP/forms/US

cp TEMPLATE.fmb XXSAMPLE.fmb

frmcmp_batch Userid=apps/apps module=XXSAMPLE.fmb output_file=/d01/oracle/VIS/apps/apps_st/appl/XXCUST/12.0.0/forms/US/XXSAMPLE.fmx compile_all=special  batch=yes

Application > Form (Register the form)

Application > Menu (Attach the function to a menu)

Open new session, source environment file, and stop middle tier services, run autoconfig

Open new session, source environment file, check for custom top in topfile.txt in $APPL_TOP/admin, start the middle tier services.

   cd $ADMIN_SCRIPTS_HOME

   sh adstpall.sh apps/apps

   sh adautocfg.sh

   sh adstrtal.sh apps/apps

   cat $APPL_TOP/admin/topfile.txt

   You can find the entry as lke this, XXCUST /d01/oracle/VIS/apps/apps_st/appl

14) Menu that is added to a particular responsibility is given to specific user

Security > User >

Attach our custom responsibility to the user.

Common Errors and Solution:

1. Function not available to this responsibility. Change responsibility or contact your system administrator.

Solution

Restart the forms server

cd $ADMIN_SCRIPTS_HOME

sh adstpall.sh apps/apps

sh adstrtal.sh apps/apps

Thanks & Regards,

Anto Joe Natesh I

Hierarchical Trees Developement Using Oracle Forms Builder

This Topic and demo contributed by Mr.Jegan A. 

About Hierarchical Trees

The hierarchical tree displays data in the form of a standard navigator.

We can populate a hierarchical tree with values contained in a Record Group or Query Text.

At runtime, you can programmatically add, remove, modify, or evaluate elements in a hierarchical tree.

The amount of data displayed at any one time depends upon the expansion of individual data nodes.

Triggers

Following Triggers are Provided by Form Builder exclusively for hierarchical tree Items.

1.       When-Tree-Node-Activated

2.       When-Tree-Node-Expanded

3.       When-Tree-Node-Selected

Built-ins

Following built-in subprograms are used to add, remove, modify, or evaluate elements in a hierarchical tree Items.

All built-ins are located in the FTREE built-in package.

1.       Add_Tree_Data

2.       Add_Tree_Node

3.       Delete_Tree_Node

4.       Find_Tree_Node

5.       Get_Tree_Node_Parent

6.       Get_Tree_Selection

7.       Populate_Group_From_Tree

8.       Populate_Tree

9.       Set_Tree_Selection

Now, we will see, how to Develop a form Using Hierarchical Tree Item for Oracle Application.

Objectives :

1.       Create the Hierarchical Tree Item in a Non-Database Block.

2.       Populate the Data to the Hierarchical Tree Item Using Record Group at Runtime.

3.       Create a Database Block to Display the Data(s) based on the Element Navigating on the Hierarchical Tree Item.

Database Objects Required to Develop this Form :

Find the Attachment contains the Script to Create Database Objects & Sample Data’s to be Inserted.

In the Canvas Tool Palette we can I find the Hierarchical Tree.

Note : Hierarchical Tree Item Should be in a separate Block as a Individual Item.

There are 2 ways to populate a hierarchical tree :

1.       Record Group

2.       Query Text

The record Group query should be in the specified structure., which requires 5 Columns.

SELECT STATUS, LEVEL, LABEL, ICON, VALUE FROM TABLE;

STATUS à Indicates the initiate status of the Node (Normally Value is 1).

LEVEL  à This is a specific pseudo-column Derived from “CONNECT BY”.

LABEL  à This is the visible label of the Node.

ICON   à That contains the icon name of the Node (can be NULL).

VALUE  à That contains the value of the Node.

Below is the Query used in the Record Group to Populate the Data in the Hierarchical Tree Item.

SELECT 1, LEVEL, ENAME, NULL, TO_CHAR(EMPNO) APPS.EMP CONNECT BY PRIOR EMP.EMPNO = EMP.MGR;

Object Navigator :

Canvas Design :

At Run Time :

Please find the attachment has the FMB of the above discussed Form.

Kindly have a look on the Below Triggers :

1. WHEN-NEW-FORM-INSTANCE (Form Level)
2. WHEN-TREE-NODE-SELECTED (Item Level)

I hope this will be Useful for our Custom Developemnts.

Thank you Jegan.

Posted By, Anto Joe Natesh I

Global Temporary Table

Create Temporary Table in Oracle

To create a table named test with column col1 type varchar2 length 10, col2 type number. col3 type clob we can use CREATE TABLE statement as,

CREATE TABLE TEST(col1 VARCHAR2(10), col2 NUMBER, col3 CLOB);

Now if I insert data into the table the data is visible and accessible to all users. In many cases it is needed the data inside a table will be reside temporarily. In that case we can use temporary tables. Temporary tables are useful in applications where a result set is to be buffered. To create temporary table we have to issue CREATE GLOBAL TEMPORARY clause.

Temporary table can be of two types based on ON COMMIT clause settings.

1)ON COMMIT DELETE ROWS specifies temporary table would be transaction specific. Data persist within table up to transaction ending time. If you end the transaction the database truncates the table (delete all rows). Suppose if you issue commit or run ddl then data inside the temporary table will be lost. It is by default option.

Example:

(i)This statement creates a temporary table that is transaction specific:

CREATE GLOBAL TEMPORARY TABLE test_temp(col1 number, col2 number) ON COMMIT DELETE ROWS;

Table created.

(ii)Insert row in to the temporary table.

insert into test_temp values(3,7);

1 row created.

(iii)Look at the data in the table.

select * from test_temp;

COL1 COL2

---------- ----------

3 7

(iv)Issue Commit.

commit;

Commit complete.

(v)Now look at the data in the temporary table. As I created transaction specific temporary table(on commit delete rows) so data is lost after commit.

SQL> select * from test_temp;

no rows selected

2)ON COMMIT PRESERVE ROWS specifies temporary table would be session specific. Data persist within table up to session ending time. If you end the session the database truncates the table (delete all rows). Suppose you type exit in SQL*Plus then data inside the temporary table will be lost.

Example of Session Specific Temporary Tables:

1)Create Session Specific Temporary Table test_temp2.

CREATE GLOBAL TEMPORARY TABLE test_temp2 (col1 number, col2 number)

ON COMMIT PRESERVE ROWS;

(ii)Insert data into it and look at data both before commit and after commit.

insert into test_temp2 values(3,7);

1 row created.

SQL>select * from test_temp2;

COL1 COL2

---------- ----------

3 7

(iii) commit;

Commit Complete

(iv)select * from test_temp2;

COL1 COL2

---------- ----------

3 7

(iv)End the Session.

exit;

Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production

With the Partitioning, OLAP and Data Mining options

(v)Connect in a new session and look at data again.

$ sqlplus apps/apps@vis.world

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – Production

With the Partitioning, OLAP and Data Mining options

SQL> select * from test_temp2;

no rows selected

This is how Global Temporary Tables are used.

Feature of Temporary Table

1.Indexes can be created on temporary tables. They are also temporary and the data in the index has the same session or transaction scope as the data in the underlying table.

2.Unlike permanent tables, temporary tables and their indexes do not automatically allocate a segment when they are created. Instead, segments are allocated when the first INSERT (or CREATE TABLE AS SELECT) is performed. This means that if a SELECT, UPDATE, or DELETE is performed before the first INSERT, the table appears to be empty.

3.DDL operations (except TRUNCATE) are allowed on an existing temporary table only if no session is currently bound to that temporary table.

4.If you rollback a transaction, the data you entered is lost, although the table definition persists.

5.A transaction-specific temporary table allows only one transaction at a time. If there are several autonomous transactions in a single transaction scope, each autonomous transaction can use the table only as soon as the previous one commits.

6.Because the data in a temporary table is, by definition, temporary, backup and recovery of temporary table data is not available in the event of a system failure.

7.It is good to know about that temporary table itself is not temporary, the data within it is temporary.

Restriction of Temporary Table

1.Temporary tables cannot be partitioned, clustered, or index organized.

2.You cannot specify any foreign key constraints on temporary tables.

3.Temporary tables cannot contain columns of nested table.

4.You cannot specify the following clauses of the LOB_storage_clause: TABLESPACE, storage_clause, or logging_clause.

5.Parallel DML and parallel queries are not supported for temporary tables. Parallel hints are ignored. Specification of the parallel_clause returns an error.

6.You cannot specify the segment_attributes_clause, nested_table_col_properties, or parallel_clause.

7.Distributed transactions are not supported for temporary tables.

Thanks & Regards,

Anto Joe Natesh I

What is FNDLOAD and what it is used for

FNDLOAD is a concurrent program that can move Oracle Applications data between database and text file. FNDLOAD can download data from an application entity into an editable text file, which can be uploaded to another database. Conversion between database format and text file format is specified by a configuration file. But i could not 

find anything regarding upload/download of an Oracle Alert. So, my conclusion was that i must be possible to use FNDLOAD to transfer Alerts, but that there is no configuration file provided by Oracle. I had to create a 

configuration file myself.

We use ldt loader data files for loading.

Oracle currently supports the migration of the following types of data using FNDLOAD

Printers / Print queues / Executables Printers / Print queues / Executables. Roles / Responsibilities / Forms Roles / Responsibilities / Forms. Menus / Users / Request Sets Menus / Users / Request Sets. Request Groups / Request Queues Request Groups / Request Queues. Work shifts / Programs / Libraries Work shifts / Programs / Libraries. Attachments / Help Files Attachments / Help Files. Mime Types Mime Types. Security Information.

What is 0 & Y in FNDCPASS, FNDLOAD or WFLOAD?

0 & Y are flags for FND Executable like FNDCPASS & FNDLOAD where
   0 is request id (request ID 0 is assigned to request ID's which are not submitted via Submit Concurrent Request Form.
   'Y' indicates the method of invocation. i.e. it is directly invoked from the command-line not from the Submit Request Form.

Thanks & Regards,
Anto Joe Natesh I

Migrating Reports to Release 12 - Co-Existing & Obsolete Table details

The Impact:

·         Some 11i queries will easily migrate to Rel. 12

·         Some with no changes at all

·         Some will need table name changes

·         Some 11i queries will need moderate attention

–      Data moved to TCA will require query rewrites, but the basic reports can remain the

·         same

·         Some 11i queries won’t migrate 1:1 to Rel. 12

–      SLA may require new reports, queries & ETL routines

Funds Disbursement Changes

Co-existing Tables

	11i	R12
Invoice payments	AP_INVOICES_ALL AP_PAYMENT_SCHEDULES_ALL	IBY_DOCS_PAYABLE_ALL
Payments	AP_CHECKS_ALL	IBY_PAYMENTS_ALL
Instructions, batches	AP_INV_SELECTION_CRITERIA_ALL	IBY_DOCS_PAYABLE_ALL IBY_PAY_SERVICE_REQUESTS IBY_PAY_INSTRUCTIONS_ALL

Obsolete Tables

	11i	R12
Banks	AP_BANK_ACCOUNT_USES_ALL	CE_BANK_ACCT_USES_ALL
Payment documents	AP_CHECK_STOCKS_ALL	CE_PAYMENT_DOCUMENTS
Supplier & customer bank accounts	AP_BANK_ACCOUNTS_ALL	IBY_EXTERNAL_PAYEES_ALL IBY_EXT_BANK_ACCOUNTS IBY_PMT_INSTR_USES_ALL

Suppliers & TCA

Supplier, supplier site, & supplier contact information migrated to TCA tables

• Three new AP tables containing supplier unique data, with links to TCA tables

AP_SUPPLIERS

AP_SUPPLIER_SITES_ALL

AP_SUPPLIER_CONTACTS

• Three old PO Vendors tables obsolete

– Views provided for backward compatibility

Supplier Changes

Co-existing Tables

	Release 12 Payables	R12
Suppliers	AP_SUPPLIERS	HZ_PARTIES
Supplier sites	AP_SUPPLIER_SITES_ALL	HZ_PARTY_SITES HZ_LOCATIONS
Supplier contacts	AP_SUPPLIER_CONTACTS	HZ_PARTIES HZ_PARTY_SITES HZ_RELATIONSHIPS HZ_ORG_CONTACTS

Obsolete Tables

	11i	R12
Suppliers	PO_VENDORS	AP_SUPPLIERS
Supplier sites	PO_VENDOR_SITES_ALL	AP_SUPPLIER_SITES_ALL
Supplier contacts	PO_VENDOR_CONTACTS	AP_SUPPLIER_CONTACTS

Banks Data in R12

Setup in Cash Management (CE)

– Bank, bank account setup

– Shared with Payables, Receivables, Treasury, & Payroll

• Banks & bank branches now represented as TCA parties

– 11i AP bank data moved to TCA HZ_PARTIES table

• Three key CE tables

– CE_BANK_ACCOUNTS for bank accounts

– CE_BANK_ACCT_USES_ALL for account uses by Operating Units & Legal Entities

– CE_GL_ACCOUNTS_CCID for bank account use accounting data

Bank Data in TCA

	Release 12 TCA
Bank, bank branch, account attributes, contact persons	HZ_PARTIES
Bank sites & locations	HZ_PARTY_SITES HZ_LOCATIONS
Change history & additional attributes	HZ_ORGANIZATION_PROFILES
Contact details & methods	HZ_CONTACT_POINTS
Contact titles	HZ_ORG_CONTACT
Contact purpose or role	HZ_ORG_CONTACT_ROLES

Thanks & Regards,

Anto Joe Natesh I