SQLServerCentral / Discuss Content Posted by Amin Sobati / Article Discussions / Article Discussions by Author / The Pitfall of "Not Equal To" Operator in Queries! / Latest Posts

RE: The Pitfall of "Not Equal To" Operator in Queries!

Mike C — Mon, 03 Sep 2007 09:30:00 GMT

Worth noting that you can use use " select * " rather than " select 1 " or " select 12345 " for that matter.

I have a sneaking suspicion that using select * or select column could result in a bookmark lookup (or RID lookup) if your query includes columns that are non-clustered index columns or non-indexed columns (particularly in the WHERE clause or in joins). Select 1 or select 12345 shouldn't encounter that problem.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Alan Nicholas — Mon, 03 Sep 2007 03:40:00 GMT

By far the best solution as it relates most closely to the problem to be solved. I also prefer to use "EXISTS" rather than "IN" as you can't use "IN" efficiently if you have a composite key.

Worth noting that you can use use " select * " rather than " select 1 " or " select 12345 " for that matter.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Dave F-425609 — Tue, 28 Aug 2007 03:05:00 GMT

Wow. Tested it out and got the same results on mine. Will definitely bear that one in mind.

Thanks Mike!

RE: The Pitfall of "Not Equal To" Operator in Queries!

Mike C — Fri, 24 Aug 2007 17:56:00 GMT

No problem Dave. There is a difference between NOT EXISTS and NOT IN in some cases. Consider the following sample:

CREATE TABLE #test (id INT PRIMARY KEY, val VARCHAR(20));

INSERT INTO #test (id, val)SELECT 1, 'One'UNION SELECT 2, 'Two'UNION SELECT 3, 'Three'UNION SELECT 4, 'Four'UNION SELECT 5, 'Five';

CREATE TABLE #odd (id INT);

CREATE NONCLUSTERED INDEX ix1ON #odd(id);goWITH Num (n)AS( SELECT 1 UNION ALL SELECT n + 1 FROM Num WHERE n < 10000)INSERT INTO #odd (id)SELECT nFROM NumOPTION (MAXRECURSION 0)goSELECT *FROM #oddWHERE id NOT IN ( SELECT id FROM #test);goSELECT *FROM #oddWHERE NOT EXISTS ( SELECT id FROM #test WHERE #test.id = #odd.id);godrop table #test;drop table #odd;

On my computer it generates two different query plans. NOT EXISTS generates a query plan with a cost of 0.0614788. NOT IN generates a query plan with substantially higher cost of 0.121561. For small data sets in both tables the two queries generated the same query plan.

EXISTS is not just about breaking the loop, the SELECT in EXISTS uses a correlated subquery and can potentially take advantage of indexes on the table. In the best case this could result in efficient index seeks in the subquery, depending on which query plan SQL Server decides to go with.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Dave F-425609 — Fri, 24 Aug 2007 04:46:00 GMT

Cheers for that Mike. I'm coming from an Oracle background and in older editions OUTER JOIN=Full Table Scan.

I spent a bit more time looking into EXISTS after my post, and see what you mean. When you code EXISTS rather than IN the first time it hits success it breaks the analysis loop. This will be quicker if you are bringing back a huge number of rows from the subquery.

HOWEVER, by the same rational NOT EXISTS should not be quicker than NOT IN AS it would have to scan the entire result set to ensure a single occurence isn't present. Seems to follow...

RE: The Pitfall of "Not Equal To" Operator in Queries!

Mike C — Thu, 23 Aug 2007 09:46:00 GMT

Can anyone explain, in detail, why the outer join solution is faster than the Subquery solution in this example? Is the Exists method fastest of all?

It depends... One could be faster than another in different situations. It all boils down to which query plan SQL Server decides to use for a given query and a given set of data. As a side not, on SQL 2000 EXISTS tends to be faster than the IN operator. The explanation I've seen for this is that the IN operator needs to serialize the entire subquery before it can perform the comparison whereas the EXISTS operator does not. This behavior may be changed in SQL 2005, although I can't test it myself right now.

I've examined all three on a limited number of rows and the performance and the plans are identical. Why do you reckon one will be faster than the next with table growth?

Basically it's all up to the optimizer. It takes a lot of factors into consideration, including amount of data, when generating query plans. Changing the amount of data could change the query plan it chooses.

