No igual <>!= operador en NULL

NULL no tiene valor, por lo que no se puede comparar usando los operadores de valor escalar.

En otras palabras, ningún valor puede ser igual a (o no igual a) NULL porque NULL no tiene valor.

Por lo tanto, SQL tiene especial ES NULL y NO ES NULL predicados para tratar con NULL.

Tenga en cuenta que este comportamiento es el comportamiento predeterminado (ANSI).

Si usted:

 SET ANSI_NULLS OFF

Http://msdn.microsoft.com/en-us/library/ms188048.aspx

Obtendrás resultados diferentes.

SET ANSI_NULLS OFF aparentemente se irá en el futuro...

En SQL, cualquier cosa que evalúes / calcules con NULL resulta en UNKNOWN

Esta es la razón por la que SELECT * FROM MyTable WHERE MyColumn != NULL o SELECT * FROM MyTable WHERE MyColumn <> NULL te da 0 resultados.

Para proporcionar una comprobación de los valores NULL, se proporciona la función isNull.

Además, puede usar el operador IS como usó en la tercera consulta.

Espero que esto ayude.

La única prueba para NULL es ES NULL o NO ES NULL. Probar la igualdad no tiene sentido porque, por definición, uno no sabe cuál es el valor.

Aquí hay un artículo de wikipedia para leer:

Https://en.wikipedia.org/wiki/Null_ (SQL)

Usamos

SELECT * FROM MyTable WHERE ISNULL(MyColumn, ' ') = ' ';

Para devolver todas las filas donde Micolumna es NULO o todas las filas donde Micolumna es una cadena vacía. Para muchos de los "usuarios finales", el problema de cadena NULA vs.vacía es una distinción sin necesidad y punto de confusión.

NULL No se puede comparar con ningún valor usando los operadores de comparación. NULL = NULL es false. Null no es un valor. El operador IS está especialmente diseñado para manejar comparaciones NULAS.

Simplemente no veo la razón funcional y sin fisuras para que los valores nulos no sean comparables a otros valores u otros valores nulos, porque podemos compararlos claramente y decir que son iguales o no en nuestro contexto. Es gracioso. Solo por algunas conclusiones lógicas y consistencia necesitamos molestarnos constantemente con ello. No es funcional, hacerlo más funcional y dejar a los filósofos y científicos para concluir si es consistente o no y tiene "lógica universal". :) Alguien puede decir que es debido a los índices o algo más, dudo que esas cosas no se puedan hacer para soportar valores nulos. Es lo mismo que comparar dos vasos vacíos, uno es vaso de vid y otro es vaso de cerveza, no estamos comparando los tipos de objetos sino los valores que contienen, lo mismo que podrías comparar int y varchar, con null es aún más fácil, no es nada y lo que dos nada tienen en común, son los mismos, claramente comparables por mí y por todos los demás que escriben sql, porque constantemente rompiendo esa lógica comparándolos de maneras extrañas debido a algunos estándares ANSI. ¿Por qué no usar el poder de la computadora para hacerlo por nosotros y dudo que ralentizaría las cosas si todo lo relacionado se construye con eso en mente? "No es null no es nada", no es Apple es apfel, vamos... Funcionalmente es tu amigo y también hay lógica aquí. Al final, lo único que importa es la funcionalidad y el uso de nulls de esa manera trae más o menos funcionalidad y facilidad de uso. Es más útil?

Considere este código:

SELECT CASE WHEN NOT (1 = null or (1 is null and null is null)) THEN 1 ELSE 0 end

¿Cuántos de ustedes saben qué devolverá este código? Con o sin NO devuelve 0. Para mí eso no es funcional y es confuso. En c# todo es como debería ser, las operaciones de comparación devuelven valor, lógicamente esto también produce valor, porque si no lo hizo no hay nada que comparar (excepto. nada :) ). Simplemente "dijeron": cualquier cosa en comparación con null" devuelve " 0 y eso crea muchas soluciones y dolores de cabeza.

Este es el código que me trajo aquí:

where a != b OR (a is null and b IS not null) OR (a IS not null and b IS null)

Solo necesito comparar si dos campos (en donde) tienen valores diferentes, podría usar la función, pero...

Vieja pregunta, pero la siguiente podría ofrecer algunos detalles más.

null representa ningún valor o un valor desconocido. No especifica por qué no hay valor, lo que puede conducir a cierta ambigüedad.

Supongamos que ejecuta una consulta como esta:

SELECT *
FROM orders
WHERE delivered=ordered;

Es decir, está buscando filas donde las fechas ordered y delivered son las mismas.

¿Qué se espera cuando una o ambas columnas son null?

Debido a que al menos una de las fechas es desconocida, no puede espere decir que las 2 fechas son las mismas. Este es también el caso cuando ambas fechas son desconocidas: ¿cómo pueden ser iguales si ni siquiera sabemos lo que son?

Por esta razón, cualquier expresión que trate a null como un valor debe fallar. En este caso, no coincidirá. Este también es el caso si intenta lo siguiente:

SELECT *
FROM orders
WHERE delivered<>ordered;

Nuevamente, cómo podemos decir que dos valores son no iguales si no sabemos cuáles son.

SQL tiene una prueba específica de falta valores:

IS NULL

Específicamente no es comparando valores , sino que busca valores faltantes .

Finalmente, en lo que respecta al operador !=, que yo sepa, en realidad no está en ninguno de los estándares, pero está muy ampliamente apoyado. Se agregó para hacer que los programadores de algunos idiomas se sientan más como en casa. Francamente, si un programador tiene dificultad para recordar qué lenguaje está usando, está mal empezado.

NULL no es anything...it se desconoce. NULL no equivale a nada. Es por eso que debe usar la frase mágica IS NULL en lugar de = NULL en sus consultas SQL

Puedes referirte a esto: http://weblogs.sqlteam.com/markc/archive/2009/06/08/60929.aspx

Me gustaría sugerir este código que hice para encontrar si hay un cambio en un valor, i siendo el nuevo valor y d siendo el viejo (aunque el orden no importa). Para el caso, un cambio de valor en null o viceversa, es un cambio, pero de nulo a nulo no es (por supuesto, de valor a otro valor es un cambio, pero de valor para el mismo no es).

CREATE FUNCTION [dbo].[ufn_equal_with_nulls]
(
    @i sql_variant,
    @d sql_variant
)
RETURNS bit
AS
BEGIN
    DECLARE @in bit = 0, @dn bit = 0
    if @i is null set @in = 1
    if @d is null set @dn = 1

    if @in <> @dn
        return 0

    if @in = 1 and @dn = 1
        return 1

    if @in = 0 and @dn = 0 and @i = @d
        return 1

    return 0

END

Para usar esta función, puede

declare @tmp table (a int, b int)
insert into @tmp values
(1,1),
(1,2),
(1,null),
(null,1),
(null,null)

---- in select ----
select *, [dbo].[ufn_equal_with_nulls](a,b) as [=] from @tmp

---- where equal ----
select *,'equal' as [Predicate] from @tmp where  [dbo].[ufn_equal_with_nulls](a,b) = 1

---- where not equal ----
select *,'not equal' as [Predicate] from @tmp where  [dbo].[ufn_equal_with_nulls](a,b) = 0

Los resultados son:

---- in select ----
a   b   =
1   1   1
1   2   0
1   NULL    0
NULL    1   0
NULL    NULL    1

---- where equal ----
1   1   equal
NULL    NULL    equal

---- where not equal ----
1   2   not equal
1   NULL    not equal
NULL    1   not equal

El uso de sql_variant lo hace compatible para variedad de tipos