By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,610 Members | 1,989 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,610 IT Pros & Developers. It's quick & easy.

Outer Join not working when using SQL-92

P: n/a
All,

I have a perplexing problem that I hope someone can help me with.

I have the following table struct:

Permission
-----------------
PermissionId
Permission
Description

UserPermission
-----------------
PermissionId
UserId
Active

I am attempting to retrieve all records from the permission table
whether there is a match on UserPermission.PermissionId or not.
Therefore I implemented this query, which does not produce the results
that I expect:

SELECT p.Permission,
up.Active

FROM Permission p
LEFT OUTER JOIN UserPermission up
ON p.[Id] = up.PermissionId
WHERE up.UserId = 3
However, if I exec this query, it works as it is supposed to:
SELECT p.Permission,
up.Active

FROM Permission p, UserPermission up
WHERE p.[Id] *= up.PermissionId AND up.UserId = 3

In the first query, only the records that match on "permissionId" are
returned, in the second all records are returned from the Left table
and those records that do not have matching columns are set to null, as
it should be. My question is, what have I done wrong here?

I am running MS-SQLServer 2000

Jul 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
The problem is with the way you are using SQL-92 standard.

Instead use the query as follows:
SELECT P.Permission, up.Active
FROM Permission p
LEFT OUTER JOIN UserPermission up
ON p.permissionid = up.PermissionId
AND up.UserId = 3

Regards
Debian


*** Sent via Developersdex http://www.developersdex.com ***
Jul 23 '05 #2

P: n/a
Thanks Debian, that did it. Is it then incorrect to use the WHERE
clause when using an outer join? I've looked at books on-line and
could not find a reference to using WHERE clauses with outer joins,
however they appear to be a typical part of inner joins.

Jul 23 '05 #3

P: n/a
Here is a "cut & paste" lecture:

Here is how OUTER JOINs work in SQL-92. Assume you are given:

Table1 Table2
a b a c
====== ======
1 w 1 r
2 x 2 s
3 y 3 t
4 z

and the outer join expression:

Table1
LEFT OUTER JOIN
Table2
ON Table1.a = Table2.a <== join condition
AND Table2.c = 't'; <== single table condition

We call Table1 the "preserved table" and Table2 the "unpreserved table"
in the query. What I am going to give you is a little different, but
equivalent to the ANSI/ISO standards.

1) We build the CROSS JOIN of the two tables. Scan each row in the
result set.

2) If the predicate tests TRUE for that row, then you keep it. You also
remove all rows derived from it from the CROSS JOIN

3) If the predicate tests FALSE or UNKNOWN for that row, then keep the
columns from the preserved table, convert all the columns from the
unpreserved table to NULLs and remove the duplicates.

So let us execute this by hand:

Let @ = passed the first predicate
Let * = passed the second predicate

Table1 CROSS JOIN Table2
a b a c
=========================
1 w 1 r @
1 w 2 s
1 w 3 t *
2 x 1 r
2 x 2 s @
2 x 3 t *
3 y 1 r
3 y 2 s
3 y 3 t @* <== the TRUE set
4 z 1 r
4 z 2 s
4 z 3 t *

Table1 LEFT OUTER JOIN Table2
a b a c
=========================
3 y 3 t <= only TRUE row
-----------------------
1 w NULL NULL Sets of duplicates
1 w NULL NULL
1 w NULL NULL
-----------------------
2 x NULL NULL
2 x NULL NULL
2 x NULL NULL
3 y NULL NULL <== derived from the TRUE set - Remove
3 y NULL NULL
-----------------------
4 z NULL NULL
4 z NULL NULL
4 z NULL NULL

the final results:

Table1 LEFT OUTER JOIN Table2
a b a c
=========================
1 w NULL NULL
2 x NULL NULL
3 y 3 t
4 z NULL NULL

The basic rule is that every row in the preserved table is represented
in the results in at least one result row.

There are limitations and very serious problems with the extended
equality version of an outer join used in some diseased mutant
products. Consider the two Chris Date tables

Suppliers SupParts
supno supno partno qty
========= ==============
S1 S1 P1 100
S2 S1 P2 250
S3 S2 P1 100
S2 P2 250

and let's do an extended equality outer join like this:

SELECT *
FROM Supplier, SupParts
WHERE Supplier.supno *= SupParts.supno
AND qty < 200;

If I do the outer first, I get:

Suppliers LOJ SupParts
supno supno partno qty
=======================
S1 S1 P1 100
S1 S1 P2 250
S2 S2 P1 100
S2 S2 P2 250
S3 NULL NULL NULL

Then I apply the (qty < 200) predicate and get

Suppliers LOJ SupParts
supno supno partno qty
===================
S1 S1 P1 100
S2 S2 P1 100

Doing it in the opposite order

Suppliers LOJ SupParts
supno supno partno qty
===================
S1 S1 P1 100
S2 S2 P1 100
S3 NULL NULL NULL

Sybase does it one way, Oracle does it the other and Centura (nee
Gupta) lets you pick which one -- the worst of both non-standard
worlds! In SQL-92, you have a choice and can force the order of
execution. Either do the predicates after the join ...

SELECT *
FROM Supplier
LEFT OUTER JOIN
SupParts
ON Supplier.supno = SupParts.supno
WHERE qty < 200;

... or do it in the joining:

SELECT *
FROM Supplier
LEFT OUTER JOIN
SupParts
ON Supplier.supno = SupParts.supno
AND qty < 200;

Another problem is that you cannot show the same table as preserved and
unpreserved in the extended equality version, but it is easy in SQL-92.
For example to find the students who have taken Math 101 and might
have taken Math 102:

SELECT C1.student, C1.math, C2.math
FROM (SELECT * FROM Courses WHERE math = 101) AS C1
LEFT OUTER JOIN
(SELECT * FROM Courses WHERE math = 102) AS C2
ON C1.student = C2.student;

Jul 23 '05 #4

P: n/a
thilbert (th******@gmail.com) writes:
Thanks Debian, that did it. Is it then incorrect to use the WHERE
clause when using an outer join? I've looked at books on-line and
could not find a reference to using WHERE clauses with outer joins,
however they appear to be a typical part of inner joins.


Incorrect and incorrect, it has a different meaning. The FROM clause
lasts all the way to WHERE, so you have

FROM a LEFT JOIN b ON a.col = b.col

Then the WHERE is applied. But if you say

WHERE b.othercol = 3

you are effectively filter out the rows from a which did not have a
matching row in b.

If you say

FROM a LEFT JOIN b ON a.col = b.col AND b.othercol = 3

The condition of othercol becomes part of the join, so that for
rows where a.col = b.col but b.othercol = 2 you will get NULL
values for b.*.

You can also say:

FROM a LEFT JOIN b ON a.col = b.col
WHERE b.othercol = 3 OR b.col IS NULL

But this gives a different result. Here the rows where a.col = b.col
but b.othercol = 2 will be removed from the result set.

See also Celko treatise on the subject.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.