I have 2 tables A and B. I want to create a third one, C. C must contain each record that is in A but not in B, and each record that is in A and B.
I've tried the following :
SELECT A.* INTO C FROM (A INNER JOIN B ON A.Id = B.Id) LEFT JOIN B ON A.Id = B.Id WHERE B.Id IS NULL;
But it gives me the error message : JOIN expression not supported.
When there's only the INNER JOIN or the LEFT JOIN, it works perfectly. But for some reason when I combine both with the brackets, it doesn't work.
I believe I am using MS-Access 2013, if that helps.
By the way, I'm an Access and an SQL newbie.
The correct logic is:
SELECT A.* INTO C
FROM A LEFT JOIN
B
ON A.Id = B.Id
WHERE B.Id IS NULL;
You do not need two joins. My guess is that the problem with your query is that B appears twice in the FROM clause, without a table alias. MS Access doesn't know what the second B refers to.
Related
I have tried to find how could I use NOT EXISTS / NOT IN clause in HIVE and have not found a solution that HIVE has to offer.
I basically need to find id's that exist in one table and not exist in the second table and I can't find a way to jump over it. Please advise
In hive you can use left join to detech not exist type clause. If you share your sql, i can be more precise. But here is some hint.
select
a.id
from
a
left outer join b on a.id = b.id
left outer join c on a.id = c.id
where
b.id is null -- make sure data doesn't exist in b
and c.id is not null -- make sure data exists in c
left join and where clause make sure data exist in table c but doesn't exist in b.
Consider the following SQL statement
select *
from A
inner join B on A.FK = B.PK
inner join C on A.FK = B.PK
This is clearly an incorrectly formed statement. The join of C is using the join conditions for B. However, this still runs. How does the interpreter decide to join C in this situation? Why is this even an allowed statement? Are there ever any situations where something like this is desirable?
The join condition from a to b is just duplicated, it doesn't matter where it is in the sql as long as after on word. I believe this to be the case.
You are doing a catersian join to the outcome of the join a to b here. If a and b join to produce 15 rows, and c has 20 then your result set is 300 rows.
I have a sql sentence.
select a.*,b.*,c.*
from a
inner join b
on a.id=b.id
left join c
on b.id=c.id
but I not konw it is execute inner join first .then create a temporary table such as temp .and finaly temp left join c. inner join ,left join and right join do they have same level of execution.Thank you!
SQL is not a procedural language. A SQL query describes the result set being produced. When interpreting a query, the join order is from left to right. So, in your query, the result set is the one produced by an inner join on a and b with that result being left joined to c.
You can add parentheses to avoid ambiguity:
from (a inner join
b
on a.id = b.id
) left join
c
on b.id = c.id
But that is unnecessary.
That is logically how the query is processed. The optimization engine can choose many different ways of executing the query, some of which might be pretty unrecognizable as relating to this particular query. The only guarantee is what the result set looks like.
If i write a sql:
select *
from a,b
where a.id=b.id(+)
and b.val="test"
and i want all records from a where corresponding record in b does not exist or it exists with val="test", is this the correct query?
You're much better off using the ANSI syntax
SELECT *
FROM a
LEFT OUTER JOIN b ON( a.id = b.id and
b.val = 'test' )
You can do the same thing using Oracle's syntax as well but it gets a bit hinkey
SELECT *
FROM a,
b
WHERE a.id = b.id(+)
AND b.val(+) = 'test'
Note that in both cases, I'm ignoring the c table since you don't specify a join condition. And I'm assuming that you don't really want to join A to B and then generate a Cartesian product with C.
Move the condition into the JOIN clause and use the ANSI standard join pattern.
SELECT NameYourFields,...
FROM A
LEFT OUTER JOIN B
ON A.ID = B.ID
AND B.VAL = 'test'
INNER JOIN C
ON ...
A LEFT OUTER JOIN is one of the JOIN operations that allow you to specify a join clause. It preserves the unmatched rows from the first (left) table, joining them with a NULL row in the shape of the second (right) table.
So you can do as follows :
SELECT
FROM a LEFT OUTER JOIN b
ON a.id = b.id
--Note that you have used double quote "test" which is not used for varchar in SQL you should use single quote 'test'
AND b.val = 'test';
SELECT * FROM abc a, xyz b
WHERE a.id = b.id
AND b.val = 'test'
Say I have three tables in SQL server 2008 R2
SELECT a.*, b.*, c.*
FROM
Table_A a
RIGHT JOIN Table_B b ON a.id = b.id
LEFT JOIN Table_C c ON b.id = c.id
or
SELECT a.*, b.*, c.*
FROM
Table_A a
RIGHT JOIN Table_B b ON a.id = b.id
JOIN Table_C c ON b.id = c.id
also, does it matter if I use b.id or a.id on joining c?
i.e. instead of JOIN Table_C c ON b.id = c.id, use JOIN Table_C c ON a.id = c.id
Thank you!
If it doesn't change the semantics of the query, the database server can reorder the joins to run in whichever way it thinks is more efficient.
Usually, if you want to force a certain order, you can use inline view subqueries, as in
SELECT a.*, x.*
FROM
Table_A a
RIGHT JOIN
(
SELECT *, b.id as id2 FROM Table_B b
LEFT JOIN Table_C c ON b.id = c.id
) x
ON a.id = x.id2
According to the definitions:
JOIN
: Return rows when there is at least one match in both tables
LEFT JOIN Return all rows from the left table, even if there are no matches in the right table
RIGHT JOIN Return all rows from the right table, even if there are no matches in the left table
The first option would include all raws from the 1st Join on Tables a and b even if there are no matching ones in table c, while the second statement would show only raws which match ones in table c.
regarding the second question i guess it would make a difference, since the 1st join includes all ids from table b, even though there are no matching ones in table a, so once you change your Join creterium to a.id you will get a different set of ids than b.id.
Yes, you do need a LEFT JOIN after a RIGHT JOIN
See
http://sqlfiddle.com/#!3/2c079/5/0
http://sqlfiddle.com/#!3/2c079/6/0
If you don't, the (inner) JOIN at the end will cancel out the effect of your RIGHT JOIN.
That wouldn't make any sense to have a RIGHT JOIN if you don't care. And if you care, you will have to add a LEFT JOIN after it.