This returns the following result:
ROWID
–––––––––
AAAMZzAAEAAAAB/Aau

The rowid will be different in different systems . It is a system generated number and cannot be predicted. That is the physical location for the record containing emp_name of employee ‘Peter’ in the EMPLOYEES table. It is unique to that record in the database.
ROWIDs use base-64 encoding and return the ten-byte value as a string when selected from SQL*Plus. The structure of the ROWID is easy to understand.

One of the biggest benefits of ROWID is the performance improvement it provides when using it to reference a record. No index is necessary, no determination needs to be made whether a full scan of the table is better, and there is no question of cardinality. ROWID provides the address to the record, so no interpretation is required at all. The following example illustrates how ROWID can be used in an UPDATE.

SET SERVEROUTPUT ON

DECLARE

/* Retrieve the rowid of the employees into the cursor */

CURSOR emp_rowid_cur

IS

SELECT a.rowid

FROM company a,employees b

Where a.company_name = ‘technoOracle’

AND (

a.id = b.employee

OR

a.id = b.manager

OR

a.id = b.progammer);

BEGIN

/* Loop through the records retrieved by the cursor and convert

the first and last names to uppercase */

FOR y IN emp_rowid_cur

LOOP

UPDATE employees

SET emp_first_name = UPPER(emp_first_name),

emp_last_name = UPPER(emp_last_name)

WHERE rowid = y.rowid;

END LOOP;

COMMIT;

EXCEPTION

WHEN OTHERS

THEN

DBMS_OUTPUT.PUT_LINE(sqlerrm);

END;

/

The following Table includes the most important parameters to set with performance implications:

Following Example shows a cursor named all_depts, and a record named dept that is based on that cursor.

Declaring a Record to Match a Cursor

1: DECLARE
2: CURSOR all_depts is
3: SELECT dept_id, dept_name
4: FROM department
5: ORDER BY dept_name;
6:
7: dept all_depts%ROWTYPE;
8: BEGIN
9: OPEN all_depts;
10:
11: LOOP
12: EXIT WHEN all_depts%NOTFOUND;
13: FETCH all_depts INTO dept;
14: DBMS_OUTPUT.PUT_LINE(dept.dept_name);
15: END LOOP;
16:
17: CLOSE all_depts;
18: END;
19: /

The cursor all_depts is declared in lines 2–5. In line 7, a record variable named
dept is declared based on the definition of the cursor. Because the variable dept
matches the cursor exactly, the FETCH statement in line 13 can fetch the results of the SELECT statement directly into the record. If at some point in the future you need to add columns to the select list, that change will automatically ripple through to the record definition,and the FETCH statement will continue to operate.

Here’s an example:

DECLARE
dept department%ROWTYPE;
BEGIN
SELECT * INTO dept
FROM department
WHERE dept_id = 502;
…
END;
/
You don’t have to use %ROWTYPE when you do this, and you don’t have to use SELECT * either. The Following Example  shows the dept record being declared without the use of %ROWTYPE,

Example

selects for department 452. If you don’t have that department,replace 452 with a valid number for your database.

Selecting Directly into a Record

1: DECLARE
2: TYPE dept_type IS RECORD
3: (
4: dept_id department.dept_id%type,
5: dept_name department.dept_name%type,
6: no_of_emps department.no_of_emps%type
7: );
8:
9: dept dept_type;
10: BEGIN
11: SELECT * INTO dept
12: FROM department
13: WHERE dept_id = 452;
14: END;
15: /

A record type named dept_type is defined in lines 2–7. The declaration in line 9
declares a variable named dept to be of type dept_type. Because the fields in the
dept_type record match exactly the fields in the Department table, the SELECT statement in lines 11–13 will work.

The Following example shows a SELECT statement other than SELECT *.

Selecting a Specific List of Fields into a Record

1: DECLARE
2: TYPE dept_type IS RECORD
3: (
4: dept_id department.dept_id%type,
5: dept_name department.dept_name%type,
6: no_of_emps department.no_of_emps%type
7: );
8:
9: dept dept_type;
10: BEGIN
11: SELECT dept_id, dept_name, no_of_emps INTO dept
12: FROM department
13: WHERE dept_id = 452;
14: END;
15: /
The three fields in the Department table are enumerated in the SELECT list.
Because the number of fields (and their datatypes) corresponds with the definition of the dept_type record, you are able to retrieve the data directly into a variable of  type dept_type.

