Wednesday, 15 June 2011

REF Cursors in Oracle PLSQL - An Overview with Example



REF Cursors in Oracle PLSQL - An Overview with Example

The Primary purpose of this post is to provide fair idea on the advanced concepts in PL/SQL like REF Cursor. We have given a try and hope to be useful for my audiences.

REF CURSOR
•          A ref cursor is a variable, defined as a cursor type, which will point to, or reference a cursor result.
•          To execute a multi-row query, Oracle opens an unnamed work area that stores processing information. You can access this area through an explicit cursor, which names the work area, or through a cursor variable, which points to the work area. To create cursor variables, you define a REF CURSOR type, and then declare cursor variables of that type.

Syntax of the REF Cursor

Define a REF Cursor TYPE:
   TYPE ref_type_name IS REF CURSOR
    [RETURN {
             cursor_name%ROWTYPE           
            |ref_cursor_name%ROWTYPE
            |record_name%TYPE
            |record_type_name
            |db_table_name%ROWTYPE
            }
    ];


RETURNspecifies the data type of a cursor variable return value. You can use the %ROWTYPE attribute in the RETURN clause to provide a record type that represents a row in a database table or a row from a cursor or strongly typed cursor variable. You can use the %TYPE attribute to provide the datatype of a previously declared record.
Ø  cursor_name
An explicit cursor previously declared within the current scope.
Ø  ref_cursor_name
An ref cursor previously declared within the current scope.
Ø  record_name
A user-defined record previously declared within the current scope.
Ø  record_type_name
A user-defined record type that was defined using the data type specifies RECORD.
Ø  db_table_name
A database table or view, which must be accessible when the declaration is elaborated.
Ø  %ROWTYPEA record type that represents a row in a database table or a row fetched from a cursor or strongly typed cursor variable. Fields in the record and corresponding columns in the row have the same names and datatypes.
Ø  %TYPE
Provides the datatype of a previously declared user-defined record.
Ø  type_name
A user-defined cursor variable type that was defined as a REF CURSOR.

Cursor_variable_declaration:
    cursor_variable_name ref_type_name;
OPEN a REF cursor...
OPEN cursor_variable_name
 FOR select_statement;

/*To be sure it's not open already:*/
IF NOT cursor_variable_name%ISOPEN THEN
   OPEN cursor_variable_name FOR select_statement;
END IF;

Types of REF CURSOR
Strongly Typed: A REF CURSOR that specifies a specific return type
DECLARE
TYPE    EmpCurTyp IS REF CURSOR
RETURN  emp%ROWTYPE; -- strongly typed ref cursor
cursor1 EmpCurTyp;
BEGIN
NULL;
END;
Weakly Typed:  A REF CURSOR that does not specify the return type  
DECLARE
TYPE    EmpCurTyp IS REF CURSOR  -- Weakly typed ref cursor
cursor1 EmpCurTyp;
BEGIN
NULL;
END;

Three statements to control a cursor variable
·      OPEN-FOR
·      FETCH
·      CLOSE

  1. OPEN-FOR statements can open the same cursor variable for different queries. You need not close a cursor variable before reopening it. When you reopen a cursor variable for a different query, the previous query is lost.
  2. PL/SQL makes sure the return type of the cursor variable is compatible with the INTOclause of the FETCH statement.
Simple Example:
DECLARE
 TYPE    EmpCurTyp IS REF CURSOR
 RETURN  emp%ROWTYPE; -- strong cursor
 emp1    EmpCurTyp;

 PROCEDURE process_emp_cv (emp_cv IN EmpCurTyp) IS
  person emp%ROWTYPE;
 BEGIN
     DBMS_OUTPUT.PUT_LINE('-----');
     DBMS_OUTPUT.PUT_LINE('Here are the names from the result set:');
 LOOP
     FETCH emp_cv INTO person;
     EXIT WHEN emp_cv%NOTFOUND;
     DBMS_OUTPUT.PUT_LINE('Name = ' || person.ENAME ||' ' || person.JOB);
 END LOOP;
 END;

BEGIN
   OPEN  emp1
   FOR   SELECT *
         FROM emp
         WHERE ROWNUM < 11;
         process_emp_cv(emp1);
   CLOSE emp1;
   OPEN  emp1
   FOR   SELECT *
         FROM emp
         WHERE ENAME LIKE 'R%';
         process_emp_cv(emp1);
   CLOSE emp1;
END;

Difference between REF CURSOR and CURSOR with Example:
DECLARE
   TYPE rc IS REF CURSOR;
   CURSOR c IS SELECT * FROM dual;
   l_cursor rc;
BEGIN
       IF   (to_char(SYSDATE,'dd') = 30) THEN
            OPEN l_cursor FOR SELECT * FROM emp;
                 
      ELSIF (to_char(SYSDATE,'dd') = 29) THEN
             OPEN l_cursor FOR SELECT * FROM dept;
                   
      ELSE
             OPEN l_cursor FOR SELECT * FROM dual;
      END IF;
      OPEN c;
         -----
             /* some manipulation here */
         -----
      CLOSE c;
