Oracle external table date field - works in one DB and not in another

Question

Here's a crazy one: the same external table definition works fine in one database, but fails in another. Not schema - database. Two databases, both on the same OS, different servers. In addition, it's failing on the 2nd date field, though both are defined the same. The NLS settings are the same on both servers, thought I thought the date mask should override that anyway. Here's the definition:

-- access parameters
-- http://docs.oracle.com/cd/E11882_01/server.112/e16536/et_params.htm

CREATE TABLE ext_tab (
  FIELD1                  VARCHAR2(30),
  FIELD2_DATE             DATE,
  FIELD3                  VARCHAR2(4),
  FIELD4                  VARCHAR2(6),
  FIELD5_DATE             DATE
)
ORGANIZATION EXTERNAL
  ( TYPE ORACLE_LOADER
    DEFAULT DIRECTORY DIR_DATADIR
    ACCESS PARAMETERS
      ( RECORDS DELIMITED BY NEWLINE
        NOBADFILE
        NODISCARDFILE
        LOGFILE 'LOGFILE_LOG'
        FIELDS
          TERMINATED BY ','
          OPTIONALLY ENCLOSED BY '"' and '"'
          LRTRIM
          MISSING FIELD VALUES ARE NULL
          REJECT ROWS WITH ALL NULL FIELDS
          (
  FIELD1                  CHAR(30),
  FIELD2_DATE             CHAR(8)   date_format DATE mask  'YYYYMMDD',
  FIELD3                  CHAR(4),
  FIELD4                  CHAR(6),
  FIELD5_DATE             CHAR(8)   date_format DATE mask  'YYYYMMDD'
          )
      )
    LOCATION ('Sample_Input_csv.csv')
  )
REJECT LIMIT UNLIMITED
NOPARALLEL;

Here's sample data:

TOTEA01217611,20121122,TOTE,847759,20121122

And, the log error:

KUP-04021: field formatting error for field FIELD5_DATE

KUP-04026: field too long for datatype

Anyone have an answer for this madness?

Answer 1

Apparently, the input file was corrupt in some way, perhaps loaded as binary instead of ASCII.

What we did: - pulled another file from the first server to the second server and tested - this one worked fine! - deleted the contents of this second file, and cut and pasted the exact text from the first file directly into this second file - ran the test again - it worked!

Everything, as far as we could tell, was identical between the two files. To rule out something to do with the filename, we then renamed this file to the original file's name, but it still worked. We then re-FTP'd the original file, and it worked this time as well. So, again, the only thing we can think of is that some non-printing characters were in the file.

We didn't have a hex editor available to check, but for anyone coming across this same thing, viewing the contents as hex would be one way to make sure there was nothing odd in the file.