Невозможно отфильтровать нулевые значения даты и времени

Question

У меня есть проблема, которая сводит меня с ума.Я должен запросить представление оракула, которое возвращает некоторые значения DATETIME.Невероятная проблема заключается в том, что даже если я задаю «IS NOT NULL» в предложении WHERE и даже если я устанавливаю NVL (FECHA_HASTA, FECHA_DESDE), я все равно получаю нулевые значения !!Как это возможно ???

Это запрос:

SELECT CUIL as Cuil, 
    COD_TIPO_CAUSAL as CodTipoCausal, 
    COD_CONVENIO as CodConvenio, 
    FECHA_DESDE as FechaDesde, 
    NVL(FECHA_HASTA, FECHA_DESDE) as FechaHasta
FROM ORGANISMO.VCAUSAL_AUSENCIA
WHERE FECHA_HASTA IS NOT NULL
AND FECHA_HASTA > (SELECT SYSDATE - 180 FROM SYS.DUAL)
AND CUIL IN (SELECT CUIL FROM ORGANISMO.VEMPLEADO WHERE FECHA_EGRESO IS NULL OR FECHA_EGRESO > (SELECT SYSDATE FROM SYS.DUAL))

РЕДАКТИРОВАТЬ:

Вот дамп (fecha_hasta, 1016) добавлено:

Answer 1

Сброшенные значения показывают, что данные повреждены.Внутренний формат даты хорошо известен :

byte 1 - century (excess 100)  
byte 2 - year (excess 100)  
byte 3 - month  
byte 4 - day  
byte 5 - hour (excess 1)  
byte 6 - minute (excess 1)  
byte 7 - seconds (excess 1)  

, поэтому четвертый байт в двух значениях, которые SQL Developer сообщает как нулевые (даже если они явно не равны нулю), долженне быть нулем, так как нет нулевого дня.

Исходя из этих правил, 79,9d,2,0,18,3c,3c в шестнадцатеричном формате, то есть 121,157,2,0,24,60,60 в десятичном виде, должно преобразовываться в:

century: 121 - 100 = 21
year: 157 - 100 - 57
month: 2
day: 0
hour: 24 - 1 = 23
minute: 60 - 1 = 59
second: 60 - 1 = 59

или2157-02-00 23:59:59.Аналогично 78,b8,1,0,18,3c,3c преобразуется в 2084-01-00 23: 59: 59.

Версия 18.3 SQL Developer отображает эти значения как в окнах вывода сценария, так и в результатах запроса, как и в предыдущий день:

DT                  DUMPED                             
------------------- -----------------------------------
01-07-2020 23:59:59 Typ=12 Len=7: 78,78,7,1,18,3c,3c   
31-01-2157 23:59:59 Typ=12 Len=7: 79,9d,2,0,18,3c,3c   
31-12-2083 23:59:59 Typ=12 Len=7: 78,b8,1,0,18,3c,3c   
01-07-2018 00:00:00 Typ=12 Len=7: 78,76,7,1,1,1,1      

, тогда как db <> fiddle показывает значения нулевого дня.

Итак, поскольку они на самом деле не равны NULL, разумно, что is not null и nvl() didnне влияет на них, и затем дело клиента в том, как их представить.

Реальная проблема заключается в том, что вы, похоже, имеете поврежденные данные в таблицах, лежащих в основе запрашиваемого представления, поэтомуэто необходимо исследовать и исправить - при условии, что недопустимые значения можно безопасно идентифицировать, и вы можете выяснить, какими они должны были быть в первую очередь, что может быть проблемой.Просто отфильтровать их как часть представления или в вашем запросе будет непросто - если только вы не сможете отфильтровать даты в будущем.И если допустить, что коррупция очевидна, то есть сдвигать даты в будущее;на каком-то уровне вы должны подвергнуть сомнению действительность всех этих дат ... может быть гораздо более тонкие искажения, которые выглядят хорошо.

И затем любой процесс или инструмент, вызвавший повреждение, должен быть обнаружен и исправлентак что это больше не повторится.Конечно, многие вещи могут привести к повреждению, но я считаю, что imp имел обыкновение иметь ошибку, которая могла повредить даты и числа, и программы OCI тоже могут.