Correct me if I'm wrong, but when you do a left outer join the left part of the join has a full table scan. How is this faster than a subquery based on an index compared to another column based upon an index? Also, I can't see the difference in using EXISTS over a standard subquery as it still is effectively comparing values inside the EXISTS subquery?

Not necessarily a "full table scan", if it's properly indexed. You could end up with an (clustered) index scan, which would be more efficient in most cases. The rationale against the subquery versus EXISTS might be the same as for EXISTS versus IN. If SQL Server has to serialize the entire subquery before using it, it could be less efficient than using EXISTS.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Dave F-425609 — Thu, 23 Aug 2007 03:47:00 GMT

Sorry, let me rephrase the question:

Can anyone explain, in detail, why the outer join solution is faster than the Subquery solution in this example? Is the Exists method fastest of all?

I've examined all three on a limited number of rows and the performance and the plans are identical. Why do you reckon one will be faster than the next with table growth?

Also the LEFT JOIN thing looks nice, but how would you work it if (as it would seem a more reasonable requirement) you wanted the people who hadn't taken the SQL Server exam BUT HAD TAKEN another?

RE: The Pitfall of "Not Equal To" Operator in Queries!

Dave F-425609 — Thu, 23 Aug 2007 03:38:00 GMT

Can anyone explain, in detail, why the outer join solution is faster than the Subquery solution in this example? Is the Exists method fastest of all?

RE: The Pitfall of "Not Equal To" Operator in Queries!

john hill — Thu, 24 Aug 2006 18:12:00 GMT

If you are running SQL 2005 add the index below and see what plan the engine picks...

create nonclustered index IX_Exam_name on StudentExam(ExamName) include(StID)

SELECT s.* FROM Students s

JOIN StudentExam se

ON s.StID=se.StID

WHERE se.ExamName<>'SQL Server'

Here's the plan with the index for the original != query...

SELECT s.* FROM Students s JOIN StudentExam se ON s.StID=se.StID WHERE se.ExamName<>'SQL Server' |--Nested Loops(Inner Join, OUTER REFERENCES[se].[StID])) |--Index Seek(OBJECT[TestingDB].[dbo].[StudentExam].[ix_Exam_name] AS [se]), SEEK[se].[ExamName] < 'SQL Server' OR [se].[ExamName] > 'SQL Server') ORDERED FORWARD) |--Clustered Index Seek(OBJECT[TestingDB].[dbo].[Students].[PK__Students__345EC57D] AS [s]), SEEK[s].[StID]=[TestingDB].[dbo].[StudentExam].[StID] as [se].[StID]) ORDERED FORWARD)

RE: The Pitfall of "Not Equal To" Operator in Queries!

Amin Sobati — Thu, 24 Aug 2006 12:53:00 GMT

Thanks Eva,

All of students appear again! You have replaced the NULL with new value, but the logic is the same!

RE: The Pitfall of "Not Equal To" Operator in Queries!

evaleah — Thu, 24 Aug 2006 11:41:00 GMT

I didn't test it but is seems this should work and is a bit simpler:

SELECT s.* FROM Students sLEFT JOIN StudentExam se ON s.StID=se.StID WHERE ISNULL(se.ExamName,'') <> 'SQL Server'

This way any NULLs would be replaced with '' and therefore would not include 'SQL Server'.

Eva

RE: The Pitfall of "Not Equal To" Operator in Queries!

Mike C — Thu, 24 Aug 2006 07:56:00 GMT

"Actually comparisons of a NULL (or a non-NULL value) to a NULL results in UNKNOWN. Your point is taken though: The WHERE clause only returns results for rows comparisons that evaluate to TRUE. Comparisons that evaluate to FALSE or UNKNOWN are dropped from the results."

Well now we're splitting hairs!

Actually UNKNOWN represents a possible result of a logical comparison while NULL represents a missing/unknown value. There can be some confusion with the terminology, but NULL is actually not the same thing as UNKNOWN. Part of the confusion pops up because the word "unknown" is so often used in the definition of NULLs.

As an example (and to add to the confusion) consider the ANSI SQL:1999 standard which added a BOOLEAN data type to SQL. The BOOLEAN data type can hold one of three possible values: TRUE, FALSE and UNKNOWN: SQL three-valued logic and all, so far so good.

