1.
To_Date(To_Char(MaxDate, 'DD/MM/YYYY')) = REP_DATE
está causando el problema. cuando usa to_date sin el formato de hora, Oracle usará el formato NLS de las sesiones actuales para convertir, que en su caso podría no ser "DD/MM/YYYY". Mira esto...
SQL> select sysdate from dual;
SYSDATE
---------
26-SEP-12
Which means my session's setting is DD-Mon-YY
SQL> select to_char(sysdate,'MM/DD/YYYY') from dual;
TO_CHAR(SY
----------
09/26/2012
SQL> select to_date(to_char(sysdate,'MM/DD/YYYY')) from dual;
select to_date(to_char(sysdate,'MM/DD/YYYY')) from dual
*
ERROR at line 1:
ORA-01843: not a valid month
SQL> select to_date(to_char(sysdate,'MM/DD/YYYY'),'MM/DD/YYYY') from dual;
TO_DATE(T
---------
26-SEP-12
2.
Más importante aún, ¿por qué está convirtiendo a char y luego a la fecha, en lugar de comparar directamente
MaxDate = REP_DATE
Si desea ignorar el componente de tiempo en MaxDate antes de la comparación, debe usar ..
trunc(MaxDate ) = rep_date
en su lugar.
==Actualizar:basado en una pregunta actualizada.
Rep_Date = 01/04/2009 Rep_Time = 01/01/1753 13:00:00
Creo que el problema es más complejo. si rep_time está destinado a ser solo tiempo, entonces no puede almacenarlo en la base de datos como una fecha. Tendría que ser una cadena o fecha a intervalo de tiempo o numéricamente como segundos (gracias a Alex, consulte esto ) . Si es posible, sugeriría usar una columna rep_date que tenga tanto la fecha como la hora y compararla directamente con la columna de fecha máxima.
Si es un sistema en ejecución y no tiene control sobre la actualización, puede probar esto.
trunc(rep_date) = trunc(maxdate) and
to_char(rep_date,'HH24:MI:SS') = to_char(maxdate,'HH24:MI:SS')
De cualquier manera, la hora se está almacenando incorrectamente (como puede ver desde el año 1753) y podría haber otros problemas en el futuro.