The key thing to keep in mind when selecting data directly into a record is that the columns and datatypes represented in the SELECT list must correspond exactly to the fields and datatypes in the record definition. The column names and field names do not need to match, as Oracle assigns column values to fields in a record based on position,but the datatypes must match.

If you are using SELECT * to retrieve values from a table,you are safest using %ROWTYPE when declaring the record.

table_name%ROWTYPE;

where table_name is the name of the table. %ROWTYPE is a keyword that tells Oracle that the record should have one field for each column in the table, and that the datatypes of the fields should exactly match the datatypes of the columns.

The following example declares the variable dept so that it matches the definition of the Department table:

DECLARE
dept department%ROWTYPE;
…

The beauty of this is that a change to the table definition automatically ripples through to your PL/SQL code. You don’t need to manually hunt down and change record definitions.

Adding a column to a table would be transparent to your PL/SQL code, as
would certain types of datatype changes. However, if you drop a table column
that your code is using, you need to visit that code and make some
changes.

As with any other record, you use dot notation to reference a specific field. As far as PL/SQL is concerned, using department%ROWTYPE has the same effect as if you had declared the record like this:

DECLARE
TYPE dept_type IS RECORD
(
dept_id department.dept_id%type,
dept_name department.dept_name%type,
no_of_emps department.no_of_emps%type
);

dept dept_type;

If you’re working with all or most of the fields in a table, use %ROWTYPE to declare your records. You’ll save typing, and you’ll insulate your code somewhat from changes to the table.

By using records, you can group like data into one structure and then manipulate this structure as one entity or logical unit. This helps reduce coding and keeps the code easier to maintain and understand.

Declaring a Record Variable

In order to use a record, you must define the record by declaring a record type. Then,you must declare one or more PL/SQL variables to be of that type.

You declare a record type in the declaration portion of a PL/SQL block, subprogram, or package.

The following example declares a record type named emp_pay_salary:

TYPE emp_pay_salary IS RECORD –record declaration
(emp_id INTEGER(10),
emp_name VARCHAR2(32),
emp_sal NUMBER(9,2),
sal_type CHAR(1)
);

With the record type defined, you can then declare variables of that type, as in the following

example:
DECLARE
…
emp emp_pay_info;
…
BEGIN
…
After you have a record variable declared, you can use dot notation to reference the individual fields within the record. In the following example, the pay_type field in the emp record is referenced in an IF statement:

IF emp.sal_type = ‘S’ THEN…

Having related fields grouped together in a record allows you to more easily keep things together when you are passing those values as parameters to other program units.

This example shows the declaration for a procedure that takes a record of type emp_pay_info as a parameter:

procedure calculate_check (emp IN emp_pay_info) IS
…
Passing related values as a record not only makes your code more readable, but it makes it more maintainable as well. If you need to add another field to the emp_pay_info record, you only need to change the record definition, and that new value will be passed around everywhere that the record goes. If you were dealing with separate variables, you would have to change the header for every procedure and function that used the record.

Using the %TYPE Attribute in Records

If you’re declaring a record, and you want some of the field definitions to match definitions of columns in a database table, you can use the %TYPE attribute.To declare a variable to match a column definition, place an entry such as this in the declaration section of the PL/SQL block:

variable_name table_name.column_name%TYPE;

The %TYPE following the table and column name tells Oracle that you want the variable being declared to inherit its datatype and length from the definition of the named column.

The following example shows another way to define the emp_pay_info record
shown in the previous section:

TYPE emp_pay_salary IS RECORD
(emp_id employee.emp_id%TYPE,
emp_name employee.emp_name%TYPE,
sal_rate employee.pay_rate%TYPE,
sal_type employee.pay_type%TYPE
);

Using %TYPE like this helps insulate your PL/SQL code from changes in the underlying database columns. In the next section you’ll learn an even easier technique, using %ROWTYPE, that you can use when you want the record to contain fields for all columns in a table.

Syntax:

DROP TRIGGER trigger_name;

Example:

CREATE OR REPLACE TRIGGER EMP_MONDAY

BEFORE INSERT OR UPDATE OR DELETE ON EMP

BEGIN

IF RTRIM(UPPER(TO_CHAR(SYSDATE,'DAY')))='MONDAY' THEN

