This question already has answers here:
SQL not displaying null values on a not equals query?
(5 answers)
Closed 20 hours ago.
Before select
Status could be:
X1, X2, NULL
SELECT * FROM surrtest t Where t.Status != „X2“
It’s deleting also rows where Status was null. But it shouldn’t.
So after query I’m only getting rows where status Is X1 but I also want the NULL rows.
Is it possible?
I don’t know if it’s possible. If not maybe there is a workaround where we replace the null values with empty strings? But I hope it is possible without changing the data.
This should work:
SELECT * FROM surrtest Where Status != ‘X2’ or Status is null
If that doesn’t work then there’s something weird going on with your database.
In most databases, a where clause evaluates to either true, false, or unknown. Any comparison with null will result in an unknown result. Since a where clause filters out all records that don't evaluate to true, you will not see records that evaluate to unknown, as well as false.
In your original query, the where clause was filtering out null records, because they evaluated to unknown. So, you have to add the extra part or Status is null to the where clause to include the null records.
Also, do NOT use or Status = null, since that will always evaluate to unknown, like mentioned before. You must use or Status is null.
Related
This question already has answers here:
postgresql NOT ILIKE clause does not include null string values
(2 answers)
Closed 7 months ago.
select * from test;
select * from test where name not in ('amtf');
Why?
As others have said, the problem here is, that you're comparing against a null value, so it returns nothing, because it considers it as false, and I'll go even further that even if you say where name <> 'admf' it wont work, and even if you add more rows it will ignore the null row, and it's not just in PostgreSQL, it doesn't work in SQL-Server or MySQL either.
As you can see in these db<>fiddles SQL-Server, MySQL, and PostgreSQL.
And the reason why it doesn't work is, because you're saying name should not equal a specific value. First name needs to be a value it should not be equal to a value, but when name is null it doesn't have a value, and even more for a side note null itself is not equal null.
The way to solve it is to convert it to a empty string by using COALESCE(name,'') or in SQL-Server you can also use isnull(name,''), and then compare it, or you can add or name is null which will return you all rows, including null, where name <> 'some value'.
Well the condition is right and the response for that as soo .
select * from test where name not in ('amtf');
your query is saying : give me all the records that the name Column is not in ('amtf').
you have 2 column's on is amtf and the other is null.
amtf will no be brought because of the condition and the other column is null -> no name set
I have recently started learning oracle and sql.
While learning I encountered a couple of queries which my friend was asked in an interview.
SELECT *
FROM Employees
WHERE NULL IS NULL;
this query yields all the rows in the Employees table.
As for as I have understood Oracle searches data in columns, so, NULL, is it treated as a column name here?
Am I correct when I say that Oracle searches for data in columns?
How come Oracle gives all the rows in this query?
In WHERE clause, is it not must that the left hand side of a condition be a COLUMN NAME?
Shouldn't it throw an error?
SELECT *
FROM Employees
WHERE NULL = NULL;
gives NO ROWS SELECTED.
Well, I understand that I can not compare a NULL value using operators except IS NULL and IS NOT NULL.
But why should it yield a result and not an error.
Could somebody explain me this.
Does Oracle treat NULL as a column as well as empty cells?
A where clause consists of conditional expressions. There is no requirement that a conditional expression consist of a column name on either side. In fact, although usually one or both sides are columns, it is not uncommon to have expressions that include:
subqueries
parameters
constants
scalar functions
One common instance is:
WHERE 1 = 1 AND . . .
This is a sign of automatically generated code. It is easier for some programmers to knit together conditions just by including AND <condition> but the clause needs an anchor. Hence, 1 = 1.
The way the WHERE clause works conceptually is that the clause is evaluated for each row produced by the FROM. If the clause evaluates to TRUE, then the row is kept in the result set (or for further processing). If it is FALSE or NULL, then the row is filtered out.
So, NULL IS NULL evaluates to TRUE, so all rows are kept. NULL = NULL evaluates to NULL, so no rows are kept.
NULL is NULL is always true, NULL = NULL is always false. Also, you aren't testing against any columns in either query (thus you are only going to get everything or nothing).
I've a Status column in a table which has 3 values - 'N/A' , 'Single' ,'Multiple'. Some rows have a NULL value for the Status column.
I need to pull up all the rows in which Status is not null and is not 'N/A'. Basically, I need all the rows whose status is "Single" or "Multiple".
I've been just reading up about NULL actually being equivalent to 'UNKNOWN'.
If I say
SELECT *
FROM t_userstatus
WHERE status <> 'N/A'
I get the results (All rows containing "Single" or "Multiple" only).
What I would like to know is that , does the above WHERE clause always exclude the rows having NULL values?Is that the expected behaviour?
What causes this to exclude null rows even though I've not explicitly specified it?
In my query,do I have to explicitly say status IS NOT NULL ?
I am relatively new to programming, any help is appreciated.
It is not normal behavior as N/A (Single & Multiple as well) is a string that is not related to NULL. Even though the NULL is evaluated to unknown and may not return, you should explicitly use IS NOT NULL.
SELECT [column_list] FROM t_userstatus
WHERE status IS NOT NULL AND status <> 'N/A'
I would also recommend you get in the habit of specifying a column list.
SQL uses three-valued logic: true, false, and unknown. Any comparison to null results in unknown.
So null <> 'N/A' evaluates to unknown. Since unknown is not true, that means the row gets excluded.
Yes, that is the normal behavior. A NULL value has no value, so it does not satisfy a WHERE condition. If you want to also include null values, you need to specify IS NOT NULL as well.
As others have said, null is generally not comparable. So, a status != 'N/A' comes back as false when status is null.
But what others haven't mentioned yet is that that is controlled through the Ansi_nulls setting. By default it is on and nulls are not comparable (as you state in the question, the principal behind this is that they are unknown so it is false that they are not necessarily N/A). But you can use
SET ANSI_NULLS OFF
To change this behavior in which case a null will be equal to a null and not equal to anything else. There is more details on MSDN here.
A bit non-obviously, SQL has three valued logic (true/false/unknown). Any direct comparison with NULL will result in the value unknown which in the WHERE clause is considered non-true. Your condition;
WHERE status <> 'N/A'
will in other words never match a null since NULL is never "not equal" to anything.
The only ways to match a NULL using a comparison is using the special null operations IS NULL or IS NOT NULL.
As a side note, life is naturally never quite that simple.
I am getting different results when I run the query with above clause but not able to understand why. can any one explain what is the difference between the two clauses.
The result of column = null is unknown (null), since it can't be known what null really is. If you want to test for null and get a boolean value back you need to use is null. So, `column` is null is the correct syntax to use.
A comparison to null always evaluates to false, so column = null evaluates to false as well as column != null, independently of the value of column. If you want to actually check whether a value is null, you have to use column is null.
In my table, I have a nullable bit column (legacy system...) and another developer recently made a change to a stored procedure to only show values where the bit column was not true (1). Because this is a nullable column, we noticed that if the column was NULL, the record was not being picked up. WHY is this?
Both the other developer and I agree that NULL <> 1... Is this a bug in SQL or was this designed this way? Seems like a design flaw.
Current Code:
(VoidedIndicator <> 1)
Proposed Fix:
(VoidedIndicator <> 1 OR VoidedIndicator IS NULL)
Clarification (By Jon Erickson)
VoidedIndicator is a nullable bit field so it can have the following values: NULL, 0, or 1
When a SQL statement is created with a where clause such as (VoidedIndicator <> 1) we only get records returned that have VoidedIndicator == 0, but we were expecting both VoidedIndicator == 0 and VoidedIndicator IS NULL. Why is this?
Lots of good answers, but let me give you a really concise version.
To SQL, Null does NOT mean "No value" it means "Unknown Value"
With that in mind, consider the answer to the question you are asking SQL in plain English.
Q: Is this unknown value not equal to 1?
A: I don't know, there is no way to tell without knowing the value.
Hence Null<>1 = Null
From the Wikipedia entry on NULL:
For example, a WHERE clause or
conditional statement might compare a
column's value with a constant. It is
often incorrectly assumed that a
missing value would be "less than" or
"not equal to" a constant if that
field contains Null, but, in fact,
such expressions return Unknown. An
example is below:
-- Rows where num is NULL will not be returned,
-- contrary to many users' expectations.
SELECT * FROM sometable WHERE num <> 1;
Basically, any comparison between NULL and something else, whether it's with = or <> will not be true.
As another reference, the MSDN T-SQL page on <> states:
Compares two expressions (a comparison
operator). When you compare nonnull
expressions, the result is TRUE if the
left operand is not equal to the right
operand; otherwise, the result is
FALSE. If either or both operands are
NULL, see SET ANSI_NULLS
(Transact-SQL).
The SET ANSI_NULLS page then states:
When SET ANSI_NULLS is ON, a SELECT
statement that uses WHERE column_name
= NULL returns zero rows even if there are null values in column_name. A
SELECT statement that uses WHERE
column_name <> NULL returns zero rows
even if there are nonnull values in
column_name.
...
When SET ANSI_NULLS is ON, all
comparisons against a null value
evaluate to UNKNOWN. When SET
ANSI_NULLS is OFF, comparisons of all
data against a null value evaluate to
TRUE if the data value is NULL.
It's not a bug.
NULL is not equal to anything, not even NULL (NULL = NULL returns FALSE).
Typically NULL values aren't indexed either. It's generally a bad idea to rely on a particular value or NULL. Depending on what you're storing in the column, you may be better off putting a dummy or sentinel value in rather than using NULL to indicate some meaning.
The other folks are correct that NULL <> 1 doesn't evaluate as true, therefore it doesn't satisfy the WHERE clause.
The proposed fix you describe is the best way of handling it:
(VoidedIndicator <> 1 OR VoidedIndicator IS NULL)
SQL-99 does have a predicate that helps in this case, called IS DISTINCT FROM:
(VoidedIndicator IS DISTINCT FROM 1)
This predicate would behave exactly the same as your proposed fix. Unfortunately, Microsoft SQL Server does not support IS DISTINCT FROM yet.
You can also: isnull(VoidedIndicator,1) <> 1
Because the WHERE clause only selects rows when the condition evaluates to true.
When one of the operands is NULL, the condition usually evaluates to UNKNOWN (approximately equivalent to NULL), and therefore is not true. It applies to both 'column = 1' and 'column <> 1'; if column is NULL, the search condition fails.
It is why you get told to avoid NULL columns whenever possible.
NULL <> 1 evaluates (theoretically) to "maybe", which means the record will not be returned.