12.4.1 The bfile Datatype

Use the BFILE datatype to access large binary objects (up to four gigabytes in size) in files outside the database. This variable gives you read-only, bytestream I/O access to these files, which can reside on a hard disk, CD-ROM, or other such device.

When you declare a BFILE variable, you allocate memory to store the file locator of the BFILE, not the BFILE contents itself. This file locator contains a directory alias as well as a filename. See the later section Section 12.5.6 for more information about the file locator.

Here is an example of a declaration of a BFILE variable:

DECLARE

web_page BFILE;

12.4.2 The blob Datatype

Use the BLOB datatype to store large binary objects inside the database. Data for all but very small BLOB values is stored "out of line," which means that when a table has a BLOB column, a row of data for that table contains a pointer, or locator, to the actual location of the BLOB data (thus it is not "in line" with the other column values of the row). Extremely small BLOB values may be stored inline.

The BLOB variable's locator then points to a large binary object. BLOBs can be up to four gigabytes in size, and they participate fully in transactions. In other words, any changes you make to a BLOB (via the DBMS_LOB built-in package, for example) can be rolled back or committed along with other outstanding changes in your transaction. BLOB locators cannot, however, span transactions or sessions.

Here is an example of a declaration of a BLOB variable:

DECLARE

photo BLOB;

12.4.3 The clob Datatype

Use the CLOB datatype to store large blocks of single-byte character data inside the database. Variable-width character sets are not supported in CLOBs. As with BLOBs, large CLOBs are stored "out of line."

A CLOB variable contains a locator, which then points to the large block of single-byte character data. CLOBs can be up to four gigabytes in size, and they participate fully in transactions. In other words, any changes you make to a CLOB can be rolled back or committed along with other outstanding changes in your transaction. Like BLOB locators, CLOB locators cannot span transactions or sessions.

Here is an example of a declaration of a CLOB variable:

DECLARE

directions CLOB;

LONG and LONG RAW If you've been around Oracle for a few years, you've probably noticed that so far we've omitted any discussion of two datatypes: LONG and LONG RAW. This is intentional. In the database, LONG and LONG RAW allow you to store large amounts (up to two gigabytes) of character and binary data, respectively. The maximum lengths of the PL/SQL types, however, are much shorter: only 32,760 bytes, which is less than the 32,767 bytes supported by VARCHAR2 and RAW. Given this rather odd length limitation, we recommend using VARCHAR2 and RAW, instead of LONG and LONG RAW, in your PL/SQL programs. If you're retrieving LONG and LONG RAW columns that may contain more than 32,767 bytes of data, you won't be able to store the returned values in VARCHAR2 or RAW variables. This is an unfortunate restriction, and a good reason to avoid LONG and LONG RAW to begin with. LONG and LONG RAW are obsolete types, maintained only for backward compatibility. Oracle doesn't recommend their use, and neither do we. For new applications where you have a choice, use CLOB and BLOB instead. For existing applications, Oracle's Oracle9i Application Developer's Guide—Large Objects (LOBs) provides guidance for migrating existing data from LONG to LOB columns.