Dlaczego otrzymuję wyjątek "[SQL0802] Konwersja danych na błąd mapowania danych"?

Question

Nie jestem zaznajomiony z działem iseries/DB2. Pracuję jednak na stronie internetowej, która wykorzystuje ją jako główną bazę danych.

Nowa kolumna została ostatnio dodana do istniejącej tabeli. Kiedy go zobaczyć poprzez AS400, widzę następujące Typ danych:

Type: S 
Length: 9 
Dec: 2 

to mówi mi, że to pole liczbowe z 6 cyfr przed przecinkiem i 2 cyfr po przecinku.

Kiedy wysyłam zapytanie o dane za pomocą prostego SELECT (SELECT MYCOL FROM MYTABLE), bez problemu otrzymuję wszystkie rekordy. Jednak, gdy próbuję za pomocą DISTINCT, GROUP BY lub ORDER BY na tej samej kolumnie pojawia się następujący wyjątek:

[SQL0802] Data conversion of data mapping error 

mam wnioskować, że przynajmniej jeden rekord ma nieprawidłową danych - co moje rozmowy DBA „półprodukty” lub "4 O". Jak to jest możliwe? Czy baza danych nie powinna generować wyjątku w przypadku próby dodania nieprawidłowych danych do tej kolumny?

Czy mogę obejść ten problem, na przykład odfiltrowując te złe zapisy w moim zapytaniu?

Answer 1

Jedyne rozwiązanie, jakie mogłem znaleźć, to napisać skrypt, który sprawdza puste wartości w kolumnie, a następnie aktualizuje je do zera, gdy zostaną znalezione.

Answer 2

"4 O" oznacza 0x40, który jest kodem EBCDIC dla spacji lub pustego znaku i jest wartością domyślną umieszczoną w dowolnym nowym miejscu w rekordzie.

Starsze programy/operacje mogą wprowadzać błąd danych dziesiętnych. Na przykład, jeśli nowy plik został utworzony i wypełniony przy użyciu polecenia CPYF z opcją FMTOPT(*NOCHK).

Najprostszym sposobem naprawy jest napisanie programu HLL (RPG) w celu odczytania pliku i poprawienia rekordów.

Answer 3

Jeśli plik ma sprawdzanie poziomu formatu rekordu wyłączone [np. LVLCHK(*NO)] lub jest nadpisany, następnie program HLL. (np. RPG, COBOL itp.), który nie został ponownie skompilowany z nowym rekordem, może wypisać w tej kolumnie rekordy z niepoprawnymi danymi, szczególnie jeśli nowa kolumna nie znajduje się na końcu rekordu.

Upewnij się, że wszystkie programy korzystające z rodzimych operacji we/wy do zapisu lub aktualizacji rekordów tego pliku zostaną ponownie skompilowane.

Answer 4

Udało mi się rozwiązać ten błąd, odrzucając kolumny kluczowe do liczby całkowitej. Zmieniłem łączenia z tego ...

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

... do tego ...

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

... i nie trzeba wprowadzać żadnych poprawek do tabel. Jest to bardzo stara, bardzo niechlujna baza danych z mnóstwem śmieci. Wprowadziłem wiele poprawek, ale to praca w toku.