Как определить неверные (поврежденные) значения, хранящиеся в столбцах Oracle DATE

Question

Oracle 10.2.0.5

Какой самый простой способ идентифицировать строки в таблице, которые имеют «недопустимые» значения в столбцах DATE. Под «недействительным» здесь я подразумеваю двоичное представление, которое нарушает правила Oracle для значений даты.

Недавно у меня возникла проблема с недопустимой датой в столбце.

Мне удалось использовать предикат запроса для поиска конкретной проблемной строки:

  WHERE TO_CHAR(date_expr,'YYYYMMDDHH24MISS') = '00000000000000'

В моем случае байт века был недействительным ...

 select dump(h.bid_close_date) from mytable h where h.id = 54321

 Typ=12 Len=7: 220,111,11,2,1,1,1

Байт века должен быть 100 + двузначный век. В этом случае было добавлено еще 100, как будто значение столетия было «120», что делает год «12011». (Единственный известный мне способ получения недопустимых значений DATE в базе данных - это использование OCI с использованием собственного 7-байтового представления DATE.)

В этом случае функция TO_CHAR вернула идентифицируемую строку, которую я мог бы использовать для определения значения DATE вонки.

Мой вопрос: существует ли более общий или более простой подход (предпочтительно с использованием оператора SQL SELECT) для идентификации строк с «недопустимыми» значениями в столбцах DATE.

Answer 1

Это довольно необычный сценарий (хотя я однажды сталкивался с чем-то похожим). Более распространенной проблемой является поиск недопустимых дат, которые хранятся в виде строк в столбце даты. Вы можете адаптировать решение для этой ситуации, создав собственный валидатор даты.

Примерно так:

create or replace function is_a_date 
    ( p_date in date )
    return varchar2
is
    d date;
begin
    d := to_date(to_char(p_date,  'SYYYYMMDDHH24MISS'),  'SYYYYMMDDHH24MISS') ;
    if d != p_date then
        return 'not a proper date';
    else
        return 'good date';
    end if;
exception
    when others  then
        return 'not a date';
end;
/ 

Это преобразует дату в строку и обратно. Ловит исключения, сгенерированные датой кастинга. Если конечный продукт не совпадает с датой ввода, то, вероятно, что-то потеряно в переводе; Честно говоря, я не уверен, что дата 12011 будет успешно приведена к строке, так что это подход с поясом и скобками. Сложно написать эту утилиту без тестовых данных!

В этом запросе будут указаны все недействительные даты:

 select h.id, dump(h.bid_close_date)
 from mytable h 
 where h.bid_close_date is not null
 and is_a_date(h.bid_close_date) != 'good date';

Answer 2

Без добавления функции простой предикат

TO_CHAR(date_col,'YYYYMMDDHH24MISS') = '000000000000'

представляется достаточным для определения поврежденных значений, хранящихся в столбце Oracle DATE.Добавление функции кажется ненужным.Проверка поврежденных дат должна выполняться в инструкции SQL SELECT и не требовать, чтобы пользователь имел привилегию CREATE FUNCTION для базы данных.

Answer 3

Это идентифицирует недопустимые месяцы

SELECT rowid,
       pk_column,
       DUMP(date_column, 1010) AS dump1
FROM   table
WHERE  TO_NUMBER(SUBSTR(DUMP(date_column, 1010), INSTR(DUMP( date_column, 1010),
                                              ',', 1, 2
                                                     ) + 1,
                                  INSTR(DUMP(date_column, 1010), ',', 1, 3) - (
                                  INSTR(DUMP( date_column, 1010), ',', 1, 2) + 1
                                  ))) = 0; 

Обновление с использованием того же предложения where, я обнаружил, что номер месяца был нулевым в этих случаях.

Answer 4

Я бы выбрал метод, который может быть реализован как проверочное ограничение, возможно, путем проверки того, что дата находится в диапазоне допустимых значений.

Тем не менее, спросите себя также, является ли действительным иметь дату 1066-10-14? Это допустимое значение, но, возможно, у вас, например, нет счетов, напечатанных в этот день. Поэтому вам может понадобиться свернуть проверку недействительных дат в более крупную проблему того, что вы действительно считаете действительным в контексте вашей заявки.