However it also has to be nullable, and to be consistent with the rest of the SQL model, NULL would have to indicate that you don't know whether the BOOLEAN column or variable is TRUE, FALSE or UNKNOWN. I'll give a quick example. Before someone points it out, I know this won't actually run on T-SQL... this is "pseudo-SQL" to illustrate what it might look like if ANSI BOOLEANs were implemented in T-SQL:

DECLARE @x BOOLEAN;DECLARE @y BOOLEAN;DECLARE @z BOOLEAN;SELECT @x = UNKNOWN; -- UNKNOWNSELECT @y = (10 < NULL); -- evaluates to UNKNOWNSELECT @z = NULL; -- NULL value

According to this example @x is equal to @y (they are both UNKNOWN). However, is @x equal to @z? We don't know the value of @z (is it TRUE, FALSE or UNKNOWN?), but we do know that @x is UNKNOWN. So is UNKNOWN the same as NULL? According to the SQL logical model the result of this comparison should be UNKNOWN, since we don't know if @z is TRUE, FALSE or UNKNOWN. According to SQL:1999 the answer could be TRUE since they say to treat UNKNOWN as equivalent to NULL.

To implement this correctly you actually have to re-work the SQL logical model from three-valued logic to four-valued logic everywhere The ANSI standard just says to treat UNKNOWNs the same as NULLs, which means you're starting to introduce inconsistent exceptions into the logical model rather than expanding it to accomodate four-valued logic.

As for the ANSI_NULLS setting, I highly recommend leaving it set to the ON position and using the IS NULL and IS NOT NULL operators (or CASE and COALESCE) to check for NULLs.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Amin Sobati — Thu, 24 Aug 2006 04:02:00 GMT

Thank Duray!

I agree! But I intended to show a mistranslation between what a human can mean and what a developer might write in TSQL! This really depends on the experience...

RE: The Pitfall of "Not Equal To" Operator in Queries!

Amin Sobati — Thu, 24 Aug 2006 02:30:00 GMT

Thanks indeed!

Certainly there can be variations depending on the experience of the developer. I have tried to BOLD a situation that can lead a developer to strange result. This is a real case and I have seen this mistake by some developers during the years on my IT career.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Ian Griffiths — Thu, 24 Aug 2006 02:18:00 GMT

DISTINCT is definitely a bad idea, performance-wise. Avoid if at all possible as it usually involves having to sort the result set and then scan through it, making lots of unnecessary overhead that can often be avoided.

RE: The Pitfall of "Not Equal To" Operator in Queries!

herb walles — Wed, 23 Aug 2006 18:14:00 GMT

The best way to think about it as "NOT EXISTS". This is the most logical human approach. You can always convert "not exists" into "left join"

select s.* from #students swhere not exists(select 1 from #StudentExam where stid=s.stid and Examname='SQL Server')

RE: The Pitfall of "Not Equal To" Operator in Queries!

Andy DBA — Wed, 23 Aug 2006 13:01:00 GMT

Well now we're splitting hairs! But, Mike is absolutely right. BOL defines the result for those comparisons to be "UNKNOWN". I've always considered NULL and UNKNOWN to mean the same thing and, interestingly enough, when you look up "unknown data" in BOL you get the "Null Values" overview page! There must be some subtle distinction though, otherwise the authors would have used NULL instead of UNKNOWN.

Sorry to take this thread so far off topic, but here's an interesting puzzler (while we're splitting hairs). I apologize if this topic has already been covered elsewhere.

I refrained from bringing up the ANSI_NULLS setting before, but it adds an interesting twist. According to BOL:

When SET ANSI_NULLS is ON, a comparison in which one or more of the expressions is NULL does not yield either TRUE or FALSE; it yields UNKNOWN.

and

When ANSI_NULLS is OFF, comparisons such as ColumnA = NULL return TRUE when ColumnA contains a null value and FALSE when ColumnA contains some value besides NULL. Also, a comparison of two expressions that have both evaluated to null values yields TRUE.

To confirm this, let's try some simple TSQL. Running the following produces what you'd expect (after reading BOL).

set ANSI_NULLS OFFdeclare @string varchar(25)set @string = 'TEST'if @string <> NULL --compare a variable to explicit NULLprint 'true'else print 'not true'

set @string = NULLif @string <> 'TEST' --compare a NULL variable to an explicit valueprint 'true'else print 'not true'

SELECT 'true' where @string <> 'TEST' --try a comparison in a select.

Results----truetrue

true

(1 row(s) affected)

