Topics

 What is SQL*Loader and what is it used for?

 How does one use the SQL*Loader utility?
 Is there a SQL*Unloader to download data to a flat file?
 Can one load variable and fix length data records?
 Can one skip header records load while loading?
 Can one modify data as it loads into the database?
 Can one load data into multiple tables at once?
 Can one selectively load only the records that one need?
 Can one skip certain columns while loading data?
 How does one load multi-line records?
 How can one get SQL*Loader to COMMIT only at the end of the load file?
 Can one improve the performance of SQL*Loader?
 What is the difference between the conventional and direct path loader?
 How does one use SQL*Loader to load images, sound clips and documents?
 Where can one get more info about SQL*Loader?

What is SQL*Loader and what is it used for?

SQL*Loader is a bulk loader utility used for moving data from external files into the Oracle
database. Its syntax is similar to that of the DB2 Load utility, but comes with more options.
SQL*Loader supports various load formats, selective loading, and multi-table loads

How does one use the SQL*Loader utility?

One can load data into an Oracle database by using the sqlldr (sqlload on some platforms)
utility. Invoke the utility without arguments to get a list of available parameters. Look at the
following example:

 sqlldr scott/tiger control=loader.ctl

This sample control file (loader.ctl) will load an external data file containing delimited data:
load data

infile 'c:\data\mydata.csv'

into table emp

fields terminated by "," optionally enclosed by '"'

( empno, empname, sal, deptno )

The mydata.csv file may look like this:

10001,"Scott Tiger", 1000, 40

10002,"Frank Naude", 500, 20

Another Sample control file with in-line data formatted as fix length records. The trick is to
specify "*" as the name of the data file, and use BEGINDATA to start the data section in the
control file.
 load data

infile *

replace

into table departments

