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.
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.
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).
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.
Related
My problem is that I would like to make an append query in Ms-Access 2010. I tried to realize it in query designer, but it throws an error:
Type mismatch in expression
See the generated code below:
INSERT INTO Yield ( ProcessName, Sor, Lot,
ProcessCode, Outgoing, DefectReason, DefectQty, ModifyQty )
SELECT Process.[ProcessName], Sor.[Sor], Qty.[Lot], Qty.[ProcessCode],
Qty.[Outgoing Date], Qty.[Defect Reason], Qty.[Defect Qty], Qty.[Modify_Qty]
FROM (Sor INNER JOIN ProcessCode ON Sor.[SorID] = ProcessCode.[SorID])
INNER JOIN (Process INNER JOIN Qty ON Process.[ProcessID] = Qty.[ProcessID])
ON ProcessCode.[ProcessID] = Process.[ProcessID];
The tables and the attributes are all existing. The ID numbers are indexes, the Quantities are numerical, the 'ProcessName', 'Sor', 'Lot', 'ProcessCode', 'DefectReason' attributes are strings.
What could be the problem?
Thanks in advance.
Looks ok. The best advice is divide it in smaller pieces.
http://importblogkit.com/2015/05/how-do-you-eat-an-elephant/ .
Try this:
Remove the insert part. Just try the select to make sure the join are working properly. If this fail the problem is on the join fields
Then, Put the insert again, but instead of putting table fields from the SELECT use default values. '' for strings and 0 for numeric and put the right alias for column name. That way you make sure your data is bringing the right data type. If this fail then one of the field isnt really a string or a number. Like gustav suggest probably a DATE
If that work then try to put one table field each time until you find the one causing the problem. Maybe one field doesnt support null or is receiving a bigger value than supported.
The problem was that the Yield table did not have the listed attributes. I thought that if some of the listed output attributes are not included in the output table, Access automatically creates the missing new attributes. I was wrong. The output table has to contain the attributes (rows), new attributes cannot be inserted into it this way.
I'm comparing account numbers in two different databases to make sure the account exists in both. The account field in one database is nvarchar and the other it's varchar. I do a cast to cast them both to varchar(12) and join them to see where there isn't a match. If there is an account number with less than 12 characters then it thinks it's not a match. I'm assuming the extra characters in each field are causing the issue?
table1 - accountnumber(nvarchar(255))
table2 - accountnumber(varchar(20))
select * from
table1
left outer join table2 on table2.accountnumber = table1.accountnumber
In this one example, both tables have an account with the number 12345678, but the join isn't working. I'm not sure if it's data type mismatch or white space or something else.
--Added--
I should add that the data in table2 actually originates from an Oracle database where it's stored as a varchar2(12 byte). I import it into a SQL Server database where it's stored as a varchar(20). I'm not sure if this makes a difference.
Not sure where you are having a problem. This query should return matching account numbers (no need to CAST):
SELECT *
FROM YourTable
JOIN YourOtherTable ON YourTable.AccountNumber = YourOtherTable.AccountNumber
If your data has spaces, you can TRIM your data depending on your RDBMS -- LTRIM and RTRIM for SQL Server.
SELECT *
FROM YourTable
JOIN YourOtherTable ON RTRIM(LTRIM(YourTable.AccountNumber)) = RTRIM(LTRIM(YourOtherTable.AccountNumber))
Here is the SQL Fiddle.
Good luck.
Your query works fine. This is perhaps a character encoding issue. Try using collate. See this previous SO answer which might help.
I ran into absolutely same case, I had even two sibling queries (one created as a copy of another), which both had this problem. Collation and types were no issue here.
Finally after a LOT of testing, one of the queries started to work without aparent changes, just re-written. When I retyped the IN part of the second query, it started to work too.
So there was a problem with a hidden character accidentally typed somewhere in the query.
I found this odd behavior and I'm breaking my brains with this... anyone has any ideas?
Oracle 10g:
I have two different tables, both have this column named "TESTCOL" as Varchar2(10), not nullable.
If I perform this query on table1, i get the proper results:
select * from table1 where TESTCOL = 1234;
Note that I'm specifically not placing '1234'... it's not a typo, that's a dynamic generated query and I will try not to change it (at least not in the near future).
But, if I run the same query, on table2, I get this error message:
ORA-01722: Invalid number
Both queries are run on the same session, same database.
I've been joining these two tables by that column and the join works ok, the only problem shows whenever I try to use that condition.
Any ideas on what could be different from one table to the other?
Thanks in advance.
If TESTCOL contains non-numbers, then Oracle might run into problems when converting TESTCOL entries to numbers. Because, what it does internally, is this:
select * from table1 where TO_NUMBER(TESTCOL) = 1234;
If you're so sure that 1234 cannot be expressed as a VARCHAR literal, then try this instead, in order to compare varchar values, rather than numeric ones:
select * from table1 where TESTCOL = TO_CHAR(1234);
Well obvious TABLE2.TESTCOL contains values which are not numbers. Comparing a string to a numeric literal generates an implicit conversion. So any value in TESTCOL hich cannot be cast to a number will hurl ORA-1722.
It doesn't hit you where you compare the two tables because you are comparing strings.
So you have a couple of options, neiher of which you will like. The most obvious answer is to clean the data so TABLE2 hdoesn't contain non-numerics. Ideally you should combine this with changing the column to a numeric data type. Otherwise you can alter the generator so it produces code you can run against a shonky data model. In this case that means wrapping literals in quote marks if the mapped column has a character data type.
You are hitting the perils of implicit typecasting here.
With the expression testcol = 1234 you state that you want to treat testcol as a numeric column, so Oracle tries to convert all values in that column to a number.
The ORA-01722 occurs because apparently at least one value in that column is not a number.
Even though you claim that this is "not a typo" it indeed is one. It's a syntactical error.
You will have to declare your parameter as a string literal using single quotes: where testcol = '1234'
Creating a correct condition is the only solution to your problem.
The following should work. Just replace the "your where".
select *
from table1
where (select TO_NUMBER(TESTCOL)
from table2
where "your where") = 1234;
I came across a weird situation when trying to count the number of rows that DO NOT have varchar values specified by a select statement. Ok, that sounds confusing even to me, so let me give you an example:
Let's say I have a field "MyField" in "SomeTable" and I want to count in how many rows MyField values do not belong to a domain defined by the values of "MyOtherField" in "SomeOtherTable".
In other words, suppose that I have MyOtherField = {1, 2, 3}, I wanna count in how many rows MyField value are not 1, 2 or 3. For that, I'd use the following query:
SELECT COUNT(*) FROM SomeTable
WHERE ([MyField] NOT IN (SELECT MyOtherField FROM SomeOtherTable))
And it works like a charm. Notice however that MyField and MyOtherField are int typed. If I try to run the exact same query, except for varchar typed fields, its returning value is 0 even though I know that there are wrong values, I put them there! And if I, however, try to count the opposite (how many rows ARE in the domain opposed to what I want that is how many rows are not) simply by supressing the "NOT" clause in the query above... Well, THAT works! ¬¬
Yeah, there must be tons of workarounds to this but I'd like to know why it doesn't work the way it should. Furthermore, I can't simply alter the whole query as most of it is built inside a C# code and basically the only part I have freedom to change that won't have an impact in any other part of the software is the select statement that corresponds to the domain (whatever comes in the NOT IN clause). I hope I made myself clear and someone out there could help me out.
Thanks in advance.
For NOT IN, it is always false if the subquery returns a NULL value. The accepted answer to this question elegantly describes why.
The NULLability of a column value is independent of the datatype used too: most likely your varchar columns has NULL values
Do deal with this, use NOT EXISTS. For non-null values, it works the same as NOT IN so is compatible
SELECT COUNT(*) FROM SomeTable S1
WHERE NOT EXISTS (SELECT * FROm SomeOtherTable S2 WHERE S1.[MyField] = S2.MyOtherField)
gbn has a more complete answer, but I can't be bothered to remember all that. Instead I have the religious habit of filtering nulls out of my IN clauses:
SELECT COUNT(*)
FROM SomeTable
WHERE [MyField] NOT IN (
SELECT MyOtherField FROM SomeOtherTable
WHERE MyOtherField is not null
)
I have the same copy of access running in 3 cities right now. They work perfectly ok. They are 99% the same with one minor difference. Each of them has two views which use different odbc connection to different cities DB (all these databases are SQL Server 2005). The views act as datasource for some two very simple queries.
However, while I tried to make a new copy for a new city, I found that one of the simple internal query returns the correct number of row but all data are empty while the other query functions correctly.
I checked the data of these two views, the data is correct.
The one causing problem are like
Select * from View_Top where Name = "ABC"
when the recordset returns, even rs!Name give me an empty string.
Please help
Well the query looks a little wrong to me, try using ' instead of " to delimit your ABC string...
Without the definition of VIEW_TOP it's hard to tell where your error is, but if you're getting rows but the columns are NULL I'm guessing that VIEW_TOP (or something it depends on) includes an OUTER JOIN and you're pulling the columns from the wrong side of the JOIN.
SELECT
acc.FIRM,
acc.OFFICE,
acc.ACCOUNT,
a.CONV_CODE,
a.OTHER_AMT AS AMOUNT,
a.TRANS_DATE,
a.DESCRIPTN,
a.JRNAL_TYPE
FROM AccTrans AS a LEFT OUTER JOIN ACC AS acc ON a.ACCNT_CODE = acc.ACCNT_CODE
WHERE
(acc.SUN_DB = 'IF1') AND
(ANAL_T0 <> '') AND
(a.TRANS_DATE < '20091022') AND
(a.JRNAL_TYPE = 'MATCH');
This is the definition of the view. Indeed, in Access i am able to view the result of this query, it has data. that's why i know the recordset returns the correct number of row (by counting the loop in the code). sorry for my mistakes, i use Account in the where clause, the select statements should be like
select Firm, Office, Account, Trans_Date.... from
view_top
where account = 'ABC'
the query returns the right number of row but all row data (even the account field) are empty string.
then i found out what really cause the problem is the AMOUNT field, if i omit the amount, everything works. though i don't understand why.
view_top definition
"Name, Account, AccountCode, Amount, Date...."
Select Statements:
Select Name, Account, AccountCode, Amount, Date
From View_Top Where Name = 'xxx'
I found that if I omit the Amount, everything works.
Though I still don't understand why.