CODEWITHSUNDEEP
sqldb2ibm-midrange
Santiago Hitta
Santiago Hitta

Reputation: 75

SQL0802 - invalid numeric data

I'm on a db2 database over as400 system. I have a select query that is throwing the error in the title: SQL0802 code 6 which is "invalid numeric data" (translated).

I have tried separating the query in different parts and testing each part one by one to see if it works, I am 99% convinced that the problem comes because of a "CAST" clause I am using in a subquery(to cast CHAR to INT), I just don't understand why the subquery works by itself but it doesn't work as a part of the main query.

So if I run the subquery with the "CAST" clause it works fine, but when I run the main query that uses the subquery it doesn't work and the error arises. Main query can be divided in 2 queries, see the code below.

query1 looks something like this:

select SUM(Price) from TABLE1 
where X = 1
group by Country
having SUM(Price) = (query2);

query2 looks something like this:

SELECT SUM(UnitPrice * AmountStocked)
FROM TABLE2
WHERE J = X and ItemNumber in (
    SELECT CAST(ItmNumbr AS INT) from TABLE3
   where Id in (select Id from TABLE4 where Z=Y)
    )

Notes:

*query2 will return a single number.

*Running query2 by itself works fine.

*Running query1 without the "having" clause works fine too.

*If I substitute the "SELECT CAST..." subquery in query2 with something like "(2002, 9912, 1234)" and then run the main query it works fine, so this pretty much confirms that the problem is the "CAST" clause.

*I have to CAST ItmNumbr to INT because ItemNumber is of Numeric type and ItmNumbr is of Char type.

Upvotes: 1

Views: 1957

Answers (3)

jmarkmurphy
jmarkmurphy

Reputation: 11473

You said:

*I have to CAST ItmNumbr to INT because ItemNumber is of Numeric type and ItmNumbr is of Char type.

But this is not true. You could cast the other way around:

SELECT SUM(UnitPrice * AmountStocked)
FROM TABLE2
WHERE J = X and CHAR(ItemNumber) in (
    SELECT TRIM(ItmNumbr) from TABLE3
    where Id in (select Id from TABLE4 where Z=Y)
)

The advantage here is that non-numeric characters in ItmNumber will not blow you up, and CHAR(ItemNumber) should also not fail.

One thing to know about DB2 for i is that there are two ways to create database tables, and the two differ slightly in the characteristics of the resulting table. If the table is created using DDL (CREATE TABLE ...), then that table cannot contain bad data. The data types are verified on write, no matter how you write the data, it is validated before being written to the table. If the table is created by DDS (CRTPF ...), the table can indeed contain bad data because the data is not validated until it is read and loaded into a variable. Old style programs that write data to DDS tables by writing a record from a program described data structure are able to put whatever they want into a DDS defined table, including numeric data in character fields or worse, character data in numeric fields. This usually is only found in very old databases that have been migrated from the System/36 (circa 1980's) which used flat files rather than database files (it had no notion of a database). I only posit this because it is possible. Check the data in your file using hex() to see if there is anything funky in the ItmNumbr or ItemNumber fields.

Upvotes: 1

Daniel Lema
Daniel Lema

Reputation: 334

Based on your analysis:

"*If I substitute the "SELECT CAST..." subquery in query2 with something like "(2002, 9912, 1234)" and then run the main query it works fine, so this pretty much confirms that the problem is the "CAST" clause."

Check the content of TABLE3.ItmNumbr. If it is defined as NUMERIC (unpacked decimal) it may contain non-numeric values (typically spaces). That may be causing the error you are observing.

Upvotes: 0

wavery
wavery

Reputation: 279

I am not sure but I am thinking the issue has to do with your join of "WHERE J = X" since we don't know what "J" is and it may not join to "X" (not the correct data type).

Upvotes: 0

Related Questions