END;
Comparisons
1.       Cursor C will always be select * from dual.   The ref cursor can be anything.
2.       Cursor can be global -- a ref cursor cannot (you cannot define them OUTSIDE of a procedure / function).
3.       Ref cursor can be passed from subroutine to subroutine -- a cursor cannot be.

Usage Restrictions
The following are restrictions on cursor variable usage.
1.       Comparison operators cannot be used to test cursor variables for equality, inequality, null, or not null.
2.       Null cannot be assigned to a cursor variable.
3.       The value of a cursor variable cannot be stored in a database column.
4.       Static cursors and cursor variables are not interchangeable. For example, a static cursor cannot be used in an OPEN FOR statement.

post signature

TCA TABLE ARCHITECTURE IN ORACLE APPS





TCA TABLE ARCHITECTURE IN ORACLE APPS

In this post, I have tried to explain the architecture of TCA in oracle apps using graphical representations and welcoming your comments. Hope it will be useful  for my audience.


PARTIES



      The related tables are as follows:-
  • HZ_PARTIES : Stores information about parties.
  • HZ_FINANCIAL_PROFILE : Stores information about the financial accounts.
  • HZ_CREDIT_RATINGS : Stores information about the credit rating of parties
  • HZ_REFERENCES : Stores information about reference given by one party about another.
  • HZ_CERTIFICATIONS : Stores information about the certifications given by other parties.

LOGICAL MODEL DIAGRAM




PARTIES – TYPE PERSON


      The tables are as follows:-
  • HZ_PERSON_PROFILES : Stores details information about people.
  • HZ_PERSON_LANGUAGES :Stores information about the language that a person speaks, reads or writes
  • HZ_PERSON_INTEREST : Stores information about a person’s personal interests.
  • HZ_ CITIZENSHIP : Stores information about a person’s claimed nationality.
  • HZ_EDUCATIONS : Store information about a person educations.
  • HZ_EMPLOYMENT_HISTORY : Stores information about where the person has been employed.

LOGICAL MODEL DIAGRAM



 PARTIES – TYPE ORGANIZATION


 The tables are as follows:-
  • HZ_ORGANIZATION_PROFILES : Stores details information about credit rating, financial statistics, socio-economic and corporate linkage information.
  • HZ_STOCK_MARKETS :Stores information about the selling and buying of financial instruments.
  • HZ_SECURITY_ISSUED : Stores information about financial instruments such as stocks and bonds that has been issued by the organization.
  • HZ_INDUSTRIAL_CLASS_APP : It is a intersection tables that link industrial classifications stores in HZ_INDUSTRIAL_CLASSES .
  • HZ_INDUSTRIAL_CLASSES : Stores information about names and descriptions of industrial classifications.
  • HZ_FINANCIAL_REPORTS : Store information details of financial reports that describe the financial status of the party.
  • HZ_INDUSTRIAL_REFERENCE : Stores information about industrial reference for organization.

LOGICAL MODEL DIAGRAM










CUSTOMER ACCOUNTS


The tables are as follows:-
  • HZ_CUST_ACCOUNTS : Stores information about the relationship, if a party becomes a customer. Basically stores information about customer accounts.
  • HZ_CUST_ACCT_SITES_ALL : Stores information about customer sites. One customer can have more then multiple sites.
  • HZ_CUST_SITE_USES_ALL : Stores information about site uses or business purpose. A Single customer site can have multiple sites uses such as Bill To or Ship To.
  • HZ_CUST_ACCT_RELATE_ALL : Stores information about relationships between customer accounts.
  • HZ_CUST_ACCOUNT_ROLES : Stores information about the roles that parties perform in customer accounts.
  • HZ_BILLING_PREFERENCES : It describe the invoicing format preferred by customer accounts or customer account sites.
  • HZ_CUSTOMER_PROFILES : Stores credit information for a customer account and customer account sites.
  • HZ_CUST_PROFILE_AMTS : Stores profile amount limits for every currency defined for a customer account or customer account site profile.
  • HZ_CUST_PROF_CLASS_AMTS :Stores customer profile class amount limits for currency.
  • HZ_CUST_PROFILE_CLASSES : Stores standard credit profile classes.

LOGICAL MODEL DIAGRAM






CONTACT POINTS


      The tables are as follows:-
  • HZ_CONTACT_POINTS : Stores electronic methods of communicating with entities such as parties, party site. Each record in this table represents s different means of contacting an entity.
  • HZ_CUST_CONTACT_POINTS : This table is used to tie a contact point to a customer account, customer account site or customer account role.
  • HZ_CONTACT_RESTRICTIONS : It stores information about restrictions on contacting parties.

LOGICAL MODEL DIAGRAM




SITES/LOCATIONS


      The tables are as follows:-

  • HZ_PARTIES_SITES : Stores information about parties and locations.  Because there is a many-to-many relationship between parties and locations.
  • HZ_PARTIES_SITE_USES : Stores information about the party site uses and business purposes. A party site can have multiple site uses such as ‘bill to’ or ‘ship to’ and each site is stores as a record in this table.
  • HZ_LOCATIONS : Stores information about the locations, namely, address information
  • HZ_LOC_ASSIGNMENTS : It ties locations stored in HZ_LOCATIONS to a LOC_ID stored in AR_LOCATIONS_COMBINATIONS

LOGICAL MODEL DIAGRAM




post signature