12.3.2.2 Using rowids in Oracle Forms

You can make use of the rowid in an Oracle Forms application to access the row in the database corresponding to the record on the screen. When you create a base-table block in Oracle Forms, it automatically includes the rowid in the block as an "invisible pseudoitem." You do not see it on your item list, but you can reference it in your triggers and PL/SQL program units. For example, to update the name of an employee displayed on the screen, you could issue the following statement:

UPDATE employee

SET last_name = :employee.last_name

WHERE rowid = :employee.rowid;

12.3.2.3 Using rowids in a cursor for loop

You can also use the rowid inside a cursor FOR loop (or any other loop that FETCHes records from a cursor) to make changes to the row just FETCHed, as follows:

PROCEDURE remove_internal_competitors IS

BEGIN

FOR emp_rec IN

(SELECT connections, rowid

FROM employee

WHERE sal > 500000)

LOOP

IF emp_rec.connections IN ('President', 'CEO')

THEN

send_holiday_greetings;

ELSE

DELETE FROM employee

WHERE rowid = emp_rec.rowid;

END IF;

END LOOP;

END;

The DELETE uses the rowid stored in the emp_rec record to immediately get rid of anyone making more than $500,000 who does not have known connections to the President or CEO. Note that the DBA controls who may have EXECUTE privilege to this stored procedure. So one must now wonder: does the DBA have connections to the President or CEO? Well, in any case, use of the rowid guarantees the fastest possible DELETE of that employee.

Of course, the above procedure could also simply have fetched the employee_id (the primary key of the employee table) and executed a DELETE based on that real column, as in the following:

DELETE FROM employee WHERE employee_id = emp_id;

12.3.2.4 Is the use of rowids worth the effort?

We aren't convinced that the theoretical performance gains of searching by rowid justify its use. The resulting code is harder to understand than the application-specific use of the primary key. You also must understand how rowids might change. We've heard of people storing rowids in tables, only to have everything break when the DBA does an export/import to reorganize storage. It's best, in our opinion, not to store rowids in database columns.

A further issue with respect to rowids concerns portability. The rowid is not a part of the ANSI SQL standard; instead, it reflects directly the internal storage structure of the Oracle RDBMS. References to rowids could cause portability problems in the future, as non-Oracle databases do not recognize or support rowids. If you are building applications that may need to work against non-Oracle data sources, you should avoid any references to the rowid pseudocolumn and to the UROWID and ROWID datatypes.

12.4 The lob Datatypes

Oracle and PL/SQL support several variations ofLOB (large object) datatypes. LOBs can store large amounts—up to four gigabytes—of binary data (such as images) or character text data.

Within PL/SQL you can declare LOB variables of the following datatypes:

BFILE

Binary file. Declares a variable that holds a file locator pointing to an operating-system file outside the database. Oracle treats the data in the file as binary data.

BLOB

Binary large object. Declares a variable that holds a LOB locator pointing to a large binary object stored inside the database.

CLOB

Character large object. Declares a variable that holds a LOB locator pointing to a large block of single-byte, fixed-width character data stored inside the database.

NCLOB

National Language Support (NLS) character large object. Declares a variable that holds a LOB locator pointing to a large block of single-byte, fixed-width multibyte, or variable-width multibyte character data stored inside the database.

There are two types of LOBs: internal and external. Internal LOBs (BLOBs, CLOBs, and NCLOBs) are stored in the database and can participate in a transaction in the database server. External LOBs (BFILEs) represent binary data stored in operating-system files outside the database tablespaces. External LOBs cannot participate in transactions; in other words, you cannot commit or roll back changes to a BFILE. Instead, you must rely on the underlying filesystem for data integrity.