sql loader

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 transactiontype, 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 basedon 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 thatsince fields are delimited, SQL*Loader will expect to find values for thefield SEQ_NUMBER in the data file. Since such entries do not exist, whatwe 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 thaton some lines (in this case all), there may be "trailing columns" which arenull, 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 basedon position, which makes this easier. Another example below, which isslightly more difficult, covers data that is comma delimited. Both methodstake advantage of the "USER" pseudo-variable. If you prefer to use theOracle 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 thatsince 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 wemust put the USERNAME field as the last field in the control file, and thenuse 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, ornon-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:

(a) REPLACE indicates that if there is data in the tables to be loaded (EMP and PROJ), 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.

(c) WHEN is used to load only rows with non-blank project numbers. When PROJNO is 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.

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

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

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

(e)

The SEQUENCE function is used to generate a unique value in the column LOADSEQ. This function finds the current maximum value in column LOADSEQ and adds the increment (1) to it to obtain the value for LOADSEQ for each row inserted.

(f) BEGINDATA signifies the end of the control information and the beginning of the 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.