set ANSI_NULLS ON and you getResults----not truenot true

(0 row(s) affected)

So far so good. It looks like all we have to do to retrieve Bob in Ehsan's example is set ANSI_NULLS OFF, right?

set ANSI_NULLS OFFSELECT * FROM Students s left outer join StudentExam se ON s.StID = se.StID WHERE se.ExamName<>'SQL Server'

Results----StID StName StID ExamName2 Anna 2 VB.NET2 Anna 2 C#.NET1 Jack 1 XML

(3 row(s) affected)

Huh? Where is Bob? Hmmm. Let's continue to use ANSI_NULLS OFF and look for ExamName = NULL

set ANSI_NULLS OFFSELECT * FROM Students s left outer join StudentExam se ON s.StID = se.StID WHERE se.ExamName=NULL

Results----StID StName StID ExamName3 Bob

(1 row(s) affected)

There's Bob!

WHAT'S GOING ON HERE? How come se.ExamName=NULL evaluates to TRUE but se.ExamName<>'SQL Server' doesn't (with ANSI_NULLS OFF).

Is it because the NULL is "virtual" in the left join. Let's try one more experiment:

Insert Students VALUES (4,NULL)

set ANSI_NULLS OFFSELECT * FROM STUDENTS WHERE StName = NULL

Results----StID StName4

(1 row(s) affected)

So far so good. Let's try the dratted "not equals to" operator that started this whole mess:

set ANSI_NULLS OFFSELECT * FROM STUDENTS WHERE StName <> 'Nobody'

Results----StID StName1 Jack2 Anna3 Bob

(3 row(s) affected)

WHAT? Where's the new row we just inserted? Must be that pesky "not equals to" operator. Double negative anyone?

set ANSI_NULLS OFFSELECT * FROM STUDENTS WHERE not StName <> NULL

Results----StID StName4

(1 row(s) affected)

Sure, there it is. So it must not be the "not equals to" operator?

My advice to anyone still reading: BE VERY CAREFUL WITH "SET ANSI_NULLS OFF" AND ANY COMPARISONS WITH NULLS AND BE ESPECIALLY CAREFUL WITH THE <> OPERATOR AND NULLS.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Ken Shapley — Wed, 23 Aug 2006 12:44:00 GMT

y <> x and x <> z then y could possibly = z

This is not a pitfall, but merely an oversight sometimes.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Antares686 — Wed, 23 Aug 2006 12:11:00 GMT

Sorry, still a good contribution thou.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Antares686 — Wed, 23 Aug 2006 12:10:00 GMT

The issue isn't the use of <> or != (which I prefer the later). The pitfall is in presumption of the data and our understanding of the question.

The question being asked that fits your final solution is

"Which students haven't taken the %s exam?"

In your first solution the question is more to the effect

"List the students who have taken exams each time but do not show the times the %s exam was taken."

If you had used left join

"List the students who have taken exams each time but do not show the times the %s exam was taken and make sure to show those who haven't taken an exam at all at least once."

The biggest issue with generating data for reports is always making sure you understand the intended result fully and structure the query correctly. Some syntax is more prone than others to creating the structure that represents the question you want to pose. As always thou there can be dozens of ways to ask the same question and get the correct answer, then it is a matter of most effective way.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Tim Chapman-218780 — Wed, 23 Aug 2006 11:21:00 GMT

I 100% agree with the comment made by Duray AKAR. The query listed will never retrieve the results "the students that has not taken the "SQL Server" exam...will only return those results for students that have taken an exam that is not SQL Server. Very good point Duray AKAR.

Tim

RE: The Pitfall of "Not Equal To" Operator in Queries!

Mike C — Wed, 23 Aug 2006 10:04:00 GMT

"ANY COMPARISON OF A NON-NULL TO A NULL IS NULL"

Actually comparisons of a NULL (or a non-NULL value) to a NULL results in UNKNOWN. Your point is taken though: The WHERE clause only returns results for rows comparisons that evaluate to TRUE. Comparisons that evaluate to FALSE or UNKNOWN are dropped from the results.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Scalability Doug — Wed, 23 Aug 2006 09:58:00 GMT

This is a classic example of an exclusion list and point sout the limitiations of the inequality operator. What is presented in this example is that members in one are are to be excluded from from others. (Note that the example is students who have not taken the SQL Server exam. Bob gets omitted. Does he get omitted because he has not taken an exam?). And as the author points out, "you can simply use a subquery to build the list of students who have taken SQL Server exam" and then build your exclusion using the NOT EXISTS clause:

