Missing left parenthesis error - oracle

select *
from student3
where marks > (select avg(marks) from table)
missing left parenthesis error occurs when I am running query in Oracle

As Gurvinder (#GurV) firstly pointed out, table is a reserved keyword in Oracle. You can proceed with your current query by escaping table in double quotes, i.e.
select *
from student3
where marks > (select avg(marks) from "table")
But you might want to avoid using table to name your database tables.

Related

ORACLE SUBQUERY NOT WORKING IN (IN CONDITION)

I need help
i have records 123,456,789 in rows when i am execute like
this one is working
select * from table1 where num1 in('123','456')
but when i am execute
select * from table1 where num1 in(select value from table2)
no resultset found - why?
Check the DataType varchare2 or Number
try
select * from table1 where num1 in(select to_char(value) from table2)
Storing comma separated values could be the cause of problem.
You can try using regexp_substr to split comma.
First and foremost, an important thing to remember: Do not store numbers in character datatypes. Use NUMBER or INTEGER. Secondly, always prefer VARCHAR2 datatype over CHAR if you wish to store characters > 1.
You said in one of your comments that num1 column is of type char(4). The problem with CHAR datatype is that If your string is 3 characters wide, it stores the record by adding extra 1 space character to make it 4 characters. VARCHAR2 only stores as many characters as you pass while inserting/updating and are not blank padded.
To verify that you may run select length(any_char_col) from t;
Coming to your problem, the IN condition is never satisfied because what's actually being compared is
WHERE 'abc ' = 'abc' - Note the extra space in left side operator.
To fix this, one good option is to pad the right side expression with as many spaces as required to do the right comparison.The function RPAD( string1, padded_length [, pad_string] ) could be used for this purpose.So, your query should look something like this.
select * from table1 where num1 IN (select rpad(value,4) from table2);
This will likely utilise an index on the column num1 if it exists.
The other one is to use RTRIM on LHS, which is only useful if there's a function based index on RTRIM(num1)
select * from table1 where RTRIM(num1) in(select value from table2);
So, the takeaway from all these examples is always use NUMBER types to store numbers and prefer VARCHAR2 over CHAR for strings.
See Demo to fully understand what's happening.
EDIT : It seems You are storing comma separated numbers.You could do something like this.
SELECT *
FROM table1 t1
WHERE EXISTS (
SELECT 1
FROM table2 t2
WHERE ',' ||t2.value|| ',' LIKE '%,' || rtrim(t1.num1) || ',%'
);
See Demo2
Storing comma separated values are bound to cause problems, better change it.
Let me tell you first,
You have stored values in table2 which is comma seperated.
So, how could you match your data with table1 and table2.
Its not Possible.
That's why you did not get any values in result set.
I found the Solution using string array
SELECT T.* FROM TABLE1 T,
(SELECT TRIM(VALUE)AS VAL FROM TABLE2)TABLE2
WHERE
TRIM(NUM1) IN (SELECT COLUMN_VALUE FROM TABLE(FUNC_GETSTRING_ARRAY(TABLE2.VAL)))
thanks

In query missing expressions of Oracle SQL Developer

SELECT b.*
FROM buses b,
bus_stations bs,
starts st,
stops_at sa
WHERE st.station_no = ( SELECT station_id
FROM bus_stations
WHERE station_name = "golden mile_Regina"
)
AND sa.station_no = ( SELECT station_id
FROM bus_stations
WHERE station_name = 'westmount_edmonton'
)
ORDER BY DATE;
You can't use double quotes with strings - use single ones, i.e.
WHERE station_name = 'golden mile_Regina'
By the way, are you sure of spelling & letter size? Is it really mixed case, with underscores? Just asking.
Furthermore, you're ordering by DATE - that won't work either, you can't use DATE as a column name (unless you enclose it into double quotes, but I certainly wouldn't recommend that). Have a look at the following example (stupid, yes - setting date to be a number, but I used it just to emphasize that DATE can't be used as a column name):
SQL> create table test (date number);
create table test (date number)
*
ERROR at line 1:
ORA-00904: : invalid identifier
Once you fix that, you'll get unexpected result as there are 4 tables in the FROM clause, but they aren't joined with one another, so that will be a nice Cartesian product.

Hive Getting error on group by column while using case statements and aggregations

I am working on a query in hive. In that I am using aggregations like sum and case statements and group by clause. I have changed the column names and table names but my logic is same which I was using in my project
select
empname,
empsal,
emphike,
sum(empsal) as tot_sal,
sum(emphike) as tot_hike,
case when tot_sal > 1000 then exp(tot_hike)
else 0
end as manager
from employee
group by
empname,
empsal,
emphike
For the above query I was getting error as "Expression not in group by key '1000'".
So I have slightly modified the query and tried again My other query is
select
empname,
empsal,
emphike,
sum(empsal) as tot_sal,
sum(emphike) as tot_hike,
case when sum(empsal) > 1000 then exp(sum(emphike))
else 0
end as manager
from employee
group by
empname,
empsal,
emphike
For above query its putting me error as "Expression not in group by key 'Manager'".
When I add manager in the group by its showing invalid alias.
Please help me out here
I see three issues in your query:
1.) Hive cannot group by a variable you defined in the select block by the name you gave it right away. You will probably need a subquery for that.
2.) Hive tends to show errors when sum or count operations are not at the end of the query.
3.) Although I do not know what your goal is, I think that your query will not deliver the desired result. If you group by empsal there would be no difference between empsal and sum(empsal) by design. Same goes for emphike and sum(emphike).
I think the following query might solve these issues:
select
a.empname,
a.tot_sal,
a.tot_hike,
if(a.tot_sal > 1000, exp(a.tot_hike), 0) as manager
from
(select
empname,
sum(empsal) as tot_sal,
sum(emphike) as tot_hike,
from employee
group by
empname
)a
The if statement is equivalent to your case statement, however I find it a bit easier to read.
In this example you wouldn't need to group by after the subquery because the grouping is done in the subquery a.

