I have 2 complex sql statements but they both have the same column name.
I am trying to do a union between both but the
UNION
says Incorrect syntex near UNION.
not sure if there is anything else necessary to make it work.
Because I always terminate my SQL statements with a semicolon (), I sometimes see this error e.g.
SELECT c
FROM T1; <-- forgot to remove the terminator!
UNION
SELECT c
FROM T2;
The syntax that I usually use for unions is:
select *
from
(
(<subquery 1>)
union all
(<subquery 2>)
) t
UNION ALL is more efficient than UNION, since it doesn't check for an eliminate duplicates.
Related
Is it possible to create a CTE without a FROM, and if not isn't that the whole point of a CTE in the first place?
WITH cte AS
(
SELECT 1 AS col1, 2 AS col2
)
SELECT col1, col2 FROM cte;
> ORA-00923: FROM keyword not found where expected
It seems a quick-fix for this is just adding FROM DUAL whenever needed. Is that what's supposed to be done?
Yes, that's exactly what dual is supposed to be used for.
Selecting from the DUAL table is useful for computing a constant
expression with the SELECT statement. Because DUAL has only one row,
the constant is returned only once.
https://docs.oracle.com/cd/B19306_01/server.102/b14200/queries009.htm
I want to run two Oracle SQL queries together inside TOAD.
first query:
SELECT * FROM OT_SO_HEAD WHERE SOH_ANNOTATION = 'ECSO10012791'
and second:
SELECT * FROM OT_SO_ITEM WHERE SOI_SOH_SYS_ID = '30977853'
Please guide
You can use UNION or UNION ALL.
The UNION operator is used to combine the result-set of two or more SELECT statements.
Every SELECT statement within UNION must have the same number of columns
The columns must also have similar data types
The columns in every SELECT statement must also be in the same order
Syntax:
SELECT column_name(s) FROM table1
UNION
SELECT column_name(s) FROM table2;
The UNION operator selects only distinct values by default. To allow duplicate values, use UNION ALL.
right click in script window and select EXECUTE -> Execute via Toad Script Runner and reuse Toad
I ran this code in an sqlite3 terminal (version 3.29.0), and the result is a little strange:
sqlite> select sum((select 4 union all select 2 ));
4
sqlite> select sum((select 4 union select 2 ));
2
I understand why union reverses the table, but why does sum choose the first element?
Meanwhile, this code works just as expected:
sqlite> select sum(x) from (select 4 as x union all select 2 as x);
6
Is this the intended behavior, or is this a bug in sqlite? And if it's intended, what's the logic (and semantics) behind it?
That's expected behavior.
From the documentation (emphasis added)
A SELECT statement enclosed in parentheses is a subquery. All types of SELECT statement, including aggregate and compound SELECT queries (queries with keywords like UNION or EXCEPT) are allowed as scalar subqueries. The value of a subquery expression is the first row of the result from the enclosed SELECT statement. The value of a subquery expression is NULL if the enclosed SELECT statement returns no rows.
The UNION example just happened to end up returning.rows in a different order than the UNION ALL one. Without an ORDER BY neither one is guaranteed to use a particular order, though.
I'm using Sybase ASE 12.5.0.3 and I'm unable to do subqueries like:
select * from (select '1' union select '2' ) X
I've been looking around and as far as I know it should be possible after Sybase ASE 12, am I doing something wrong, or is it not possible with this version???
Edit - Even after changing the query to:
select * from (select '1' as col1 union select '2' as col1 ) X
So even giving alias to the columns, it fails anyways...
Without seeing an error message, it appears that you need to give column aliases in your sub-query:
select *
from
(
select '1' as yournewCol
union
select '2' as yournewCol
) X
You need to give your columns name. Try this:
Sybase ASE does not support subqueries in the FROM clause:
Subqueries can be nested inside the where or having clause of an outer select, insert, update, or delete statement, inside another subquery, or in a select list. Alternatively, you can write many statements that contain subqueries as joins; Adaptive Server processes such statements as joins.
Here's my query:
SELECT my_view.*
FROM my_view
WHERE my_view.trial in (select 2 as trial_id from dual union select 3 from dual union select 4 from dual)
and my_view.location like ('123-%')
When I execute this query it returns results which do not conform to the my_view.location like ('123-%') condition. It's as if that condition is being ignored completely. I can even change it to my_view.location IS NULL and it returns the same results, despite that field being not-nullable.
I know this query seems ridiculous with the selects from dual, but I've structured it this way to replicate a problem I have when I use a 'WITH' clause (the results of that query are where the selects from dual inline view are).
I can modify the query like so and it returns the expected results:
SELECT my_view.*
FROM my_view
WHERE my_view.trial in (2, 3, 4)
and my_view.location like ('123-%')
Unfortunately I do not know the trial values up front (they are queried for in a 'WITH' clause) so I cannot structure my query this way. What am I doing wrong?
I will say that the my_view view is composed of 3 other views whose results are UNION ALL and each of which retrieve some data over a DB Link. Not that I believe that should matter, but in case it does.
One thing you could try if you don't have luck with this route is to replace "IN" with an "EXISTS" or "NOT EXISTS" statement.
If you could accomplish what you want using joins, that would be the best option because of performance. If you have views pulling data from views, you can often make a single query to do what you want that gives you better performance using subqueries.
If you do
EXPLAIN PLAN FOR
SELECT my_view.*
FROM my_view
WHERE my_view.trial in (select 2 as trial_id from dual union select 3 from dual union select 4 from dual)
and my_view.location like ('123-%');
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
you should see where the location predicate is 9or is not) being applied. My bet is that it has something to do with the DB links and you won't be able to reproduce it if all the tables are local.
Optimizing a distributed query gets complicated.
Try changing the UNION query to use UNION ALL, as in:
SELECT my_view.*
FROM my_view
WHERE my_view.trial in (select 2 as trial_id from dual
UNION ALL
select 3 AS TRIAL_ID from dual
UNION ALL
select 4 AS TRIAL_ID from dual)
and my_view.location like ('123-%')
I also put in "AS TRIAL_ID" on the 3 and 4 cases. I agree that neither of these should matter, but I've run into cases occasionally where things that I thought shouldn't matter mattered.
Good luck.