RAISE_APPLICATION_ERROR
(-20022,'NO OPERARTION CAN BE PERFORMED ON MONDAY');

END IF;

END;

Dropping Trigger

DROP TRIGGER REC_CHECK;

We can disable / enable the trigger by the following syntax:

ALTER TRIGGER <trigger name> DISABLE / ENABLE

Example

CREATE OR REPLACE TRIGGER UPDATE_CHECK BEFORE UPDATE ON EMP
FOR EACH ROW

BEGIN

IF :NEW.SAL<:OLD.SAL THEN

RAISE_APPLICATION_ERROR(-20000,'NEW SALARY
CANNOT BE LESS THAN OLD SALARY');

END IF;

END;

Enabling Trigger

SQL>ALTER TRIGGER UPDATE_CHECK DISABLE;

Trigger Disabled;


Disabling Trigger

SQL>ALTER TRIGGER UPDATE_CHECK ENABLE;

Trigger Enabled;

Syntax:
RAISE_APPLICATION_ERROR (error_number, message);

Here:
error_number
It is a negative integer in the range-20000 to –20999

Message
It is a character string up to 2048 bytes in length

This procedure terminates procedure execution, rolls back any effects of the procedure, and returns a user-specified error number and message. Following example makes use of the RAISE_APPLICAION_ERROR.

To Create a trigger so that no operation can be performed on emp table
on Monday.

Solution:

CREATE OR REPLACE TRIGGER EMP_MONDAY

BEFORE INSERT OR UPDATE OR DELETE ON EMP

BEGIN

IF RTRIM(UPPER(TO_CHAR(SYSDATE,'DAY')))='MONDAY' THEN

RAISE_APPLICATION_ERROR
(-20022,'NO OPERARTION CAN BE PERFORMED ON MONDAY');

END IF;

END;

• Row Level Triggers
• Statement Level Triggers
  
• Before Triggers
  
• After Triggers

Here is a brief description about above triggers:

Row Level Triggers

Row level triggers execute once for each row in a transaction. The commands of row level triggers are executed on all rows that are affected by the command that enables the trigger. For example, if an UPDATE statement updates multiple rows of a table, a row trigger is fired once for each row affected by the UPDATE statement. If the triggering statement affects no rows, the trigger is not executed at all. Row level triggers are created using the FOR EACH ROW clause in the CREATE TRIGGER command.

Statement Level Triggers

Statement level triggers are triggered only once for each transaction. For example when an UPDATE command update 15 rows, the commands contained in the trigger are executed only once, and not with every processed row. Statement level trigger are the default types of trigger created via the CREATE TRIGGER command.

Before  Trigger

Since triggers are executed by events, they may be set to occur immediately before or after those events. When a trigger is defined, you can specify whether the trigger must occur before or after the triggering event i.e. INSERT, UPDATE, or DELETE commands.

BEFORE trigger execute the trigger action before the triggering statement. These types of triggers are commonly used in the following situation:

• BEFORE triggers are used when the trigger action should determine whether or not the triggering statement should be allowed to complete. By using a BEFORE trigger, you can eliminate unnecessary processing of the triggering statement. For example: To prevent deletion on Sunday, for this we have to use Statement level before trigger on DELETE statement.
• BEFORE triggers are used to derive specific column values before completing a triggering INSERT or UPDATE statement.

After Trigger

AFTER trigger executes the trigger action after the triggering statement is executed. AFTER triggers are used when you want the triggering statement to complete before executing the trigger action.

For example: To perform cascade delete operation, it means that user delete the record fro one table, but the corresponding records in other tables are delete automatically by a trigger which fired after the execution of delete statement issued by the user.

When combining the different types of triggering actions, there are mainly 12 possible valid trigger types available to us. The possible configurations are:

• BEFORE INSERT row
• BEFORE INSERT statement
• AFTER INSERT row
• AFTER INSERT statement
• BEFORE UPDATE row
• BEFORE UPDATE statement
• AFTER UPDATE Row
• AFTER UPDATE statement
• BEFORE DELETE row
• BEFORE DELETE statement
• AFTER DELETE row
• AFTER DELETE statement

Instead of Trigger

These Triggers are Defined on a View rather than a table.You can use INSTEAD OF TRIGGER to tell oracle what to do instead of  performing actions that invoked the  trigger.