I have 2 queries, which takes data dynamically.
Select cid from table1 where cNumber={{custNbr}}
Here {{custNbr}} comes from a .txt file.
update table2 set status='A' where customer_id=NVL({{cid}},0000)
Here {{customer_id}} comes from output of step 1.
Issue: When step 1 returns NULL, it actually returns an empty string ''. As a result, Step 2 translates to -
update table2 set status='A' where customer_id=NVL(,0000)
This throws an error java.sql.SQLSyntaxErrorException: ORA-00936: missing expression
How do I rewrite the queries to make them work.
In your case, it's probably sufficient to provide a fallback for the result of the first query:
Select nvl(cid, -1) as cid
from table1
where cNumber={{custNbr}}
This assumes that -1 does not appear as a customer ID in table2. Therefore, the UPDATE will be syntactically valid, but it will update zero rows.
CAVEAT
However, I'd be strongly suspicious of a tool that cannot handle NULL values as input to Database queries. You might want to contact the DevTest support regarding this.
Related
I'm using SQL developer and I'm getting an error I don't fully understand.
Due to data privacy, I cannot share the real query, but the question is fairly simple.
I have a query to obtain table T (which works if ran alone) and I want to filter a Y/N flag so I have the following query:
select * from T where flag ='Y'
While this query works, I want the observations which do not fullfil the condition but neither of the following queries works:
select * from T where flag <>'Y'
select * from T where flag ='N'
*I get the following error:
01722. 00000 - "invalid number"
*Cause: The specified number was invalid.
Action: Specify a valid number .
Vendor code 1722
I tried to export the table to analyze it on another language, but I still get the same error.
Can anyone help?
As you confirmed T in your example is not a table, your error simply seems to be caused by a conversion error somewhere on 1 or several records WHERE flag <> 'Y'. This is why the query works with flag = 'Y' but not with your other conditions.
Minimal case to reproduce would be something like:
CREATE TABLE MyTable (
Field VARCHAR(10),
Flag VARCHAR(1)
);
CREATE VIEW T AS SELECT to_number(Field), Flag FROM MyTable;
INSERT INTO MyTable VALUES ('1', 'Y'); /* OK */
INSERT INTO MyTable VALUES ('No way', 'N'); /* Fails */
In your case, the error may not be caused by a call to to_number but this is the best clue I can give given the limited information you provide. It might not be a call to a function at all but the result of a calculation using operators only.
You simply need to make sure the fields can be converted/used in a calculation before you actually attempt to do so (CASE WHEN ... THEN ... ELSE NULL for instance).
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.
I'm trying to update a procedure we run by switching out a list of static varchars within an IN statement (which is in a join condition) to use a subquery instead. However, I'm getting an error saying Conversion failed when converting the varchar value 'Normal' to data type int.
I know that means somewhere in the query I'm trying to convert the value 'Normal' to an int, but in this query there's not a place where anything should be an int - it's all varchar or datetime, and the subquery returns the same values as the former static list of varchars. Furthermore, there's not a place anywhere in my dataset with the value "Normal", which is what really confuses me.
Has anyone else dealt with something like this before?
EDIT:
Here's the code (reduced to just show the pieces that are causing the error):
select * from #tempTable
left join dbo.v_Lookup_Assumptions Assumptions on
case when Group3 in
--('Value1', 'Value2', 'Value3')
(Select lookupdetail_name from lookupDetail)
then Group3 else Group2 end =Assumptions.Sector2
and AsOfDate between Assumptions.StartDate and Assumptions.EndDate
and ShortName = Assumptions.AssumptionShortName
I can comment out the subquery and uncomment the list of values and it works. Also, if I don't run the "ShortName" constraint when I'm using the subquery, it works (though doesn't give the expected results, as you might expect). All join constraints are either varchar or date.
In addition, I added 'Normal' to the list of static values and it ran as expected. I also updated the subquery to SELECT 'Value1' from lookupDetail and it failed.
EDIT2:
And this makes no sense, but if I limit the original #tempTable to 2080 records, the new subquery syntax works. However, if I let it go to 2081 records it fails - regardless of the dataset. In other words, as I change the dates around so I get different data each time through and limit #tempTable to 2080 records, this new syntax works just fine. Change it to 2081 records and it fails. If I run through the 2081 record dataset and filter with a WHERE clause, I can get every row in the 2081 record to display as long as it's not all 2081 at the same time.
It turns out the execution plan was changing when the total number of records would exceed 2080, and was implicitly converting a varchar field to an int. I grabbed the XML query plan for the small dataset from SQL Server Profiler and forced the larger dataset query to use it with OPTION (USE PLAN '<Insert XML Query Plan Here />').
I have sql query:
select * from table where id in (1,2)
1,2 are parameters which I add there dynamically. But what If I have empty set:
select * from table where id in ()
then this query call exception:
ERROR at line 1:
ORA-00936: missing expression
how should I create sql with empty set
You can always add null to your set, so when the real set is empty, you get no syntax error:
select * from table where id in (null,1,2)
vs
select * from table where id in (null)
Your generator would be simpler, too, because you can print a , in front of every item that you add, without checking if it's the first one or not.
Of course since you are generating your SQL, the standard precautions against SQL Injection apply: do not let user input anywhere near the SQL that you generate.
Try this
select * from table where id in (null)
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;