Why am I getting a “[SQL0802] Data conversion of d

Question

I am not very familiar with iseries/DB2. However, I work on a website that uses it as its primary database.

A new column was recently added to an existing table. When I view it via AS400, I see the following data type:

Type: S
Length: 9
Dec: 2

This tells me it's a numeric field with 6 digits before the decimal point, and 2 digits after the decimal point.

When I query the data with a simple SELECT (SELECT MYCOL FROM MYTABLE), I get back all the records without a problem. However, when I try using a DISTINCT, GROUP BY, or ORDER BY on that same column I get the following exception:

[SQL0802] Data conversion of data mapping error

I've deduced that at least one record has invalid data - what my DBA calls "blanks" or "4 O". How is this possible though? Shouldn't the database throw an exception when invalid data is attempted to be added to that column?

Is there any way I can get around this, such as filtering out those bad records in my query?

Answer 1

"4 O" means 0x40 which is the EBCDIC code for a space or blank character and is the default value placed into any new space in a record.

Legacy programs / operations can introduce the decimal data error. For example if the new file was created and filled using the CPYF command with the FMTOPT(*NOCHK) option.

The easiest way to fix it is to write an HLL program (RPG) to read the file and correct the records.

Answer 2

The only solution I could find was to write a script that checks for blank values in the column and then updates them to zero when they are found.

Answer 3

I was able to solve this error by force-casting the key columns to integer. I changed the join from this...

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

...to this...

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

...and I didn't have to make any corrections to the tables. This is a very old, very messy database with lots of junk in it. I've made many corrections, but it's a work in progress.

Answer 4

If the file has record format level checking turned off [ie. LVLCHK(*NO)] or is overridden to that, then an HLL program. (ex. RPG, COBOL, etc) that was not recompiled with the new record might write out records with invalid data in this column, especially if the new column is not at the end of the record.

Make sure that all programs that use native I/O to write or update records on this file are recompiled.