How to ''give'' error for this case of an EXTERNAL TABLE?

Question

Our external table routine works fine:
-- We have a csv file with 2 cols.
-- When we create the table referring the csv it works fine.
-- Even if the csv has more the 2 cols, the ET command only takes the 2 cols and it works fine.
-- Now, users are saying that if the csv has more than 2 cols, the ET command should give an error
I went through the command but cannot find any clause which will do this.
Is there any other way or workaround?
CREATE TABLE <table_name> (
<column_definitions>)
ORGANIZATION EXTERNAL
(TYPE oracle_loader
DEFAULT DIRECTORY <oracle_directory_object_name>
ACCESS PARAMETERS (
RECORDS DELIMITED BY newline
BADFILE <file_name>
DISCARDFILE <file_name>
LOGFILE <file_name>
[READSIZE <bytes>]
[SKIP <number_of_rows>
FIELDS TERMINATED BY '<terminator>'
REJECT ROWS WITH ALL NULL FIELDS
MISSING FIELD VALUES ARE NULL
(<column_name_list>))\
LOCATION ('<file_name>'))
[PARALLEL]
REJECT LIMIT <UNLIMITED | integer>;
Is it possible to use the READSIZE?
Edited by: Channa on Sep 23, 2010 2:28 AM

Answer 1

-- Now, users are saying that if the csv has more than 2 cols, the ET command should give an error
I went through the command but cannot find any clause which will do this.
Is there any other way or workaround?I looked at Serverprocess' sql*loader script and did not see how that would answer your question - how to raise an error if the file has more than 2 columns. If I missed something can Serverprocess explain?
I can't think of a direct way to do this with your external table either, but there may be indirect ways. Some brainstorming ideas of perhaps dubious usefulness follow.
Placing a view over the external table can limit results to the first two columns but won't raise an error.
A pipelined function can read the external table, check for data where there shouldn't be any, and raise an exception when you find data in columns where there should not be any.
Similarly, you could ditch the external table and use utl_file to read the file, manually parsing and checking the data. LOTS more work but more control on your end. External tables are much easer to use :(
Or, first load the external table into a work table before the "real" select. Check the work table for the offending data programatically and raise an error if data is where it should not be. You could keep the existing external table and not have to do a lot of recoding.
Or, also load the data into an otherwise unneeded global temporary table first. Use a trigger on the load to look for the unwanted data and raise an error if offending data is there
These ideas are boiling down to variations on validating the data before you use it.
Good luck!