Showing posts with label Tables. Show all posts
Showing posts with label Tables. Show all posts

Friday, 17 April 2015

Global Temporary Tables

The DECLARE GLOBAL TEMPORARY TABLE statement defines a temporary table for the current connection.

These tables do not reside in the system catalogs and are not persistent. Temporary tables exist only during the connection that declared them and cannot be referenced outside of that connection. When the connection closes, the rows of the table are deleted, and the in-memory description of the temporary table is dropped.
Temporary tables are useful when:
  • The table structure is not known before using an application.
  • Other users do not need the same table structure.
  • Data in the temporary table is needed while using the application.
  • The table can be declared and dropped without holding the locks on the system catalog.


1. Create Global Temporary  Table and Insert Rows and Run Select Statement to See Values from the Table.

 --DROP TABLE SUPPLIERS_TEMP;

/*
CREATE GLOBAL TEMPORARY TABLE SUPPLIERS_TEMP
( SUPPLIER_ID NUMERIC(10) NOT NULL,
SUPPLIER_NAME VARCHAR2(50) NOT NULL,
CONTACT_NAME VARCHAR2(50)
) ON COMMIT DELETE ROWS; --ON COMMIT DELETE ROWS clause indicates that the data should be deleted at the end of the transaction.
*/

CREATE GLOBAL TEMPORARY TABLE SUPPLIERS_TEMP
( SUPPLIER_ID NUMERIC(10) NOT NULL,
SUPPLIER_NAME VARCHAR2(50) NOT NULL,
CONTACT_NAME VARCHAR2(50)
) ON COMMIT PRESERVE ROWS; --ON COMMIT PRESERVE ROWS clause indicates that rows should be preserved until the end of the session.

 BEGIN
INSERT INTO SUPPLIERS_TEMP VALUES (1, 'Dheeraz Thandlam', 'Son of Lokanadham Thandlam');
INSERT INTO SUPPLIERS_TEMP VALUES (2, 'Nishanth Thandlam', 'Son of Lokanadham Thandlam');
INSERT INTO SUPPLIERS_TEMP VALUES (3, 'Sasi Thandlam', 'Wife of Lokanadham Thandlam');
END;


SELECT * FROM SUPPLIERS_TEMP




2. Close the Current Session.


3. Open New Session with Same Schema



4. Run The select Statement again to check the rows. But No Rows Returned.




Monday, 16 March 2015

Table and Column Registration in APPS

CREATE TABLE WIP_ITEM
(
   ITEM               VARCHAR2 (15),
   ITEMDESCRIPTION    VARCHAR2 (100),
   ITEMCOST           NUMBER (8),
   CATEGORYK          VARCHAR2 (100),
   CREATION_DATE      DATE,
   CREATED_BY         NUMBER (7),
   LAST_UPDATE_DATE   DATE,
   LAST_UPDATED_BY    NUMBER (7),
   ATTRIBUTE_CAT      VARCHAR2 (100),
   ATTRIBUTE1         VARCHAR2 (100),
   ATTRIBUTE2         VARCHAR2 (100),
   ATTRIBUTE3         VARCHAR2 (100),
   ATTRIBUTE4         VARCHAR2 (100),
   ATTRIBUTE5         VARCHAR2 (100)
);



/*
begin
 AD_DD.REGISTER_TABLE
(p_appl_short_name,
p_tab_name, --table name
p_tab_type,
p_next_extent, -- Enter the initial and next extent sizes in kilobytes for your table. You must enter values greater than 0.
p_pct_free,--free storage.
p_pct_used);-- used storage.
end; */


BEGIN
 AD_DD.REGISTER_TABLE('WIP','WIP_ITEM','T',8,10,90);
 COMMIT;
END;


Query with Table Name 
























/*
Registering the Columns:
Syntax:  AD_DD.REGISTER_COLUMN p_appl_short_name,
p_tab_name,
p_col_name,
p_col_seq,
p_col_type,
p_col_width,
p_nullable,
p_translate,
p_precision default null,
p_scale default null);
*/

BEGIN

 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','ITEM',1,'VARCHAR2',15,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','ITEMDESCRIPTION',2,'VARCHAR2',100,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','ITEMCOST',3,'NUMBER',8,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','CATEGORYK',4,'VARCHAR2',100,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','CREATION_DATE',5,'DATE',11,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','CREATED_BY',6,'NUMBER',7,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','LAST_UPDATE_DATE',7,'DATE',11,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','LAST_UPDATED_BY',8,'NUMBER',7,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','ATTRIBUTE_CAT',9,'VARCHAR2',100,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','ATTRIBUTE1',10,'VARCHAR2',100,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','ATTRIBUTE2',11,'VARCHAR2',100,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','ATTRIBUTE3',12,'VARCHAR2',100,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','ATTRIBUTE4',13,'VARCHAR2',100,'N','Y');
 AD_DD.REGISTER_COLUMN('WIP','WIP_ITEM','ATTRIBUTE5',14,'VARCHAR2',100,'N','Y');
 COMMIT;

END;

Query with Table Name 

Wednesday, 17 September 2014

Oracle Apps TCA Tables

Introduction

Oracle Applications R12 Trading Community Architecture Tables

Background

What is TCA?
Oracle Trading Community Architecture (TCA) is a data model that allows you to manage complex information about the parties, or customers.
Trading Community Architecture is the implementation of technology and applications to allow users to create and maintain relationships among entities. It is a way to understand who your customer interacts with inside and outside the enterprise.

The code

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.

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.

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.



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.



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.



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