无效月份-SQL ORA-01843-UNIX

Question

I'm using a

TO_CHAR(TO_DATE(tdj_tran_dt,'DD-MON-RRRR'),'DD-MON-RRRR')    

in my one of my views.

The underlying Data is in the form DD-MON-YY and I have to display it in the form DD-MON-YYYY in the screen.

Initially I was using to_char(tdj_Tran_dt,'DD-MON-YYYY') alone but it wasnt working out. For example, 20-OCT-17 would become 20-OCT-0017. My system has migrated data so changing the form of the data while inserting into table will not help. So for this I've used TO_CHAR(TO_DATE(tdj_tran_dt,'DD-MON-RRRR'),'DD-MON-RRRR') which seems to be working everywhere except in unix. I have a proc file (run through linux) which calls this view and writes the data in xls format. but in the proc while opening the cursor it gives Oracle error ORA-01843. Changing it back to to_char(tdj_Tran_dt,'DD-MON-YYYY') seems to work but brings back the original problem.

I just want to know is there some setting in the database that I can change to fix this issue. I have the samething running in two different environments and the not a valid month error seems to be only occuring in one environment. I have checked nls_parameters which seems to be the same in both environments.

NLS_LANGUAGE    AMERICAN
NLS_TERRITORY   AMERICA
NLS_CURRENCY    $
NLS_ISO_CURRENCY    AMERICA
NLS_NUMERIC_CHARACTERS  .,
NLS_CALENDAR    GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE   AMERICAN
NLS_CHARACTERSET    AL32UTF8
NLS_SORT    BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT    DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT  HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY   $
NLS_NCHAR_CHARACTERSET  AL16UTF16
NLS_COMP    BINARY
NLS_LENGTH_SEMANTICS    BYTE
NLS_NCHAR_CONV_EXCP FALSE

I've checked in a lot of places but no solution. If anybody has any idea how this could be solved, please help.

Answer 1

I'm going to make a wild guess that tdj_tran_dt is actually a DATE column, since you mentioned that you were using to_char(tdj_tran_dt,'DD-MON-YYYY') , which would have failed if it was a string. (It could also explain why to_date(tdj_tran_dt,'DD-MON-RRRR') failed in another environment, if the nls_date_format there was not compatible with 'DD-MON-RRRR' .) Therefore the issue is that some of the dates were incorrectly entered as year 0017 etc, ie 1st century AD.

If this is the case, then you probably want to clean up dates that are wildly out by discarding the century and substituting a nearer one, while retaining dates that are closer to today.

with demo (tdj_tran_dt) as
     ( select date '0017-01-30' from dual union all
       select date '1917-01-30' from dual union all
       select date '1960-01-30' from dual union all
       select date '2017-01-30' from dual )
select tdj_tran_dt
     , to_date(to_char(tdj_tran_dt,'DD-MON-YY'),'DD-MON-RR') as fixed_tran_dt
from   demo
order by tdj_tran_dt;

TDJ_TRAN_DT  FIXED_TRAN_DT
------------ -------------
30-JAN-0017  30-JAN-2017
30-JAN-1917  30-JAN-2017
30-JAN-1960  30-JAN-1960
30-JAN-2017  30-JAN-2017