U voert in beide versies meerdere impliciete datumconversies uit. Dit:
SELECT to_date(to_char(to_date('01-FEB-1949'))) FROM DUAL;
is gelijk aan:
SELECT to_date(to_char(to_date('01-FEB-1949', <NLS_DATE_FORMAT>),
<NLS_DATE_FORMAT>, <NLS_DATE_FORMAT>)) FROM DUAL;
terwijl de tweede zoekopdracht een van die heeft vervangen door een specifiek formaat. Het ziet eruit als uw standaardindeling - die u, geloof ik, kunt instellen in de Toad-voorkeuren zonder het register rechtstreeks te wijzigen; het is niet duidelijk of je zelfs iets aan het wijzigen bent dat gerelateerd is aan Toad - is DD-MON-RR
, zoals getoond door dat in te pluggen in deze queries:
SELECT to_date(to_char(to_date('01-FEB-1949','DD-MON-RR'),
'DD-MON-RR'),'DD-MON-RR') AS date1,
to_date(to_char(to_date('01-FEB-1949','DD-MON-RR'),
'dd-MON-yyyy'),'DD-MON-RR') AS date2 FROM DUAL;
DATE1 DATE2
February, 01 2049 00:00:00+0000 February, 01 1949 00:00:00+0000
(SQL Fiddle )
U kunt zien in deze SQL Fiddle
dat in de eerste versie de datum verschijnt als een string met het jaar als 49
in plaats van 1949
, en dat wordt dan geïnterpreteerd - door de RR
masker - als 2049
, wat het verwachte gedrag is.
Korte versie:vertrouw nooit op impliciete datumconversies of het NLS-datumformaatmasker.