Почему я получаю исключение "[SQL0802] Data conversion of data mapping error"?

Я не очень хорошо знаком с iseries/DB2. Однако я работаю на веб-сайте, который использует его в качестве основной базы данных.

Недавно в существующую таблицу был добавлен новый столбец. Когда я просматриваю его через AS400, я вижу следующий тип данных: 

Type: S
Length: 9
Dec: 2
Это говорит мне, что это числовое поле с 6 цифрами перед десятичной точкой и 2 цифрами после десятичной точки.

Когда я запрашиваю данные с помощью простого SELECT (SELECT MYCOL FROM MYTABLE), я без проблем возвращаю все записи. Однако, когда я пытаюсь использование a DISTINCT, GROUP BY, или ORDER BY в этом же столбце я получаю следующее исключение: 

[SQL0802] Data conversion of data mapping error
Я пришел к выводу, что по крайней мере одна запись содержит неверные данные - то, что мой DBA называет "пробелами" или "4 O". Но как это возможно? Не должна ли база данных выдавать исключение при попытке добавления в этот столбец недопустимых данных?

Есть ли какой-либо способ обойти это, например, отфильтровать эти плохие записи в моем запросе?

4 7
sql data-conversion

4 ответа:

"4 O" означает 0x40, который является кодом EBCDIC для пробела или пустого символа и является значением по умолчанию, помещенным в любое новое пространство в записи.

Устаревшие программы / операции могут вводить ошибку десятичных данных. Например, если новый файл был создан и заполнен с помощью команды CPYF с параметром FMTOPT(*NOCHK).

Самый простой способ исправить это-написать программу HLL (RPG), чтобы прочитать файл и исправить записи.

4

Если в файле отключена проверка уровня формата записи [ie. LVLCHK(*NO)] или переопределяется этим, то программа HLL. (экс. RPG, COBOL и т. д.), которые не были перекомпилированы с новой записью, могут записать записи с недопустимыми данными в этом столбце, особенно если новый столбец не находится в конце записи.

Убедитесь, что все программы, использующие собственный ввод-вывод для записи или обновления записей в этом файле, перекомпилированы.

2

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

2

Я смог решить эту ошибку путем принудительного приведения ключевых столбцов к целому числу. Я изменил соединение от этого...

FROM DAILYV INNER JOIN BXV ON DAILYV.DAITEM=BXV.BXPACK

... к этому...

FROM DAILYV INNER JOIN BXV ON CAST(DAILYV.DAITEM AS INT)=CAST(BXV.BXPACK AS INT)

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

0