SELECT s.*FROM Students swhere not exists ( select stid from studentExam se where s.StID = stid and examname = 'SQL Server' )

RE: The Pitfall of "Not Equal To" Operator in Queries!

YSLGuru — Wed, 23 Aug 2006 09:38:00 GMT

Regardless of the material, a thanks to Amin Sobati for writing it. I often wonder why any of these contributing authors would take the time to produce material when too often that maetrial recieves not just constructive criticism but out right crude & rude behaivor. Is it necessary to sue workds like 'stupid' in a constructive criticism?

RE: The Pitfall of "Not Equal To" Operator in Queries!

Dennis D. Allen — Wed, 23 Aug 2006 09:23:00 GMT

The question is one of membership, and the IN clause seems to be a very clear way to pose that question. After proper indexing, it yields the same query plan as the methods proposed, but in a more understandable query./* Students that have taken the SQL Server test */SELECT s.*FROM dbo.Students AS sWHERE s.StID IN (SELECT StID FROM dbo.StudentExam WHERE ExamName = 'SQL Server')/* Students that have not taken the SQL Server test */SELECT s.*FROM dbo.Students AS sWHERE s.StID NOT IN (SELECT StID FROM dbo.StudentExam WHERE ExamName = 'SQL Server')

RE: The Pitfall of "Not Equal To" Operator in Queries!

Andy DBA — Wed, 23 Aug 2006 09:20:00 GMT

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.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Donald Eberhart — Wed, 23 Aug 2006 08:56:00 GMT

Ehsan,

Bob does not show up in your results.

Regards,

Don

RE: The Pitfall of "Not Equal To" Operator in Queries!

Dan Knowlton — Wed, 23 Aug 2006 08:50:00 GMT

The point of the article is excellent. It reinforces the fact that we as SQL programmers need to be careful and be sure of the results that our queries will return. It's a reminder to us veterans to not be complacent and whip out some crappy code when we're in a hurry. It's a nice lesson for new programmers who could easily fall into the trap of using the "Not Equal To" operator when they should really be using a sub-query or outer join.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Jason Hopkins — Wed, 23 Aug 2006 08:36:00 GMT

Subqueries are usually a bad idea as a first option- how about a left join, perhaps with a DISTINCT in the SELECT clause?

RE: The Pitfall of "Not Equal To" Operator in Queries!

Mike C — Wed, 23 Aug 2006 07:39:00 GMT

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)GOCREATE CLUSTERED INDEX IX_StudentsON Students (StName)GOINSERT Students VALUES (1,'Jack')INSERT Students VALUES (2,'Anna')INSERT Students VALUES (3,'Bob')GOCREATE TABLE StudentExam (StID INT NOT NULL,ExamName VARCHAR(50) NOT NULL,PRIMARY KEY (StID, ExamName))GOINSERT 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.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Tatsu — Wed, 23 Aug 2006 07:19:00 GMT

Here is how I would answer the original question:

select s.* from Students swhere 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.

RE: The Pitfall of "Not Equal To" Operator in Queries!

Duray AKAR — Wed, 23 Aug 2006 07:10:00 GMT

SELECT s.* FROM Students sJOIN StudentExam seON s.StID=se.StIDWHERE 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....

RE: The Pitfall of "Not Equal To" Operator in Queries!

Vladan — Wed, 23 Aug 2006 05:14:00 GMT

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.StIDWHERE se.StID IS NULL

I would prefer to use one of these variants:variant 1) - simplestSELECT 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 duplicatesSELECT s.* FROM Students s LEFT JOIN (SELECT DISTINCT StID FROM StudentExam WHERE ExamName='SQL Server') se ON s.StID=se.StIDWHERE 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.

RE: The Pitfall of "Not Equal To" Operator in Queries!

nileshsane — Wed, 23 Aug 2006 04:51:00 GMT

Nice article.

Another way of writing the same, for those who prefer the old convention (I dont recommend it).

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

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

where s.StID !=se.StID

The Pitfall of "Not Equal To" Operator in Queries!

Yaroslav Pentsarskyy-353753 — Wed, 16 Aug 2006 09:25:00 GMT

Comments posted to this topic are about the content posted at temp