De waarde die in die kolom is opgeslagen, is geen geldige datum. De eerste byte van de dump moet de eeuw zijn, die volgens Oracle-ondersteuningsnotitie 69028.1 wordt opgeslagen in de notatie 'excess-100', wat betekent dat het een waarde moet hebben van 100 + de werkelijke eeuw; dus 1900 zou 119 zijn, 2000 zou 120 zijn en 5500 zou 155 zijn. Dus 44 zou -5600 vertegenwoordigen; de datum die je hebt opgeslagen lijkt daadwerkelijk 5544-09-14 BC te vertegenwoordigen . Aangezien Oracle alleen datums ondersteunt met jaren tussen -4713 en +9999, wordt dit niet herkend.
Je kunt dit vrij eenvoudig opnieuw maken; het lastigste is om de ongeldige datum in de database te krijgen:
create table t42(dt date);
Table created.
declare
d date;
begin
dbms_stats.convert_raw_value('2c9c090e010101', d);
insert into t42 (dt) values (d);
end;
/
PL/SQL procedure successfully completed.
select dump(dt), dump(dt, 1016) from t42;
DUMP(DT)
--------------------------------------------------------------------------------
DUMP(DT,1016)
--------------------------------------------------------------------------------
Typ=12 Len=7: 45,56,9,14,1,1,1
Typ=12 Len=7: 2d,38,9,e,1,1,1
Dit heeft dus een enkele rij met dezelfde gegevens als jij. alter session gebruiken Ik kan zien wat een geldige datum lijkt:
alter session set nls_date_format = 'DD-Mon-YYYY';
select dt from t42;
DT
-----------
14-Sep-5544
alter session set nls_date_format = 'YYYYMMDDHH24MISS';
select dt from t42;
DT
--------------
55440914000000
Maar als ik een expliciet datummasker gebruik, krijgt het gewoon nullen:
select to_char(dt, 'DD-Mon-YYYY'), to_char(dt, 'YYYYMMDDHH24MISS') from t42;
TO_CHAR(DT,'DD-MON-Y TO_CHAR(DT,'YY
-------------------- --------------
00-000-0000 00000000000000
En als ik jouw procedure uitvoer:
exec dump_table_to_csv('T42');
De resulterende CSV heeft:
"DT"
"0000-00-00T00:00:00"
Ik denk dat het verschil is dat degenen die proberen de datum weer te geven, vasthouden aan het interne datumgegevenstype 12, terwijl degenen die nullen tonen het externe gegevenstype 13 gebruiken, zoals vermeld in opmerking 69028.1.
Kortom, uw procedure doet niets verkeerd, de datum waarop deze probeert te exporteren is intern ongeldig. Tenzij je weet welke datum het had moeten zijn, wat onwaarschijnlijk lijkt gezien je startpunt, denk ik niet dat je er veel aan kunt doen, behalve gissen of negeren. Tenzij u misschien weet hoe de gegevens zijn ingevoegd en kunt achterhalen hoe deze zijn beschadigd.
Ik denk dat het waarschijnlijker is dat het van een OCI-programma komt dan wat ik hier deed; deze 'rauwe' truc kwam hier oorspronkelijk vandaan. U kunt ook notitie 331831.1 bekijken. En deze vorige vraag is enigszins gerelateerd.