SELECT s.*, se.* FROM Students s ,

(SELECT * FROM StudentExam WHERE ExamName='SQL Server') se

where s.StID !=se.StID

I'm not sure why one would use precisely this form... IMHO it is more complicated than necessary, and the complication does not bring any advantages :
SELECT s.* FROM Students s
LEFT JOIN (SELECT StID FROM StudentExam WHERE ExamName='SQL Server') se ON s.StID=se.StID
WHERE se.StID IS NULL

I would prefer to use one of these variants:
variant 1) - simplest
SELECT s.* FROM Students s
LEFT JOIN StudentExam E ON E.stID=s.stID AND ExamName='SQL Server'
WHERE E.StID IS NULL

variant 2) - to avoid possible duplicates
SELECT s.* FROM Students s
LEFT JOIN (SELECT DISTINCT StID FROM StudentExam WHERE ExamName='SQL Server') se
  ON s.StID=se.StID
WHERE se.StID IS NULL

Is there any reason why to use the code as shown in the article?

Yes I know that if condition is NOT, there can't be any duplicities because I only take those that don't have any corresponding rows... but generally when speaking about similar JOINs, duplicities are things that can cause problems - so I thought I'll mention that... also because it is the main reason why/when I would use the derived table. Otherwise, variant 1 should be good enough.

SELECT s.* FROM Students s
JOIN StudentExam se
ON s.StID=se.StID
WHERE se.ExamName<>'SQL Server'

is definitely NOT the query to be used to retrieve:
The students that has not taken "SQL Server" exam
in the given data architecture...

It is a query to get:
The students that has taken an exam that is NOT "SQL Server".

And it successfully delivers the expected result.
What if there are students that has not taken ANY exams ?

So, I don't think this is a pitfall of "<>" operator at all !

The query should be in the final form that the author suggests to begin with....

Here is how I would answer the original question:

select s.* from Students s
where not exists
  (select 1 from StudentExam se
   where se.ExamName = 'SQL Server'
     and s.StID=se.StID)

While I have seen some performance issues when using an in (select ...) clause exists seems to work great.

Here's your sample tables with indexes on them.  Should eliminate the table scans in your query plan.

CREATE TABLE Students (
StID INT NOT NULL PRIMARY KEY NONCLUSTERED,
StName NVARCHAR(50) NOT NULL)
GO

CREATE CLUSTERED INDEX IX_Students
ON Students (StName)
GO

INSERT Students VALUES (1,'Jack')
INSERT Students VALUES (2,'Anna')
INSERT Students VALUES (3,'Bob')
GO

CREATE TABLE StudentExam (
StID INT NOT NULL,
ExamName VARCHAR(50) NOT NULL,
PRIMARY KEY (StID, ExamName))
GO

INSERT StudentExam VALUES (1,'SQL Server')
INSERT StudentExam VALUES (2,'VB.NET')
INSERT StudentExam VALUES (2,'C#.NET')
INSERT StudentExam VALUES (1,'XML')
GO

Then run your query and see if it comes back with a more efficient query plan.

Ehsan,

Bob does not show up in your results.

Regards,

Don

If you "Check out" Ehsan's example you'll find Jack is retrieved even though he did take the class and, even though Bob did not take the class, he is not retrieved.

"Stupid people compose a query and expect other unusual result "

Vladan's variant 1 example returns the correct results because the ExamName criteria is in the join, NOT the where clause.  This causes all StudentExam columns in the join's result set to be NULL for students without a 'SQL Server' exam.  The example then filters out the non-null rows from the result set with the where clause.

In Ehsan's example, putting the ExamName <> 'SQL Server' criteria in the where clause filters out all rows where ExamName = 'SQL Server'.  This allows Jack to still be retrieved because there is a row in the result set where ExamName <> 'SQL Server'.

This also causes Bob to be filtered out because all of the StudentExam columns in the result set are NULL for Bob (who didn't take any exams).  ANY COMPARISON OF A NON-NULL TO A NULL IS NULL.  So, ExamName <> 'SQL Server' evaluates to NULL even though it seems like it should evaluate to TRUE and the row is filtered out.  Bye bye Bob.

There's more good stuff in BOL on NULL comparisons in the "Comparison Search Conditions" subtopic under "null values" in the index.

Finally, Ehsan's example will return duplicates for students taking more than one exam other than 'SQL Server'.  The beauty of Vladan's example is that you only get one row in the result set for each row in the "left" table without a match in the "right" table so "select distinct" is not required.