Professional Documents
Culture Documents
---- SQL is a query language that allows you to issue a single query or execute a single
insert/update/delete. PL-SQL is Oracle's "Programming Language" SQL, which allows you
to write a full program (loops, variables, etc.) to accomplish multiple
selects/inserts/updates/deletes.
---- 1.) SQL is a data oriented language for selecting and manipulating sets of data. PL/SQL
is a procedural language to create applications.
2.) PL/SQL can be the application language just like Java or PHP can. PL/SQL might be the
language we use to build, format and display those screens, web pages and reports.SQL
may be the source of data for our screens, web pages and reports.
3.) SQL is executed one statement at a time. PL/SQL is executed as a block of code.
4.) SQL tells the database what to do (declarative), not how to do it. In contrast, PL/SQL tell
the database how to do things (procedural).
5.) SQL is used to code queries, DML and DDL statements. PL/SQL is used to code
program blocks, triggers, functions, procedures and packages.
6.) We can embed SQL in a PL/SQL program, but we cannot embed PL/SQL within a SQL
statement.
---- 1.) SQL is a data oriented language for selecting and manipulating sets of data. PL/SQL
is a procedural language to create applications.
2.) PL/SQL can be the application language just like Java or PHP can. PL/SQL might be the
language we use to build, format and display those screens, web pages and reports.SQL
may be the source of data for our screens, web pages and reports.
3.) SQL is executed one statement at a time. PL/SQL is executed as a block of code.
4.) SQL tells the database what to do (declarative), not how to do it. In contrast, PL/SQL tell
the database how to do things (procedural).
6.) We can embed SQL in a PL/SQL program, but we cannot embed PL/SQL within a SQL
statement.
7.) SQL is a language that is used by relational database technologies such as Oracle,
Microsoft Access, and Sybase etc., PL/SQL is commonly used to write data-centric
programs to manipulate data in an Oracle database. PL/SQL language includes object
oriented programming techniques such as encapsulation, function overloading, and
information hiding (all but inheritance).
---- An SQL JOIN clause is used to combine rows from two or more tables, based
on a common field between them.
The most common type of join is: SQL INNER JOIN (simple join). An SQL
INNER JOIN return all rows from multiple tables where the join condition is met.
In this kind of a JOIN, we get all records that match the condition in both the tables, and
records in both the tables that do not match are not reported.
In other words, INNER JOIN is based on the single fact that : ONLY the matching entries in
BOTH the tables SHOULD be listed.
Note that a JOIN without any other JOIN keywords (like INNER, OUTER, LEFT, etc) is an
INNER JOIN. In other words, INNER JOIN is a Syntactic sugar for JOIN (see : Difference
between JOIN and INNER JOIN).
2. OUTER JOIN :
Either, the matched rows from one table and all rows in the other table Or, all rows in all
tables (it doesn't matter whether or not there is a match).
In other words, OUTER JOIN is based on the fact that : ONLY the matching entries in ONE
OF the tables (RIGHT or LEFT) or BOTH of the tables(FULL) SHOULD be listed.
1. the JOIN is made on all the columns with the same name for equality.
2. Removes duplicate columns from the result.
This seems to be more of theoretical in nature and as a result (probably) most DBMS don't
even bother supporting this.
4. CROSS JOIN :
It is the Cartesian product of the two tables involved. The result of a CROSS JOIN will not
make sense in most of the situations. Moreover, we wont need this at all (or needs the
least, to be precise).
5. SELF JOIN :
It is not a different form of JOIN, rather it is a JOIN (INNER, OUTER, etc) of a table to itself.
View:
---- Views are virtual only and run the query definition each time they are accessed
Views are logical virtual table created by “select query” but the result is not stored anywhere
in the disk and every time we need to fire the query when we need data, so always we get updated
or latest data from original tables. Performance of the view depend upon our select query. If we want
to improve the performance of view we should avoid to use join statement in our query or if we need
multiple joins between table always try to use index based column for joining as we know index
based columns are faster than non index based column. View allow to store definition of the query in
the database itself.
2.This feature is commonly referred to in the MSSQL community as a derived table, and in the Postgres
community simply refers to it as a subselect (subselects are inline views + subqueries in Oracle nomenclature
Select statement follows from clause of the sub query is called inline view
Example:
SELECT ENAME,SAL,E1.DEPTNO,E2.MAXSAL FROM EMP E1,
(SELECT DEPTNO,MAX(SAL) MAXSAL FROM EMP GROUP BY DEPTNO order by deptno)E2
WHERE E1.DEPTNO=E2.DEPTNO AND E1.SAL<E2.MAXSAL;
(Or)
select max(age)
from (
-- this part of the query is an inline view:
select age from table
)
GOOD SQL:
select employee, sum(bonus) from emp_bonus
group by employee having sum(bonus) > 1000;
where clause+having clause ---posible
where clause +group by clause ----not possible
groupby clause+having clause ----posible
We can write orderby clause with all clauses based on condition.
Eg:- SELECT cust_name, dept_no FROM Customer WHERE cust_name IN (SELECT cust_name
FROM Customer);
Correlated subquery:-The outer query will get executed first and for every row of outer query,
inner query will get executed. So the inner query will get executed as many times as no.of
rows in result of the outer query.The outer query output can use the inner query output for
comparison. This means inner query and outer query dependent on each other
1. CUBE generates a result set that shows aggregates for all combinations of values in the
selected columns.
In addition to the subtotals generated by the ROLLUP extension, the CUBE extension will generate subtotals for
all combinations of the dimensions specified. If "n" is the number of columns listed in the CUBE, there will be
2nsubtotal combinations.
SELECT fact_1_id,
fact_2_id,
SUM(sales_value) AS sales_value
FROM dimension_tab
GROUP BY CUBE (fact_1_id, fact_2_id)
ORDER BY fact_1_id, fact_2_id;
18 rows selected.
2. ROLLUP generates a result set that shows aggregates for a hierarchy of values in the selected
columns.
----the ROLLUP extension produces group subtotals from right to left and a grand total. If "n" is the
number of columns listed in the ROLLUP, there will be n+1 levels of subtotals. Looking at the output in
a SQL*Plus or a grid output, you can visually identify the rows containing subtotals as they have null
values in the ROLLUP columns. Obviously, if the raw data contains null values, using this visual
identification is not an accurate approach
SELECT fact_1_id,
fact_2_id,
SUM(sales_value) AS sales_value
FROM dimension_tab
GROUP BY ROLLUP (fact_1_id, fact_2_id)
ORDER BY fact_1_id, fact_2_id;
13 rows selected.
Let's say you would like to retrieve a list of the highest paid salaries in each
dept:
FROM employee
GROUP BY dept;
This statement will select the maximum salary for the people in each unique
department. Basically, the salary for the person who makes the most in each
department will be displayed. Their, salary and their department will be
returned.
IN:
The Oracle PL/SQL IN operator allows testing a term of a condition by comparing it for equality
with a list of fixed values. The condition defined using the IN operator is also known as
themembership condition. IN works with values of all data types. When using characters, dates,
or other non-numeric strings, the list items must be enclosed with single quotation marks (for
example, '2010-09-22'), as shown in the second example below.
Example Syntax:
1)
SELECT *
FROM EMPLOYEES
FROM EMPLOYEES
---- A pseudo-column is an Oracle assigned value (pseudo-field) used in the same context as an
Oracle Database column, but not stored on disk. SQL and PL/SQL recognizes the following SQL
pseudocolumns, which return specific data items: SYSDATE, SYSTIMESTAMP, ROWID,
ROWNUM, UID, USER, LEVEL, CURRVAL, NEXTVAL, ORA_ROWSCN, etc.
Pseudocolumns are not actual columns in a table but they behave like columns. For example, you can
select values from a pseudocolumn. However, you cannot insert into, update, or delete from a
pseudocolumn. Also note that pseudocolumns are allowed in SQL statements, but not in procedural
statements.
The LAG function is used to access data from a previous row. The following query returns the salary from the
previous row to calculate the difference between the salary of the current row and that of the previous row.
Notice that the ORDER BY of the LAG function is used to order the data by salary.
SELECT empno,
ename,
job,
sal,
LAG(sal, 1, 0) OVER (ORDER BY sal) AS sal_prev,
sal - LAG(sal, 1, 0) OVER (ORDER BY sal) AS sal_diff
FROM emp;
Lead: The LEAD function is used to return data from the next row. The following query
returns the salary from the next row to calulate the difference between the salary of the
current row and the following row.
The LEAD function is used to return data from the next row. The following query returns the salary from the
next row to calulate the difference between the salary of the current row and the following row.
SELECT empno,
ename,
job,
sal,
LEAD(sal, 1, 0) OVER (ORDER BY sal) AS sal_next,
LEAD(sal, 1, 0) OVER (ORDER BY sal) - sal AS sal_diff
FROM emp;
the aggregate function reduces the number of rows returned by the query. The GROUP BY clause allows us to
apply aggregate functions to subsets of rows.
Analytic functions also operate on subsets of rows, similar to aggregate functions in GROUP BY queries, but
they do not reduce the number of rows returned by the query. For example, the following query reports the
salary for each employee, along with the average salary of the employees within the department.
SQL>
This time AVG is an analytic function, operating on the group of rows defined by the contents of
the OVER clause. This group of rows is known as a window, which is why analytic functions are sometimes
referred to as window[ing] functions. Notice how the AVG function is still reporting the departmental average,
like it did in the GROUP BY query, but the result is present in each row, rather than reducing the total number
of rows returned. This is because analytic functions are performed on a result set after all join, WHERE, GROUP
BY and HAVING clauses are complete, but before the final ORDER BY operation is performed.
AVG *
CORR *
COUNT *
COVAR_POP *
COVAR_SAMP *
CUME_DIST
DENSE_RANK
FIRST
FIRST_VALUE *
LAG
LAST
LAST_VALUE *
LEAD
LISTAGG
MAX *
MIN *
NTH_VALUE *
NTILE
PERCENT_RANK
PERCENTILE_CONT
PERCENTILE_DISC
RANK
RATIO_TO_REPORT
REGR_ (Linear Regression) Functions *
ROW_NUMBER
STDDEV *
STDDEV_POP *
STDDEV_SAMP *
SUM *
VAR_POP *
VAR_SAMP *
VARIANCE *
Conversion functions convert a value from one datatype to another. Generally, the form of
the function names follows the convention datatype TO datatype. The first datatype is the
input datatype. The second datatype is the output datatype. The SQL conversion functions
are:
ASCIISTR
BIN_TO_NUM
CAST
CHARTOROWID
COMPOSE
CONVERT
DECOMPOSE
HEXTORAW
NUMTODSINTERVAL
NUMTOYMINTERVAL
RAWTOHEX
RAWTONHEX
ROWIDTOCHAR
ROWIDTONCHAR
SCN_TO_TIMESTAMP
TIMESTAMP_TO_SCN
TO_BINARY_DOUBLE
TO_BINARY_FLOAT
TO_CHAR (character)
TO_CHAR (datetime)
TO_CHAR (number)
TO_CLOB
TO_DATE
TO_DSINTERVAL
TO_LOB
TO_MULTI_BYTE
TO_NCHAR (character)
TO_NCHAR (datetime)
TO_NCHAR (number)
TO_NCLOB
TO_NUMBER
TO_DSINTERVAL
TO_SINGLE_BYTE
TO_TIMESTAMP
TO_TIMESTAMP_TZ
TO_YMINTERVAL
TO_YMINTERVAL
TRANSLATE ... USING
UNISTR
This characteristics make B-Tree indexes very useful for speeding searches in OLTP applications,
when you are working with very small data sets at a time, most queries filter by ID, and you want
good concurrent performance.
Bitmap indexes are mostly used in data warehouse applications, where the database is read only
except for the ETL processes, and you usually need to execute complex queries against a star
schema, where bitmap indexes can speed up filtering based on conditions in your dimension tables,
which do not usually have too many distinct values.
As a very short summary: use B-Tree indexes (the "default" index in most databases) unless you are a
data warehouse developer and know you will benefit for a bitmap index.
1. B-tree Index has low cardinality values, where as Bitmap Index has High Cardinality values.
2. B-tree Index is userful for OLTP, where as Bitmap Index is useful for Dataware Housing.
3. B-tree index updates on key values has relatively inexpensive, where as Bitmap index has more expensive.
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.
Syntax
DECLARE GLOBAL TEMPORARY TABLE table-Name
{ column-definition [ , column-definition ] * }
[ ON COMMIT {DELETE | PRESERVE} ROWS ]
NOT LOGGED [ON ROLLBACK DELETE ROWS]
25. What is the difference between primary key and forigen key?
Primary Key:
Foreign Key:
It will allow "Null values" and "Duplicte values" and it refers to a primary key in
anoter table.
Difference between Primary Key & Foreign Key
Primary Key
Foreign Key
Primary key uniquely identify a record in the table.
Foreign key is a field in the table that is primary key in another table.
Primary Key can't accept null values.
Foreign key can accept multiple null value.
By default, Primary key is clustered index and data in the database table is physically organized in the
sequence of clustered index.
Foreign key do not automatically create an index, clustered or non-
clustered. You can manually create an index on foreign key.
We can have only one Primary key in a table.
We can have more than one foreign key in a table.
Syntax
Consider the following example where data from the HR_RECORDS table is merged into the EMPLOYEES table.
Savepoint names must be distinct within a given transaction. If you create a second
savepoint with the same identifier as an earlier savepoint, then the earlier savepoint is
erased. After a savepoint has been created, you can either continue processing, commit
your work, roll back the entire transaction, or roll back to the savepoint.
Example
UPDATE employees
SET salary = 7000
WHERE last_name = 'Banda';
SAVEPOINT banda_sal;
UPDATE employees
SET salary = 12000
WHERE last_name = 'Greene';
SAVEPOINT greene_sal;
COMMIT;
Commit:
Make permanent changes to data (inserts, updates, deletes) in the database. Before
changes are committed, both the old and new data exist so that changes can be stored or
the data can be restored to its prior state.
Example
* PRAGMA AUTONOMOUS_TRANSACTION
* PRAGMA SERIALLY_REUSABLE
* PRAGMA RESTRICT_REFRENCES
* PRAGMA EXCEPTION_INIT
* PRAGMA INLINE
1. We can execute a stored procedure whenever we want with the help of the exec command,
but a trigger can only be executed whenever an event (insert, delete, and update) is fired on
the table on which the trigger is defined.
2. We can call a stored procedure from inside another stored procedure but we can't directly call
another trigger within a trigger. We can only achieve nesting of triggers in which the action
(insert, delete, and update) defined within a trigger can initiate execution of another trigger
defined on the same table or a different table.
3. Stored procedures can be scheduled through a job to execute on a predefined time, but we
can't schedule a trigger.
4. Stored procedure can take input parameters, but we can't pass parameters as input to a trigger.
5. Stored procedures can return values but a trigger cannot return a value.
6. We can use Print commands inside a stored procedure for debugging purposes but we can't
use print commands inside a trigger.
7. We can use transaction statements like begin transaction, commit transaction, and rollback
inside a stored procedure but we can't use transaction statements inside a trigger.
8. We can call a stored procedure from the front end (.asp files, .aspx files, .ascx files, etc.) but
we can't call a trigger from these files.
9. Stored procedures are used for performing tasks. Stored procedures are normally used for
performing user specified tasks. They can have parameters and return multiple results sets.
10. The Triggers for auditing work: Triggers normally are used for auditing work. They can be
used to trace the activities of table events.
These functions work with any data type and pertain to the use of null values in the expression list.
These functions use of null value and returns result value.
Example
ID SALARY COMMISSION
1 10000 0.05
2 8000 null
3 5000 0.1
select ID, SALARY, (NVL(COMMISSION,1)*SALARY)+SALARY as COM_SALARY from
employees;
Result :
ID SALARY COM_SALARY
1 10000 10500
2 8000 8000
3 5000 5500
If you do not use NVL function, when COM_SALARY have a null value, print null.
might not see it) at some time or the other during the development process. In this blog post, we will cover why
this error occurs and how we can resolve it using different methodology.
Mutating error normally occurs when we are performing some DML operations and we are trying to select the
affected record from the same trigger. So basically we are trying to select records in the trigger from the table
that owns the trigger. This creates inconsistency and Oracle throws a mutating error. Let us take a simple
scenario in which we have to know total number of invalid objects after any object status is updated to
‘INVALID’. We will see it with an example. First let us create a table and then trigger.
Table created.
DECLARE
v_Count NUMBER;
BEGIN
SELECT count(*)
INTO v_count
FROM TEST
END;
Now if we try to change the status of any object to ‘INVALID’, we will run into mutating error as we are trying to
update the record and trigger is trying to select total number of records in ‘INVALID’ status from the same table.
Having said that there are different ways we can handle mutating table errors. Let us start taking one
by one scenario.
First one is to create statement level trigger instead of row level. If we omit the ‘for each row’ clause
from above trigger, it will become statement level trigger. Let us create a new statement level trigger.
SELECT count(*)
INTO v_count
FROM TEST
END;
1 row updated.
When we defined statement level trigger, update went through fine and it displayed the total number of invalid
objects.
Why this is a problem when we are using ‘FOR EACH ROW’ clause? As per Oracle documentation, the session,
which issues a triggering statement on the table, cannot query the same table so that trigger cannot see
inconsistent data. This restriction applies to all the row level triggers and hence we run into mutating table error.
Second way of dealing with the mutating table issue is to declare row level trigger as an autonomous
transaction so that it is not in the same scope of the session issuing DML statement. Following is the row level
SELECT count(*)
INTO v_count
FROM TEST
END;
Now let is issue the update statement again and observe the results.
1 row updated.
If you closely look at the output, you will see only 5 objects shown in invalid status while statement level trigger
showed 6 objects in invalid status. Let us try to update multiple objects at the same time.
2 rows updated.
By defining row level trigger as an autonomous transaction, we got rid of mutating table error but result is not
correct. The latest updates are not getting reflected in our result set as oppose to statement level trigger. So one
In version 11g, Oracle made it much easier with introduction of compound triggers. We have covered compound
triggers in a previous blog post. Let us see in this case how a compound trigger can resolve mutating table
/* Declaration Section*/
v_count NUMBER;
BEGIN
dbms_output.put_line(‘Update is done’);
AFTER STATEMENT IS
BEGIN
SELECT count(*)
INTO v_count
FROM TEST
END TEST_TRIG_COMPOUND;
/
Now let us check how many objects are invalid in the test table.
COUNT(*)
———-
Update is done
1 row updated.
Here we get correct result without getting mutating table error. This is also one very good advantage of
compound triggers. There are other ways also to resolve mutating table error using temporary tables but we
Dynamic SQL is a programming technique that enables you to build SQL statements dynamically at
runtime. You can create more general purpose, flexible applications by using dynamic SQL because
the full text of a SQL statement may be unknown at compilation. For example, dynamic SQL lets
you create a procedure that operates on a table whose name is not known until runtime.
In past releases of Oracle, the only way to implement dynamic SQL in a PL/SQL application was by
using the DBMS_SQL package. Oracle8i introduces native dynamic SQL, an alternative to the
DBMS_SQL package. Using native dynamic SQL, you can place dynamic SQL statements directly into
PL/SQL blocks
You should use dynamic SQL in cases where static SQL does not support the operation
you want to perform, or in cases where you do not know the exact SQL statements that
must be executed by a PL/SQL procedure. These SQL statements may depend on user
input, or they may depend on processing work done by the program. The following
sections describe typical situations where you should use dynamic SQL and typical
problems that can be solved by using dynamic SQL
In PL/SQL, you can only execute the following types of statements using dynamic SQL,
rather than static SQL:
Ex:
DECLARE
deptid NUMBER;
ename VARCHAR2(20);
BEGIN
EXECUTE IMMEDIATE 'SELECT d.id, e.name
FROM dept_new d, TABLE(d.emps) e -- not allowed in static SQL
-- in PL/SQL
WHERE e.id = 1'
INTO deptid, ename;
END;
A cursor is a temporary work area created in the system memory when a SQL statement is executed. A
cursor contains information on a select statement and the rows of data accessed by it.
This temporary work area is used to store the data retrieved from the database, and manipulate this data.
A cursor can hold more than one row, but can process only one row at a time. The set of rows the cursor
holds is called the active set.
Implicit cursors
These are created by default when DML statements like, INSERT, UPDATE, and DELETE statements are
executed. They are also created when a SELECT statement that returns just one row is executed.
Explicit cursors
They must be created when you are executing a SELECT statement that returns more than one row. Even
though the cursor stores multiple records, only one record can be processed at a time, which is called as
current row. When you fetch a row the current row position moves to next row.
Both implicit and explicit cursors have the same functionality, but they differ in the way they are accessed.
Command> DECLARE
> v_lname VARCHAR2 (15);
> BEGIN
> SELECT last_name INTO v_lname
> FROM employees
> WHERE first_name = 'John';
> DBMS_OUTPUT.PUT_LINE ('Last name is :' || v_lname);
> END;
> /
8507: ORA-01422: exact fetch returns more than requested number of rows
8507: ORA-06512: at line 4
The command failed.
You can handle such exceptions in your PL/SQL block so that your program completes
successfully. For example:
Command> DECLARE
> v_lname VARCHAR2 (15);
> BEGIN
> SELECT last_name INTO v_lname
> FROM employees
> WHERE first_name = 'John';
> DBMS_OUTPUT.PUT_LINE ('Last name is :' || v_lname);
> EXCEPTION
> WHEN TOO_MANY_ROWS THEN
> DBMS_OUTPUT.PUT_LINE (' Your SELECT statement retrieved multiple
> rows. Consider using a cursor.');
> END;
> /
Your SELECT statement retrieved multiple rows. Consider using a cursor.
Exception types
In TimesTen, these three types of exceptions are used in the same way as in Oracle
Database.
Trap a predefined TimesTen error by referencing its predefined name in your exception-
handling routine. PL/SQL declares predefined exceptions in theSTANDARD package.
Predefined exceptions
Oracle
error
Exception name number SQLCODE Description
You can define your own exceptions in PL/SQL in TimesTen, and you can raise user-defined
exceptions explicitly with either the PL/SQL RAISE statement or
theRAISE_APPLICATION_ERROR procedure.
In this example, the department number 500 does not exist, so no rows are updated in
the departments table. The RAISE statement is used to explicitly raise an exception and
display an error message, returned by the SQLERRM built-in function, and an error code,
returned by the SQLCODE built-in function. Use theRAISE statement by itself within an
exception handler to raise the same exception again and propagate it back to the calling
environment.
Command> DECLARE
> v_deptno NUMBER := 500;
> v_name VARCHAR2 (20) := 'Testing';
> e_invalid_dept EXCEPTION;
> BEGIN
> UPDATE departments
> SET department_name = v_name
> WHERE department_id = v_deptno;
> IF SQL%NOTFOUND THEN
> RAISE e_invalid_dept;
> END IF;
> ROLLBACK;
> EXCEPTION
> WHEN e_invalid_dept THEN
> DBMS_OUTPUT.PUT_LINE ('No such department');
> DBMS_OUTPUT.PUT_LINE (SQLERRM);
> DBMS_OUTPUT.PUT_LINE (SQLCODE);
> END;
> /
No such department
User-Defined Exception
1
Use an error number between -20,000 and -20,999. Specify a character string up to 2,048
bytes for your message.
Command> DECLARE
> v_last_name employees.last_name%TYPE := 'Patterson';
> BEGIN
> DELETE FROM employees WHERE last_name = v_last_name;
> IF SQL%NOTFOUND THEN
> RAISE_APPLICATION_ERROR (-20201, v_last_name || ' does not exist');
> END IF;
> END;
> /
8507: ORA-20201: Patterson does not exist
8507: ORA-06512: at line 6
The command failed.
Modularity
Packages let you encapsulate logically related types, items, and subprograms in a named
PL/SQL module. Each package is easy to understand, and the interfaces between
packages are simple, clear, and well defined. This aids application development.
When designing an application, all you need initially is the interface information in the
package specs. You can code and compile a spec without its body. Then, stored
subprograms that reference the package can be compiled as well. You need not define the
package bodies fully until you are ready to complete the application.
Information Hiding
With packages, you can specify which types, items, and subprograms are public (visible
and accessible) or private (hidden and inaccessible). For example, if a package contains
four subprograms, three might be public and one private. The package hides the
implementation of the private subprogram so that only the package (not your application)
is affected if the implementation changes. This simplifies maintenance and enhancement.
Also, by hiding implementation details from users, you protect the integrity of the
package.
Added Functionality
Packaged public variables and cursors persist for the duration of a session. So, they can be
shared by all subprograms that execute in the environment. Also, they allow you to
maintain data across transactions without having to store it in the database.
Better Performance
When you call a packaged subprogram for the first time, the whole package is loaded into
memory. So, later calls to related subprograms in the package require no disk I/O. Also,
packages stop cascading dependencies and thereby avoid unnecessary recompiling. For
example, if you change the implementation of a packaged function, Oracle need not
recompile the calling subprograms because they do not depend on the package body.
Modularity
Packages let you encapsulate logically related types, items, and subprograms in a named
PL/SQL module. Each package is easy to understand, and the interfaces between
packages are simple, clear, and well defined. This aids application development.
When designing an application, all you need initially is the interface information in the
package specs. You can code and compile a spec without its body. Then, stored
subprograms that reference the package can be compiled as well. You need not define the
package bodies fully until you are ready to complete the application.
Information Hiding
With packages, you can specify which types, items, and subprograms are public (visible
and accessible) or private (hidden and inaccessible). For example, if a package contains
four subprograms, three might be public and one private. The package hides the
implementation of the private subprogram so that only the package (not your application)
is affected if the implementation changes. This simplifies maintenance and enhancement.
Also, by hiding implementation details from users, you protect the integrity of the
package.
Added Functionality
Packaged public variables and cursors persist for the duration of a session. So, they can be
shared by all subprograms that execute in the environment. Also, they allow you to
maintain data across transactions without having to store it in the database.
Better Performance
When you call a packaged subprogram for the first time, the whole package is loaded into
memory. So, later calls to related subprograms in the package require no disk I/O. Also,
packages stop cascading dependencies and thereby avoid unnecessary recompiling. For
example, if you change the implementation of a packaged function, Oracle need not
recompile the calling subprograms because they do not depend on the package body.
REF cursor is typically used to return record set or a cursor from stored procedure. REF Cursor is
basically a data type. It is normally declared as type r_cursor is REF CURSOR; REF cursor supports
dynamic change of query.
Normal cursor is a static cursor in which the query is assigned at design time and cant be changed at
run time.
Difference between REF Cursor & Normal Cursor in Oracle - April 08, 2009 at 13:00 PM by Rajmeet Ghai
What is the difference between REF Cursor & Normal Cursor in oracle?
Normal cursors fall under the category of static cursors while REF cursors are dynamic. This means
that normal cursors can only be used again not defined. Ref cursors on the other hand can be
changed. A Ref cursor can be passed from one procedure to another. A normal cursor cannot.
Code Sharing
Stored procedures guarantee common code sharing, regardless of tool, language, or DML statement
origination. The code needs testing only once; it does not have to be retested every time it is used in a new
program.
Object Security
EXECUTE privilege is granted to a database user for the stored procedure, not for the tables that the
procedure may reference. This means that a DBA does not have to grant DML access on database objects for
a user to be able to update those objects. The owner of the stored procedure needs the correct privileges on
the underlying objects, but the calling user does not. The calling user does not even have to know the
procedure tables exist. The user needs only to be concerned about the fact that a result is achieved when he
or she calls a procedure, not how that result is arrived at.
Procedure Overlaying
Procedure overlaying is another powerful extension of stored procedures (and library procedures) that
developers should exploit. This overlaying can be a very elegant way to retrospectively alter and/or extend
business functionality. Overlaying allows the developer to define a procedure with several alternative
definitions to choose from. Each definition is checked until a parameter list type match is found.
Modularity
*************
Packages let you encapsulate logically related types, items, and subprograms
in a named PL/SQL module.
Each package is easy to understand, and the interfaces between packages are
simple, clear, and well
specs. You can code and compile a spec without its body. Then, stored
subprograms that reference the
package can be compiled as well. You need not define the package bodies
fully until you are ready to
Information Hiding
*******************
With packages, you can specify which types, items, and subprograms are
public (visible and accessible)
be public and one private. The package hides the implementation of the
private subprogram so that only
Added Functionality
********************
Packaged public variables and cursors persist for the duration of a session.
They can be shared by allsubprograms that execute in the environment. They
let you maintain data across transactions without
Better Performance
*******************
When you invoke a packaged subprogram for the first time, the whole package
is loaded into memory.
function; these subprograms only depend on the parameters and return value
that are declared in the
Function Overloading
*****************
you can use same procedure name more than one procedure with diff parameters
and their datatypes.
Procedure : Procedure does not return any values with return clause, however can return data with "out"
parameter to calling program
Function : Funcation must return values to calling program with return statement. Funcation can also returns
values with "out" parameter to calling program.
Package : Package is group of procedure, fuctions and data types ete. The package is faster as compared to
procedure or function. The package will be loaded on the memory when first execution and will be available
for subsequent calls, this way package is faster compared to procedure and functions.
Function Procedure
1. Can be used as column Cant used in select statement
in select statement
2. Can be used in where Cant used in where condition
condition
2. It must return value Return keyword can be used but will
with return keyword only pass control back to the main program.
Benefits
Functions:
Complex logic can be embedded in the function which can be used in query to filter the record selection.
Procedure:
It can be called standalone and process list of actions (although function can also do the same) to perform.
The only difference with respect to function is that it do not require any placeholder to hold the return value.
Package:
If any of the package component called the whole package gets compiled and remain loaded in the memory
untill flushed out (restart or using pragma serially_reusable).
Therefore whenever any function/procedure called the response time is fast.
Drawbacks:
Function:
1. If function has group by or any DML statement it cant be used inside select query.
Procedure:
It cant be called inside select/where statement.
Package:
If package procedure/function needs to be used only once, unnecessary the whole package gets loaded in the
memory.
Associative arrays, also known as index-by tables, let you look up elements using
arbitrary numbers and strings for subscript values. These are similar to hash tables
in other programming languages.
Nested tables hold an arbitrary number of elements. They use sequential numbers as
subscripts. You can define equivalent SQL types, allowing nested tables to be stored
in database tables and manipulated through SQL.
Varrays (short for variable-size arrays) hold a fixed number of elements (although
you can change the number of elements at runtime). They use sequential numbers
as subscripts. You can define equivalent SQL types, allowing varrays to be stored in
database tables. They can be stored and retrieved through SQL, but with less
flexibility than nested tables.
Although collections have only one dimension, you can model multi-dimensional arrays by
creating collections whose elements are also collections.
To use collections in an application, you define one or more PL/SQL types, then define
variables of those types. You can define collection types in a procedure, function, or
package. You can pass collection variables as parameters to stored subprograms.
To look up data that is more complex than single values, you can store PL/SQL records or
SQL object types in collections. Nested tables and varrays can also be attributes of object
types.
PL/SQL nested tables represent sets of values. You can think of them as one-dimensional
arrays with no declared number of elements. You can model multi-dimensional arrays by
creating nested tables whose elements are also nested tables.
Within the database, nested tables are column types that hold sets of values. Oracle stores
the rows of a nested table in no particular order. When you retrieve a nested table from the
database into a PL/SQL variable, the rows are given consecutive subscripts starting at 1.
That gives you array-like access to individual rows.
1. Nested tables do not have a declared number of elements, while arrays have a
predefined number as illustrated in Figure 5-1. The size of a nested table can
increase dynamically; however, a maximum limit is imposed. See "Referencing
Collection Elements".
2. Nested tables might not have consecutive subscripts, while arrays are always dense
(have consecutive subscripts). Initially, nested tables are dense, but they can
become sparse (have nonconsecutive subscripts). You can delete elements from a
nested table using the built-in procedure DELETE. The built-in function NEXT lets you
iterate over all the subscripts of a nested table, even if the sequence has gaps.
Understanding Varrays
Items of type VARRAY are called varrays. They let you reference individual elements for array
operations, or manipulate the collection as a whole. To reference an element, you use
standard subscripting syntax (see Figure 5-2). For example, Grade(3) references the third
element in varray Grades.
A varray has a maximum size, which you specify in its type definition. Its index has a fixed
lower bound of 1 and an extensible upper bound. For example, the current upper bound for
varray Grades is 7, but you can increase its upper bound to maximum of 10. A varray can
contain a varying number of elements, from zero (when empty) to the maximum specified
in its type definition.
Associative arrays are sets of key-value pairs, where each key is unique and is used to
locate a corresponding value in the array. The key can be an integer or a string.
Assigning a value using a key for the first time adds that key to the associative array.
Subsequent assignments using the same key update the same entry. It is important to
choose a key that is unique. For example, key values might come from the primary key of a
database table, from a numeric hash function, or from concatenating strings to form a
unique string value.
Oracle provides a way to capture the error codes when a SQL statement raises an
exception by using the SQLCODEand SQLERRM globally-defined variables. Both
SQLCODEand SQLERRM can be useful in tracking exceptions that are handled by the
OTHERS clauseof the exception handler. SQLCODE returns the current error code from
the error stack. SQLERRM returns the error message from the current error code as
shown below.
SQL> declare
2 n_numb number := &Number;
3 n_2 number := 0;
4 begin
5 test_var(n_numb, n_2);
6 dbms_output.put_line(n_2);
7 exception
8 when others then
9 begin
10 dbms_output.put_line('SQLCODE: '||SQLCODE);
11 dbms_output.put_line('Message: '||SQLERRM);
12 end;
13 end;
14 /
Enter value for number: 105
old 2: n_numb number := &Number;
new 2: n_numb number := 105;
SQLCODE: -20010
Message: ORA-20010: Number Too Large
Using the same function from the previous example, a value greater than 100 will raise an
exception. The OTHERS clausein the exception handler caught the exception and printed
out the SQLCODEand SQLERRM. Once you know the error code, you can
programmatically handle the exception, like this:
SQL> declare
2 n_numb number := &Number;
3 n_2 number := 0;
4 begin
5 test_var(n_numb, n_2);
6 dbms_output.put_line(n_2);
7 exception
8 when others then
9 begin
10 if SQLCODE = -20010
11 then dbms_output.put_line('Value Too
Large');
12 else dbms_output.put_line('Unknown
Exception');
13 end if;
14 end;
15 end;
16 /
Exceptions are notifications that identify issues that need resolution. Oracle Collaborative
Planning generates an exception whenever an actual process does not match the required
process. For example, if you and your supplier's forecasts do not match, Oracle
Collaborative Planning generates a forecast mismatch exception. Exceptions ensure that the
decision-making process remains focused, occurs in a timely manner, and makes the supply
chain more responsive.
Oracle Collaborative Planning exceptions are grouped into several categories that
correspond to supply chain problems. The categories are:(seeded exceptions)
Late orders
Early orders
Material shortage
Material excess
Forecast mismatch
Response required
Change orders
Forecast accuracy
Exception notifications for an item are sent to the supply chain collaboration planner for the
item. If no planner is specified for an item, notification is sent to an Administrator. Any
planner can view an exception through the Exceptions tab. You can also view counts for a
given exception type.
CONDITIONAL STATEMENTS
IF-THEN-ELSE Statement
{...statements...}
END IF;
IF condition THEN
{...statements...}
ELSE
{...statements...}
END IF;
IF condition THEN
{...statements...}
{...statements...}
ELSE
{...statements...}
END IF;
( name_in IN varchar2 )
RETURN varchar2
IS
monthly_value number(6);
ILevel varchar2(20);
cursor c1 is
SELECT monthly_income
FROM employees
WHERE name = name_in;
BEGIN
open c1;
fetch c1 into monthly_value;
close c1;
ELSE
ILevel := 'High Income';
END IF;
RETURN ILevel;
END;
Case Statement
CASE [ expression ]
...
ELSE result
END
You could use the CASE statement in a SQL statement as follows: (includes the expression clause)
select table_name,
CASE owner
END
from all_tables;
GOTO Statement
The GOTO statement causes the code to branch to the label after the GOTO statement.
For example:
GOTO label_name;
Then later in the code, you would place your label and code associated with that label.
Label_name: {statements}
LOOPS
Loop Statement
FOR Loop
CURSOR FOR Loop
While Loop
Repeat Until Loop
Exit Statement
The PLSQL Engine first makes a copy of the record and then during program executing
makes a changes to that copy.
---- The NOCOPY hint tells the PL/SQL compiler to pass OUT and IN OUT parameters
by reference, rather than by value.
When parameters are passed by value, the contents of the OUT and IN OUT parameters
are copied to temporary variables, which are then used by the subprogram being called.
On successful completion of the subprogram the values are copied back to the actual
parameters, but unhandled exceptions result in the original parameter values being left
unchanged. The process of copying large parameters, such as records, collections, and
objects requires both time and memory which affects performance.
With the NOCOPY hint the parameters are passed by reference and on successful
completion the outcome is the same, but unhandled exceptions may leave the parameters
in an altered state, so programs must handle errors or cope with the suspect values.
The use of the NOCOPY hint does come with some drawbacks, as it can result in
parameter aliasing when global variables are passed as parameters to subprograms. A
parameter alias occurs when two variable names point to the same memory location. The
update_global.sql script shows how aliasing can occur if a global variable is accessed
directly from a procedure when it has also been passed as a NOCOPY parameter.
If an exception is raised and PL/SQL cannot find a handler for it in the current block, the
exception then propagates to successive enclosing blocks, until a handler is found or there are
no more blocks to propagate to. If no handler is found, PL/SQL returns an unhandled
exception error to the host environment.
Example Syntax:
Example Usage:
The PL/SQL block below selects an employee corresponding to a given employee IDd. If no
employee record is found it raises the NO_DATA_FOUND exception and displays a message.
Note that NO_DATA_FOUND is a system defined exception.
DECLARE
L_EMP VARCHAR2(1000);
CURSOR C IS
SELECT ENAME
FROM EMPLOYEE
WHERE EMPNO = 300;
BEGIN
OPEN C;
CLOSE C;
RAISE NO_DATA_FOUND;
END IF;
EXCEPTION
END;
raise_application_error(
error_number, message[, {TRUE | FALSE}]);
DECLARE
num_tables NUMBER;
BEGIN
SELECT COUNT(*) INTO num_tables FROM USER_TABLES;
IF num_tables < 1000 THEN
/* Issue your own error code (ORA-20101)
with your own error message. You need not
qualify RAISE_APPLICATION_ERROR with
DBMS_STANDARD */
RAISE_APPLICATION_ERROR
(-20101, 'Expecting at least 1000 tables');
ELSE
-- Do rest of processing (for nonerror case)
NULL;
END IF;
END;
----- Actual Parameters : Subprograms pass information using parameters. The variables or
expressions referenced in the parameter list of a subprogram call are actual parameters. For
example, the following procedure call lists two actual parameters named emp_num and amount:
Eg. raise_salary(emp_num, amount);
Formal Parameters : The variables declared in a subprogram specification and referenced in
the subprogram body are formal parameters. For example, the following procedure declares two
formal parameters named emp_id and increase: Eg. PROCEDURE raise_salary (emp_id
INTEGER, increase REAL) IS current_salary REAL;
---- There are two different kinds of parameters: actual and formal parameters.
The formal parameters are the names that are declared in the parameter list of the header of a
module.
The actual parameters are the values or expressions placed in the parameter list of the actual call to
the module.
Let’s examine the differences between actual and formal parameters using the example of tot_sales. Here is
tot_sales’ header:
FUNCTION tot_sales
(company_id_in IN company.company_id%TYPE,
status_in IN order.status_code%TYPE := NULL)
RETURN std_types.dollar_amount;
The formal parameters of tot_sales are:
They do not exist outside of the function. You can think of them as place holders for real or actual parameter
values that are passed into the function when it is used in a program.
When you use tot_sales in your code, the formal parameters disappear. In their place you list the actual
parameters or variables, whose values will be passed to tot_sales. In the following example, the company_id
variable contains the primary key pointing to a company record. In the first three calls to tot_sales a different,
hardcoded status is passed to the function. The last call to tot_sales does not specify a status; in this case the
function assigns the default value (provided in the function header) to the status_in parameter:
The actual parameters must be evaluated because they can be expressions, as well as pointers, to non-
PL/SQL objects such as bind variables in the development tool.
The formal parameter and the actual parameter that corresponds to the formal parameter (when called) must
be of the same or compatible datatypes. PL/SQL will perform datatype conversions for you in many situations.
Generally, however, you are better off avoiding all implicit datatype conversions so you are sure of what is
happening in your code. Use a formal conversion function like TO_CHAR or TO_DATE, so you know exactly
what kind of data you are passing into your modules.
I would never use either in the database as they add a lot of SQL complexity for no gain. In
a PL/SQL program you might use a nested table so that you can select from an in-memory
array as if it were a real table.
authors first fetch data from a table by using bulk collect statements. After that, they are inserting it into
target table by using the forall statement.
DECLARE
TYPE prod_tab IS TABLE OF products%ROWTYPE;
products_tab prod_tab := prod_tab();
BEGIN
-- Populate a collection - 100000 rows
SELECT * BULK COLLECT INTO products_tab FROM source_products;
this ref cursor allows us to any type of select statement irrespective of data
structure . i .e any table
---There are 2 types in this.
1.strong ref cursor:
This has a return type defined.
2. weak ref cursor.
this doesnt have a return type
normal cursor:
Nothing but the named memory location.
it has 2 types
1. explicit cursor
Need to be defined whenever required.
2.Implicit cursor
need not defined and used by oracle implicitly in DML operation.
Answer Question
--- In case of an normal explict cursor, the SQL query has to be defined at the time of declaring the cursor
itself. In case of REF Cursor, the cursor declartion is not associated with any SQL query, it is associated with
a query at a later stage this brings in a lot of flexibility as different SQL queries can be associated with the
cursor (one at a time, offcourse) programatically. REF Cursors also provide the feature of passing
parameters. Though there is something dynamic with REF Cursor when compared to a normal explicit cursor,
it is not a truly perfect dynamic cursor. Truly perfect dynamic cursors are the one constructed using
DBMS_SQL package.
Primary Key:
iii) Primary Key is unique key identifier and can not be null and must be unique.
Unique Key:
Note that to enable code to run with Invoker rights, the AUTHID clause must be used before
the IS or AS keyword in the routine header.
Invoker Rights
Invoker rights is a method present in Oracle 8i and greater that is used to resolve
references to database elements in a PL/SQL program unit. Using Invoker rights we can
instruct Oracle if a given program unit should run with the authority of the definer or of the
invoker. The result is that multiple schemas can share the same piece of code while
accessing only the elements which belong to the invoker.
---- There are lot of times we get error in Oracle Apps while trying to execute the API's at
development time, due to the AUTHID DEFINER and AUTHID CURRENT_USER. This article gives
you good understanding about the AUTHID DEFINER and AUTHID CURRENT_USER.
A stored procedure runs either with the rights of the caller (AUTHID CURRENT_USER) or with
the rights of the procedure's owner (AUTHID DEFINER). This behaviour is specified with
the AUTHID clause. This authid clause immediatly follows thecreate procedure, create
function, create package or create type statement. It can be ommited, in which case the
defaultauthid definer is taken.
Example:-
---------
The following are done in APPS scheme.
begin
xyz.XYZ_1;
end;
select * from a;
Provide grants for this package to other schema (scott) and create the synonym for the xyz
package in scott.
Example:-
---------
Now for the other schema SCOTT try to run the same query.
begin
xyz.XYZ_1;
end;
It have inserted new record in the 'A' table. Note there is no synonym for the table A in
SCOTT schema.
Running this program from anywhere, it is as good as running from APPS schema in case
of AUTHID DEFINER.
10.2) CURRENT_USER:-
----------------------
Example:-
-----------
begin
xyz.XYZ_1;
end;
select * from a;
Provide grants for this package to other schema (scott) and create the synonym for the xyz
package in scott.
Example:-
-----------
Now for the other schema (scott) try to run the same query.
begin
xyz.XYZ_1;
end;
Got the error message table or view doesn't exist for the A table.
Create view for the a table and run the same program again.
begin
xyz.XYZ_1;
end;
select * from a;
----- The authid current_user is used when you want a piece of code (PL/SQL) to
execute with the privileges of the current user, and NOT the user ID that created the
procedure. This is termed a "invoker rights", the opposite of "definer rights".
In the same sense, the authid current_user is the reverse of the "grant execute" where the
current user does not matter, the privileges of the creating user are used.
PL/SQL, by default, run with the privileges of the schema within which they are created no matter
who invokes the procedure. In order for a PL/SQL package to run with invokers rights AUTHID
CURRENT_USER has to be explicitly written into the package.
The authid current_user clause tells the kernel that any methods that may be used in the
type specification (in the above example, none) should execute with the privilege of the
executing user, not the owner.
The default option is authid definer, which would correspond to the behavior in pre-
Oracle8i releases, where the method would execute with the privileges of the user
creating the type.
See this example of authid current_user to understand how this syntax causes invoker
rights, which, in turn, changes the behavior of the PL/SQL code.
If you plan on updating or deleting records that have been referenced by a SELECT FOR UPDATE
statement, you can use the WHERE CURRENT OF statement.
UPDATE table_name
SET set_clause
WHERE CURRENT OF cursor_name;
OR
The WHERE CURRENT OF statement allows you to update or delete the record that was last
fetched by the cursor.
---- If you plan on updating or deleting records that have been referenced by a SELECT FOR
UPDATE statement, you can use the WHERE CURRENT OF statement.
The syntax for the WHERE CURRENT OF statement in Oracle/PLSQL is either:
UPDATE table_name
SET set_clause
OR
The WHERE CURRENT OF statement allows you to update or delete the record that was last fetched by the
cursor.
Here is an example where we are updating records using the WHERE CURRENT OF Statement:
CREATE OR REPLACE Function FindCourse
( name_in IN varchar2 )
RETURN number
IS
cnumber number;
CURSOR c1
IS
SELECT course_number
FROM courses_tbl
BEGIN
OPEN c1;
FETCH c1 INTO cnumber;
if c1%notfound then
cnumber := 9999;
else
UPDATE courses_tbl
SET instructor = 'SMITH'
WHERE CURRENT OF c1;
COMMIT;
end if;
CLOSE c1;
RETURN cnumber;
END;
( name_in IN varchar2 )
RETURN number
IS
cnumber number;
CURSOR c1
IS
SELECT course_number
from courses_tbl
BEGIN
open c1;
if c1%notfound then
cnumber := 9999;
else
COMMIT;
end if;
close c1;
RETURN cnumber;
END;
You use FORALL when working with collections and it has a better performance than FOR.
If you are working with individual items you have to use FOR.
----- FORALL is:
"The keyword FORALL instructs the PL/SQL engine to bulk-bind input collections before sending them to the
SQL engine. Although the FORALL statement contains an
iteration scheme, it is not a FOR loop.
The index can be referenced only within the FORALL statement and only as a collection subscript. The SQL
statement must be an INSERT, UPDATE, or DELETE statement that
references collection elements. And, the bounds must specify a valid range of consecutive index numbers.
The SQL engine executes the SQL statement once for each index
number in the range."
So there you go. Collections, BULK COLLECT and FORALL are the new features in Oracle 8i, 9i and 10g
PL/SQL that can really make a different to you PL/ SQL performance.
Hopefully, if you've not come across these areas before.
FORALL Syntax & Example:
FORALL IN ..
SAVE EXCEPTIONS;
FORALL IN INDICES OF
[BETWEEN AND ]
SAVE EXCEPTIONS;
FORALL IN INDICES OF
VALUES OF
SAVE EXCEPTIONS;
FOR ‘INSERT’
===========
CREATE TABLE servers2 AS
SELECT *
FROM servers
WHERE 1=2;
DECLARE
CURSOR s_cur IS
SELECT *
FROM servers;
TYPE fetch_array IS TABLE OF s_cur%ROWTYPE;
s_array fetch_array;
BEGIN
OPEN s_cur;
LOOP
FETCH s_cur BULK COLLECT INTO s_array LIMIT 1000;
FORALL i IN 1..s_array.COUNT
INSERT INTO servers2 VALUES s_array(i);
EXIT WHEN s_cur%NOTFOUND;
END LOOP;
CLOSE s_cur;
COMMIT;
END;
/
END forward_pack;
---- Special sub program unit declaration called forward
declaration, Consider below the example
END forward_pack;
57. What are who columns? Why we can use in the tables?
LAST_UPDATE_DATE,
LAST_UPDATED_BY,
CREATION_DATE,
CREATED_BY,
LAST_UPDATE_LOGIN
---- WHO columns are used to track the information updated or inserted by the users against the tables.
FND_STANDARD package is used for this purpose. FND_STANDARD.SET_WHO Procedure is used to
update the WHO columns in a Table when a DML operation s (i.e. INSERT, UPDATE) performed.
1) Created by
2) Creation date
3) Last _updated_by
4) last_update_date
5) last_update_login
Use fnd_profile.VALUE (‘USER_ID’) for retrieving the user_id which will be used by created_by
column.
Creation date and last_update_date will be normally SYSDATE.
last_updated_by is same as created_by.
Use USERENV (‘SESSIONID’) for getting the last_update_login id
Discoverer :
SELECT owner,table_name
FROM all_tables
WHERE owner = 'EUL4_US'
AND table_name LIKE '%DOCUMENT%';
Note:
If the First Query is not returning any data then try the following query and manually find the
table name.
SELECT owner,table_name
FROM all_tables
WHERE table_name LIKE '%EUL%DOCUMENT%';
You have to modify the 2nd query in this case with the new OWNER.TABLE_NAME
21. Explain me any 5 conversions along with the interface tables,errors tables and
validations
27. What is the multi org..?How to find multi org is installed in back end.
28. What are the changes in r12 related to it.
30. What is incompatibility ?can you set the same program incompatible to itself
31. What is the profile options and its levels and its back end tables?
36. How to generate the trace file for a plsql concurrent program for tuning
38. Where we can find log file and outputfile after submitting the concrrent program
39. How to get the data from 11i views and r12 synonyms
8. What is prepayment
10. Link between requisition and rfq,po and requisition,po and invoice,invoice and
payment
14. What are the bank tables and accounting tables in 11i as well as r12
17. What are the order types and order hold types in om
18. Tell me about pick slip report trip stop report
19. Where we can find applied amount and unapplied amount and balance amt in ar
22. What are the new features in om module and ar module in r12