( dept position (02:05) char(4),

deptname position (08:27) char(20)

begindata

COSC COMPUTER SCIENCE

ENGL ENGLISH LITERATURE

MATH MATHEMATICS

POLY POLITICAL SCIENCE

 Back to top of file

Is there a SQL*Unloader to download data to a flat file?

Oracle does not supply any data unload utilities. However, you can use SQL*Plus to select and
format your data and then spool it to a file:
set echo off newpage 0 space 0 pagesize 0 feed off head off trimspool
on

spool oradata.txt

select col1 || ',' || col2 || ',' || col3

from tab1

where col2 = 'XYZ';

spool off

Alternatively use the UTL_FILE PL/SQL package:

rem Remember to update initSID.ora, utl_file_dir='c:\oradata'
parameter

declare

fp utl_file.file_type;

begin

fp := utl_file.fopen('c:\oradata','tab1.txt','w');

utl_file.putf(fp, '%s, %s\n', 'TextField', 55);

utl_file.fclose(fp);

end;

/
You might also want to investigate third party tools like SQLWays from Ispirer Systems, TOAD
from Quest, or ManageIT Fast Unloader from CA to help you unload data from Oracle.

Can one load variable and fix length data records?

Yes, look at the following control file examples. In the first we will load delimited data
(variable length):
LOAD DATA

INFILE *

INTO TABLE load_delimited_data

FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"'

TRAILING NULLCOLS

( data1,

data2
)

BEGINDATA

11111,AAAAAAAAAA

22222,"A,B,C,D,"

If you need to load positional data (fixed length), look at the following control file example:
LOAD DATA

INFILE *

INTO TABLE load_positional_data

( data1 POSITION(1:5),

data2 POSITION(6:15)

BEGINDATA

11111AAAAAAAAAA

22222BBBBBBBBBB

 Can one skip header records load while loading?

Use the "SKIP n" keyword, where n = number of logical rows to skip. Look at this example:
LOAD DATA

INFILE *

INTO TABLE load_positional_data

SKIP 5

( data1 POSITION(1:5),

data2 POSITION(6:15)

)
 BEGINDATA

11111AAAAAAAAAA

22222BBBBBBBBBB

 Back to top of file

Can one modify data as it loads into the database?

Data can be modified as it loads into the Oracle Database. Note that this only applies for the
conventional load path and not for direct path loads.
LOAD DATA

INFILE *

INTO TABLE modified_data

( rec_no "my_db_sequence.nextval",

region CONSTANT '31',

time_loaded "to_char(SYSDATE, 'HH24:MI')",

data1 POSITION(1:5) ":data1/100",

data2 POSITION(6:15) "upper(:data2)",

data3 POSITION(16:22)"to_date(:data3, 'YYMMDD')"

BEGINDATA

11111AAAAAAAAAA991201

22222BBBBBBBBBB990112

LOAD DATA

INFILE 'mail_orders.txt'

BADFILE 'bad_orders.txt'

APPEND

INTO TABLE mailing_list

FIELDS TERMINATED BY ","

( addr,

city,

state,

zipcode,

mailing_addr "decode(:mailing_addr, null, :addr, :mailing_addr)",

mailing_city "decode(:mailing_city, null, :city, :mailing_city)",

mailing_state

)
Can one load data into multiple tables at once?
Look at the following control file:
LOAD DATA

INFILE *

REPLACE

INTO TABLE emp

WHEN empno != ' '

( empno POSITION(1:4) INTEGER EXTERNAL,

ename POSITION(6:15) CHAR,

deptno POSITION(17:18) CHAR,

mgr POSITION(20:23) INTEGER EXTERNAL

INTO TABLE proj

WHEN projno != ' '

( projno POSITION(25:27) INTEGER EXTERNAL,

empno POSITION(1:4) INTEGER EXTERNAL

Can one selectively load only the records that one need?
Look at this example, (01) is the first character, (30:37) are characters 30 to 37:
LOAD DATA

INFILE 'mydata.dat' BADFILE 'mydata.bad' DISCARDFILE 'mydata.dis'

APPEND

INTO TABLE my_selective_table

WHEN (01) <> 'H' and (01) <> 'T' and (30:37) = '19991217'

region CONSTANT '31',

service_key POSITION(01:11) INTEGER EXTERNAL,

call_b_no POSITION(12:29) CHAR

Can one skip certain columns while loading data?

One cannot use POSTION(x:y) with delimited data. Luckily, from Oracle 8i one can specify
FILLER columns. FILLER columns are used to skip columns/fields in the load file, ignoring fields
that one does not want. Look at this example:
LOAD DATA
 TRUNCATE INTO TABLE T1

FIELDS TERMINATED BY ','

( field1,

field2 FILLER,

field3

How does one load multi-line records?

One can create one logical record from multiple physical records using one of the following two
clauses:

• CONCATENATE: - use when SQL*Loader should combine the same number of physical
records together to form one logical record.
• CONTINUEIF - use if a condition indicates that multiple records should be treated as
one. Eg. by having a '#' character in column 1.

How can get SQL*Loader to COMMIT only at the end of the load file?
One cannot, but by setting the ROWS= parameter to a large value, committing can be reduced.
Make sure you have big rollback segments ready when you use a high value for ROWS=.

Can one improve the performance of SQL*Loader?

1. A very simple but easily overlooked hint is not to have any indexes and/or constraints
(primary key) on your load tables during the load process. This will significantly slow
down load times even with ROWS= set to a high value.
2. Add the following option in the command line: DIRECT=TRUE. This will effectively
bypass most of the RDBMS processing. However, there are cases when you can't use
direct load. Refer to chapter 8 on Oracle server Utilities manual.
3. Turn off database logging by specifying the UNRECOVERABLE option. This option can
only be used with direct data loads.
4. Run multiple load jobs concurrently.

How does one use SQL*Loader to load images, sound clips and
documents?
SQL*Loader can load data from a "primary data file", SDF (Secondary Data file - for loading
nested tables and VARRAYs) or LOGFILE. The LOBFILE method provides and easy way to load
documents, images and audio clips into BLOB and CLOB columns. Look at this example:

Given the following table:

CREATE TABLE image_table (

image_id NUMBER(5),

file_name VARCHAR2(30),

image_data BLOB);
Control File:
LOAD DATA

INFILE *

INTO TABLE image_table

REPLACE

FIELDS TERMINATED BY ','

image_id INTEGER(5),

file_name CHAR(30),

image_data LOBFILE (file_name) TERMINATED BY EOF

BEGINDATA

001,image1.gif

002,image2.jpg

What is the difference between the conventional and direct path

loader?
The conventional path loader essentially loads the data by using standard INSERT statements.
The direct path loader (DIRECT=TRUE) bypasses much of the logic involved with that, and loads
directly into the Oracle data files. More information about the restrictions of direct path
loading can be obtained from the Utilities Users Guide.

Where can one get more info about SQL*Loader?

• Using the Oracle Bulk Loader

• Solutions to common SQL*Loader questions

1. How do you load an implied decimal place into the database?

Example:
=======

Let us take an example of a bank account, the data contains a

transaction
type, an account number, and a dollar amount. The last column is a
numeric value with an implied decimal place (100.73, 75.25, and 20.00):

DEPOSIT 10015 10073

DEPOSIT 10020 7525
WITHDRAWAL 10015 2000

We want to load the data into the following table:

 SQL> CREATE TABLE register
2 (tx_type CHAR(15),
3 acct NUMBER,
4 amt NUMBER);

The control file would look like:

LOAD DATA
INFILE 'month.dat'
INTO TABLE register
(tx_type POSITION(1:10),
acct POSITION(13:17),
amt POSITION(20:24) ":amt/100"
)

After we run SQL*Loader, our table data looks like:

SQL> SELECT * FROM register;

TX_TYPE ACCT AMT

--------------- ---------- ----------
DEPOSIT 10015 100.73
DEPOSIT 10020 75.25
WITHDRAWAL 10015 20

How this works:

==============

SQL*Loader simply builds an insert statement which looks like:

INSERT INTO register (tx_type,acct,amt)

VALUES (:data1, :data2, ":amt/100");

So, for every AMT loaded, we divide it by 100.

See chapter 6 of the Utilities Guide "Applying SQL Operators to Fields".

Restrictions:
============

This method cannot be used with DIRECT PATH Loader.

=======================================================================
========
LOADING DATABASE SEQUENCES
=======================================================================
========

2. How do you load a database sequence into a table?

Example-I:
=========

In the first example, all of the fields are located in the datafile
based
on position, which makes this easier. Another example below covers
data that

is comma delimited.

We want to load the data into the following table:

SQL> CREATE TABLE load_db_seq_positional

2 (seq_number NUMBER,
3 data1 NUMBER,
4 data2 CHAR(15) );

We will use the following sequence:

SQL> CREATE SEQUENCE db_seq

2 START WITH 1
3 INCREMENT BY 1;

The control file would look like:

LOAD DATA
INFILE *
INTO TABLE load_db_seq_positional
(seq_number "db_seq.nextval"
data1 POSITION(1:5),
data2 POSITION(6:15),
)
BEGINDATA
11111AAAAAAAAAA
22222BBBBBBBBBB

After we run SQL*Loader, our table data looks like:

SQL> SELECT * FROM load_db_seq_positional;

SEQ_NUMBER DATA1 DATA2

---------- ---------- ---------------
1 11111 AAAAAAAAAA
2 22222 BBBBBBBBBB

Example-II:
==========

In this example, the data fields are comma delimited. The key here is
that
since fields are delimited, SQL*Loader will expect to find values for
the
field SEQ_NUMBER in the data file. Since such entries do not exist,
what
we must do is to put the SEQ_NUMBER field as the last field in the
control
file, and then use the TRAILING NULLCOLS clause to indicate to Loader
that
on some lines (in this case all), there may be "trailing columns" which
are
null, or non-existent.
Here is the similar create table statetement, we will use the same
sequence:

SQL> CREATE TABLE load_db_seq_delimited

2 (seq_number NUMBER,
3 data1 NUMBER,
4 data2 CHAR(15));

The control file would look like:

LOAD DATA
INFILE *
INTO TABLE load_db_seq_delimited
FIELDS TERMINATED BY ","
TRAILING NULLCOLS
(data1,
data2,
seq_number "db_seq.nextval"
)
BEGINDATA
11111,AAAAAAAAAA
22222,BBBBBBBBBB

After we run SQL*Loader, our table data looks like:

SQL> SELECT * FROM load_db_seq_delimited;

SEQ_NUMBER DATA1 DATA2

---------- ---------- ---------------
3 11111 AAAAAAAAAA
4 22222 BBBBBBBBBB

How this works:

==============

SQL*Loader simply builds an insert statement which looks like:

INSERT INTO load_db_seq_delimited (data1,data2,seq_number)

VALUES (:data1, :data2, "db_seq.nextval");

See chapter 6 of the Utilities Guide "Applying SQL Operators to Fields".

Restrictions:
============

Both of these methods cannot be used with DIRECT PATH Loader.

=======================================================================
========
LOADING USERNAME OF USER RUNNING SQL*LOADER
=======================================================================
========

3. How do you load the username of the user running the SQL*Loader
session?

Example-I:
=========

In this example, all of the fields are located in the datafile based
on position, which makes this easier. Another example below, which is
slightly more difficult, covers data that is comma delimited. Both
methods
take advantage of the "USER" pseudo-variable. If you prefer to use the
Oracle User ID number, you could use "UID" instead.

We want to load the data into the following table:

SQL> CREATE TABLE load_user_positional

2 (username CHAR(30),
3 data1 NUMBER,
4 data2 CHAR(15) );

The control file would look like:

LOAD DATA
INFILE *
INTO TABLE load_user_positional
(username "USER"
data1 POSITION(1:5),
data2 POSITION(6:15),
)
BEGINDATA
11111AAAAAAAAAA
22222BBBBBBBBBB

If we run SQL*Loader as scott:

$ SQLLDR scott/tiger load_user_d.ctl

Our table data looks like:

SQL> SELECT * FROM load_user_positional;

USERNAME DATA1 DATA2

-------------- ---------- ---------------
SCOTT 11111 AAAAAAAAAA
SCOTT 22222 BBBBBBBBBB

Example-II:
==========

In this example, the data fields are comma delimited. The key here is
that
since fields are delimited, SQL*Loader will expect to find values for
the
field USERNAME in the data file. Since such entries do not exist, then
we
must put the USERNAME field as the last field in the control file, and
then
use the TRAILING NULLCOLS clause to indicate to SQL*Loader that on some
lines

(in this case all), there may be "trailing columns" which are null, or
non-existent.

Here is the similar create statetement:

SQL> CREATE TABLE load_user_delimited

2 (username CHAR(30),
3 data1 NUMBER,
4 data2 CHAR(15) );

The control file would look like:

LOAD DATA
INFILE *
INTO TABLE load_user_delimited
FIELDS TERMINATED BY ","
TRAILING NULLCOLS
(data1,
data2,
username "USER"
)
BEGINDATA
11111,AAAAAAAAAA
22222,BBBBBBBBBB

If we run SQL*Loader as jack:

$ SQLLDR jack/jack load_user_d.ctl

Our table data looks like:

SQL> SELECT * FROM load_user_delimited;

USERNAME DATA1 DATA2

-------------- ---------- ---------------
JACK 11111 AAAAAAAAAA
JACK 22222 BBBBBBBBBB

How this works:

==============

SQL*Loader simply builds an insert statement which looks like:

INSERT INTO load_user_delimited (data1,data2,seq_number)

VALUES (:data1, :data2, "user");

See chapter 6 of the Utilities Guide "Applying SQL Operators to Fields".

Restrictions:
============

Both of these methods cannot be used with DIRECT PATH Loader.

This section will provide a basic understanding of SQL*Loader. Most of the information
contained in this section is DIRECTLY extracted from ``ORACLE7 Server Utilities
Users Guide'' and all credit should be given to ORACLE. If you require more detailed
information than provided in this section, consult the ``ORACLE7 Server Utilities Users
Guide''.

SQL*Loader is a product for moving data from external files into tables in an ORACLE
database. SQL*Loader loads data in a variety of formats, performs filtering (selectively
loading records based upon the data values), and loads multiple tables simultaneously.
During execution SQL*Loader produces a detailed log file with statistics about the load,
and may also produce a bad file (records rejected because of incorrect data) and a discard
file (records that did not meet your selection criteria). You have control over several
loading options.

You must provide two types of input to SQL*Loader to load data from external files into
an ORACLE database: the data itself, and control information describing how to perform
the load.

You must provide a file called the control file as an input to SQL*Loader. The control
file tells SQL*Loader how to interpret the data file. For example, it describes the
following:

• the names of the data files

• the format of the data files

• the character sets used in the data files

• the datatypes of the fields in those files

• how to identify the start and end of data fields

• which tables and columns to load

The control file's datatype specifications tell SQL*Loader how to interpret the fields in
the data files. SQL*Loader uses this information when working with the fields, and uses
it to describe the data that is being passed to ORACLE. ORACLE then converts the data
into the datatype specified by the table definition.

Some information is mandatory (such as where to find the data and how it corresponds to
the database tables). However, many options are also available to describe and
manipulate the file data. For example, the instructions can include directions on how to
format or filter the data, or to generate unique ID numbers.

You may load data in various formats. It is usually read from one or more data files, but
the data may also be placed in the control file after the control file information.
Data records may be in fixed or variable format. In fixed format, the data is contained in
records which all have the same (fixed) format. That is, the records have a fixed length,
and the data fields in those records have fixed length, type, and position.

In variable format (sometimes called stream format), each record is only as long as
necessary to contain the data. With character data, if the first item is shorter than the
second one, the first record is shorter. Also, the type of data in each record may vary. One
record may contain a character string, the next may contain seven integers, the third may
contain three decimals and a float, and so on. Operating systems use a record terminator
character (such as newline) to mark where variable records end.

Delimited data is of two types: terminated or enclosed. Terminated data is followed by a

specified character such as a comma, as in the following example:

1,1,2,3,5,8,13

Enclosed data is preceded and followed by a specified character such as a quotation

mark, as in the following example:

``BUNKY''

A final distinction concerns the difference between logical and physical records. A record
or line in a file (either of fixed length or terminated) is referred to as a physical record.
Logical record, on the other hand, corresponds to a row in a database table. Sometimes
the logical and physical records are equivalent; such is the case when only a few short
columns are being loaded. However, sometimes several physical records must be
combined to make one logical record.

The examples below will illustrate some of the features of the SQL*Loader.

Example 1. Loading Data into Multiple Tables

CONTROL FILE - The control file for this example.

-- Loads EMP records from first 23 characters

-- Creates and loads PROJ records for each PROJNO listed

-- for each employee

LOAD DATA

INFILE 'ulcase5.dat'

BADFILE 'ulcase5.bad'
 DISCARDFILE 'ulcase5.dsc'

a. REPLACE

b. INTO TABLE emp

(empno POSITION(1:4) INTEGER EXTERNAL,

ename POSITION(6:15) CHAR,

deptno POSITION(17:18) CHAR,

mgr POSITION(20:23) INTEGER EXTERNAL)

b. INTO TABLE proj

-- PROJ has two columns, both not null: EMPNO and PROJNO

c. WHEN projno != ' '

(empno POSITION(1:4) INTEGER EXTERNAL,

c. projno POSITION(25:27) INTEGER EXTERNAL) -- 1st proj

b. INTO TABLE proj

WHEN projno != ' '

(empno POSITION(1:4) INTEGER EXTERNAL,

projno POSITION(29:31) INTEGER EXTERNAL) -- 2nd proj

b. INTO TABLE proj

WHEN projno != ' '

(empno POSITION(1:4) INTEGER EXTERNAL,

projno POSITION(33:35) INTEGER EXTERNAL) -- 3rd proj

--------------------------------------------------------------
-

NOTES:

REPLACE indicates that if there is data in the tables to be loaded (EMP and PROJ),
(a)
that data should be deleted before new rows are loaded.

(b) Multiple INTO clauses are used to load two tables, EMP and PROJ. The same set of
records is processed three times using different combinations of columns each time, to
 load table PROJ.

WHEN is used to load only rows with non-blank project numbers. When PROJNO is
(c) defined as columns 25..27, rows are inserted into PROJ only if there is a value in
those columns.

DATA FILE - Part of the data file follows.

1234 BAKER 10 9999 101 102 103

1234 JOKER 10 9999 777 888 999

2664 YOUNG 20 2893 425 abc 102

INVOKING SQL*LOADER - The command line for this example.

SQLLOAD / CONTROL=ULCASE5.CTL LOG=ULCASE5.LOG

Example 2 Loading a Delimited, Free-Format File

CONTROL FILE - The control file for this example.

-- Variable-length, delimited and enclosed data format

LOAD DATA

a. INFILE *

b. APPEND

INTO TABLE emp

c. FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"'

(empno, ename, job, mgr,

d. hiredate DATE "DD-Month-YYYY",

sal, comm, deptno CHAR TERMINATED BY ':',

projno,

e. loadseq SEQUENCE(MAX,1))

f. BEGINDATA
 7782, "CLARK", "Manager", 7839, 09-June-1981, 2572.50, 10:101

7839, "King", "President", , 17-January-1982, 920.00, 10:102

--------------------------------------------------------------
-

NOTES:

(a) INFILE * signifies the data is found at the end of the control file.

APPEND indicates that data may be loaded even if the table already contains rows;
(b)
the table need not be empty.

The default terminator for the data fields is a comma, and some fields may be
(c)
enclosed by a double quote.

The data to be loaded into column HIREDATE appears in the format DD-Month-
(d)
YYYY.

The SEQUENCE function is used to generate a unique value in the column

LOADSEQ. This function finds the current maximum value in column LOADSEQ
(e)
and adds the increment (1) to it to obtain the value for LOADSEQ for each row
inserted.

BEGINDATA signifies the end of the control information and the beginning of the
(f)
data.

INVOKING SQL*LOADER - The command line for this example.

SQLLOAD / CONTROL=ULCASE3.CTL LOG=ULCASE3.LOG

Control File Syntax

The control file usually begins with the phase LOAD DATA, followed by several phrases
that describe the data to be loaded. Only comments or the OPTIONS phrase can precede
the LOAD DATA phase.
For a complete control file syntax diagram see Appendix C in this manual.

Only a subset of the syntax will be explained below. For a complete explanation of the
above syntax, see chapter 6 of ``ORACLE7 Server Utilities Users Guide''.

Comments

Comments may appear anywhere in the command section of the file, but they should not
appear in the data. Comments are preceded with a double dash, which may appear
anywhere on a line. All text to the right of the double dash is ignored, until the end of
line.

The OPTIONS Clause

The OPTIONS clause is useful when you usually invoke a control file with the same set
of options, or when the command line and all its arguments becomes very long. This
clause allows you to specify runtime arguments in the control file rather than on the
command line.

SKIP = n -- Number of logical records to skip (DEFAULT 0)

LOAD = n -- Number of logical records to load (DEFAULT all)
ERRORS = n -- Number of errors to allow (DEFAULT 50)
ROWS = n -- Number of rows in conventional path bind array (DEFAULT 64)
BINDSIZE = n -- Size of conventional path bind array in bytes
SILENT = {HEADER | FEEDBACK | ERROR | DISCARDS | ALL }
-- Suppress messages during run
For example:

OPTIONS (BINDSIZE=10000, SILENT=(ERRORS, FEEDBACK) )

Values specified on the command line override values specified in the control file. With
this precedence, the OPTIONS keyword in the control file established default values that
are easily changed from the command line.

Continuing Interrupted Loads

If SQL*Loader runs out of space for data rows or index entries, the load is discontinued.
(For example, the table might reach its maximum number of extents.) Discontinued loads
can be continued after more space is made available.

When a load is discontinued, any data already loaded remains in the tables, and the tables
are left in a valid state. SQL*Loader's log file tells you the state of the tables and indexes
and the number of logical records already read from the input data file. Use this
information to resume the load where it left off.

For example:

SQLLOAD / CONTROL=FAST1.CTL SKIP=345

CONTINUE\_LOAD DATA statement is used to continue a discontinued direct path

load involving multiple tables with a varying number of records to skip. For more
information on this command, see chapter 6 of ``ORACLE7 Server Utilities Users
Guide''.

Identifying Data Files

To specify the file containing the data to be loaded, use the INFILE or INDDN keyword,
followed by the filename. A filename specified on the command line overrides the first
INFILE or INDDN statement in the control file. If no filename is specified, the filename
defaults to the control filename with an extension or filetype of DAT.

Loading into Non-Empty Database Tables

SQL*Loader does not update existing records, even if they have null columns. If the
tables you are loading already contain data, you have three choices for how SQL*Loader
should proceed:

INSERT - This is the default option. It requires the table to be empty before loading.
SQL*Loader terminates with an error if the table contains rows.
APPEND - If data already exists in the table, SQL*Loader appends the new rows to it; if
data doesn't already exist, the new rows are simply loaded.

REPLACE - All rows in the table are deleted and the new data is loaded. This option
requires DELETE privileges on the table.

You can create one logical record from multiple physical records using
CONCATENATE and CONTINUEIF. See chapter 6 of ``ORACLE7 Server Utilities
Users Guide''.

Loading Logical Records into Tables

The INTO TABLE clause allows you to tell which table you want to load data into. To
load multiple tables, you would include one INTO TABLE clause for each table you wish
to load.

The INTO TABLE clause may continue with some options for loading that table. For
example, you may specify different options (INSERT, APPEND, REPLACE) for each
table in order to tell SQL*Loader what to do if data already exists in the table.

The WHEN clause appears after the table name and is followed by one or more field
conditions. For example, the following clause indicates that any record with the value
``q'' in the fifth column position should be loaded:

WHEN (5) = 'q'

A WHEN clause can contain several comparisons as long as each is preceded by AND.
Parentheses are optional but should be used for clarity with multiple comparisons joined
by AND. For example:

WHEN (DEPTNO = '10') AND (JOB = 'SALES')

To evaluate the WHEN clause, SQL*Loader first determines the values of all the fields in
the record. Then the WHEN clause is evaluated. A row is inserted into the table only if
the WHEN clause is true.

When the control file specifies more fields for a record than are present in the record,
SQL*Loader must determine whether the remaining (specified) columns should be
considered null, or whether an error should be generated. TRAILING NULLCOLS
clause tells SQL*Loader to treat any relatively positioned columns that are not present in
the record as null columns. For example, if the following data

10 Accounting
is read with the following control file

INTO TABLE dept

TRAILING NULLCOLS

( deptno CHAR TERMINATED BY " ",

dname CHAR TERMINATED BY WHITESPACE,

loc CHAR TERMINATED BY WHITESPACE )

and the record ends after DNAME, then the remaining LOC field is set to null. Without
the TRAILING NULLCOLS clause, an error would be generated, due to missing data.

Specifying Datatypes
The datatype specification in the control file tells SQL*Loader how to interpret the
information in the data file. The server defines the datatypes for the columns in the
database. SQL*Loader extracts data from a field in the input file, guided by the datatype
specification in the control file. SQL*Loader then sends the field to the server to be
stored in the appropriate column. The server does any data conversion necessary to store
the data in the proper internal format. The datatype of the data in the file does not
necessarily have to be the same as the datatype of the column in the ORACLE table.
ORACLE automatically performs conversions - but you need to ensure that the
conversion makes sense and does not generate errors. SQL*Loader does not contain
datatype specifications for ORACLE internal datatypes like NUMBER or VARCHAR2.
SQL*Loader's datatypes describe data that can be produced with text editors (character
datatypes) and with standard programming languages (native datatypes).

Native Datatypes

Some datatypes consist entirely of binary data, or contain binary data in their
implementation. These non-character datatypes are the native datatypes:

INTEGER ZONED SMALLINT

VARCHAR FLOAT GRAPHIC
DOUBLE GRAPHIC EXTERNAL BYTEINT
VARGRAPHIC (packed) DECIMAL RAW

These datatypes will not be discussed as most of the datatypes that you will be using will
be character datatypes. For more information on SQL*Loader datatypes, see page 6-52 of
``ORACLE7 SERVER Utilities User's Guide''.
Character Datatypes

The character datatypes are CHAR, DATE, and the numeric EXTERNAL datatypes
(INTEGER and DECIMAL). These fields can be delimited, and can have lengths (or
maximum lengths) specified in the control file.

CHAR - This data field contains character data. The length is optional, and is taken from
the POSITION specification if it is not present here. If present, this length overrides the
length in the POSITION specification. If no length is given, CHAR data is assumed to
have a length of 1. A field of datatype CHAR may also be variable-length delimited or
enclosed.

To Load LONG Data: If the column in the database table is defined as LONG, you must
explicitly specify a maximum length either with a length-specifier on the CHAR
keyword, or with the POSITION keyword. This guarantees that a large enough buffer is
allocated for the value, and is necessary even if the data is delimited or enclosed.

DATE - This data is character data that should be converted to an ORACLE date using
the specified date mask. The length specification is optional, unless a varying-length data
mask is specified. With a specification like:

DATE "Month dd, YYYY"

the date mask is 14 characters, while the length of a field like

September 31, 1991

is 18 characters. In this case, a length must be specified. Similarly, a length is required for
any Julian dates (date mask ``J'') - a field length is required any time the length of the
date string could exceed the length of the mask. An explicit length specification, if
present, overrides the length in the POSITION clause. Either of these overrides the length
derived from the mask. The mask may be any valid ORACLE date mask. If you omit the
mask, the default ORACLE date mask of ``dd-mon-yy'' is used. See Chapter 6 for the
Oracle date masks.
Numeric EXTERNAL - The numeric external datatypes are the numeric datatypes
(INTEGER, FLOAT, DECIMAL, and ZONED) specified with the EXTERNAL keyword
along with optional length and delimiter specifications. These datatypes are the human-
readable, character form of numeric data.

The data is a number in character form (not binary representation). As such, these
datatypes are identical to CHAR and are treated identically, with one exception: the use
of DEFAULTIF. If you want the default to be null, use CHAR; if you want it to be zero,
use EXTERNAL.

>>----INTEGER
---EXTERNAL--------------------------------------

|___FLOAT___| |_ ( length ) _| |_ delimiter_spec

_|

|___DECIMAL_|

|___ZONED___|

delimiter_spec - The boundaries of CHAR, DATE, or numeric EXTERNAL fields may

also be marked by specific delimiter characters contained in the input data record. You
indicate how the field is delimited by using a delimiter specification after specifying the
datatype. Delimited data can be TERMINATED or ENCLOSED.