Vertica - Subquery used as an expression returned more than one row

Is it possible to run a query which matches ANY rows in another table column? I'm trying to run this for example:
SELECT *
FROM emails
WHERE address ILIKE '%#' || IN (select * from dictionary.wordlist) || '.%'
However this returns [Vertica]VJDBC ERROR: Subquery used as an expression returned more than one row
Now that's a strange way of formulating it...
If you go back to a basic SQL tutorial, you will understand that a string literal like '%#' , which can be the operand of an ILIKE predicate, cannot be concatenated with an IN () clause - which is a predicate in itself.
I assume that you are looking for all rows in the emails table whose address contains any of the words in dictionary.wordlist between the at-sign and a dot.
I hope (correct me if I'm wrong) that dictionary.wordlist is a table with one column in VARCHAR() or other string format. If that is the case, you can go like this:
WITH
-- out of "dictionary.wordlist", create an in-line-table containing a column
-- with the wildcard operand to be later used in an ILIKE predicate
operands(operand) AS (
SELECT
'%#'||wordlist.word||'.%'
FROM dictionary.wordlist
)
SELECT
emails.*
FROM emails
INNER JOIN operands
ON email.address ILIKE operands.operand
;
There are other ways of doing it, of course, but this is one of them.
I'm not trying to say it will be very fast - an ILIKE predicate as a JOIN condition can't be performant ...
Good luck
Marco the Sane

oracle SQL and ( ) brackets in where

I have an application which automatically add brackets after WHERE condition and send it to JDBC Oracle driver, Oracle doesn't like it and thrown: ORA-00907: missing right parenthesis
I'm not sure how to work with it in the scope of Oracle syntax, but any suggestion to fix it having this brackets or it's not supported by the syntax?
Original query works just fine:
SELECT count(*) as ErrorCount, Engine_name, to_char(log_time,'hh24') as Hour FROM eailog_data.err_log WHERE err_timestamp > sysdate-1/24 GROUP BY engine_name, to_char(log_time,'hh24') HAVING count(*) > 100 AND count(*) > 0 ORDER BY count(*)
and 3rd party application modify it like this (note brackets added after WHERE condition):
SELECT count(*) as ErrorCount, Engine_name, to_char(log_time,'hh24') as Hour
FROM eailog_data.err_log
WHERE
(
err_timestamp > sysdate-1/24
GROUP BY engine_name,
to_char(log_time,'hh24')
HAVING count(*) > 100
)
AND count(*) > 0
ORDER BY count(*)
Any ideas how to fix SQL with added brackets?
The WHERE clause parenthetical expression needs to end at the end of the WHERE clause and the condition in the HAVING clause ends with a parenthesis, but never begins.
In terms of adding parenthesis, certainly you could add a parenthesis at the end of the WHERE clause and add a parenthesis at the beginning of the HAVING clause as follows:
SELECT count(*) AS errorcount,
engine_name,
to_char(log_time,'hh24') AS HOUR
FROM eailog_data.err_log
WHERE ( err_timestamp > SYSDATE-1/24 )
GROUP BY engine_name,
to_char(log_time,'hh24')
HAVING ( count(*) > 100 )
AND count( *) > 0
ORDER BY count(*)
Since this is an application, it sounds like you need to work with the author of the application to fix their parenthesis usage.
Here is an example using the DUAL table
Before, malformed parenthetical expression in the WHERE and HAVING clause.
SCOTT#dev> SELECT dummy,
2 COUNT(*)
3 FROM dual
4 WHERE (dummy != 'Y'
5 GROUP BY dummy
6 HAVING COUNT( *) = 1)
7 AND COUNT( *) > 0
8 ORDER BY COUNT(*)
9 /
WHERE (dummy != 'Y'
*
ERROR at line 4:
ORA-00907: missing right parenthesis
After, corrected parenthetical expression in the 'WHERE' and 'HAVING' clause.
SCOTT#dev> --corrected
SCOTT#dev> SELECT dummy,
2 COUNT(*)
3 FROM dual
4 WHERE (dummy != 'Y')
5 GROUP BY dummy
6 HAVING (COUNT( *) = 1)
7 AND COUNT( *) > 0
8 ORDER BY COUNT(*)
9 /
D COUNT(*)
= ==========
X 1
A SQL statement consists of several clauses (some of which are optional):
the column list
the table list (FROM clause)
filter conditions (WHERE clause)
aggregate columns (GROUP BY clause)
aggregate conditions (HAVING clause)
etc.
The key concept that seems to be missing is that you can't open a parenthesis in one clause and close it in another. The reason the error you're getting is "missing right parenthesis" is that the SQL engine thinks you're done with the WHERE clause as soon as it sees GROUP BY. Since there was a un-closed parenthetical at that point, it can't parse any further.
To use an analogy, the SQL you provided is like having the opening and closing parenthesis in different methods in Java. It simply can't work.
There are at least two ways to get around some tool mangling your SQL syntax: Creative SQL to subvert the parser, and convert the SQL.
Creative SQL
Parsing Oracle SQL is virtually impossible to do 100% correctly since the syntax is much more complicated than other languages. This leads to problems with beautifiers and code generators. I've seen tools fail in ways very similar to your example.
But this complexity also offers many opportunities to subvert tools that try to rewrite SQL. Try different features until you find something that is immune to their parser. Here are some ideas:
Inline view. select * from (select ... from ... where ... ) where 1=1;
Common table expression. with some_query as (select ... from ... where ... ) select * from some_query;
Alternative quoting mechanism.
select dummy
from dual
where '''' = q'<'>' --The parser probably thinks this is still a string.
and 1 = 1
group by dummy
--' --And it probably thinks this is the end.
Convert SQL
In extreme cases there are ways to make Oracle accept completely broken SQL. Check out
SQL Translation Framework
and DBMS_ADVANCED_REWRITE.
Those tools are definitely a last resort. It would be great if we could wave a magic wand and fix all 3rd party programs but we have to live in the real world.

Resources