Início / dba / Perguntas / 341474
Accepted
crichavin
Asked: 2024-08-07 09:43:56 +0800 CST

Por que é retornado um valor de data e hora que corresponde ao valor do predicado ao usar maior que comparação

  • 772

Quero encontrar registros maiores que o tempo fornecido em meu predicado, que vem de um aplicativo Web C# no qual existe apenas type DateTime. No entanto, o SQL Server está retornando uma linha igual ao valor do predicado fornecido. Por que está fazendo isso? A ShipDateTimeUTCcoluna é um datetimetipo de dados.

DECLARE @p__linq__1 datetime2(7) = '2024-08-07 00:14:11.3630000';

SELECT 
    [OrderHeaderId],
    Id,
    [ShipDateTimeUTC]
FROM  
    [dbo].[ShippingContainerHeader]
WHERE 
    [ShipDateTimeUTC] > @p__linq__1;

Aqui estão os resultados onde você pode ver que ShipDateTimeUTC corresponde ao valor do predicado. Eu não quero que isso seja incluído. Por que está sendo incluído nos resultados?

resultados SQL

sql-server

2 respostas

  1. Best Answer

    Você obterá esse comportamento se ShipDateTimeUTCfor um datetimetipo de dados.

    datetime2(7)tem precedência de tipo de dados maior do datetimeque você esperaria que a coluna fosse convertida implicitamente paradatetime2(7)

    Há um comportamento irritante (†) "por design" que, ao converter para datetime2(7)valores como, 2024-08-07 00:14:11.363é convertido para 2024-08-07 00:14:11.3633333(e 2024-08-07 00:14:11.367seria convertido para 2024-08-07 00:14:11.3666667)

    Após esta conversão implícita 2024-08-07 00:14:11.3633333ser maior que 2024-08-07 00:14:11.3630000.

    Você deve alterar o tipo de dados to @p__linq__1para datetimecorresponder à coluna, pois as conversões implícitas na WHEREcláusula devem ser evitadas de qualquer maneira.

    Inicialmente pensei que, se por algum motivo você estivesse preso datetime2(7), precisaria alterar o valor a ser usado 2024-08-07 00:14:11.3633333para levar isso em consideração. No entanto, o comportamento de comparação implícita com tipos de dados mistos, na verdade, opera de maneira diferente do que com tipos de dados convertidos explicitamente. Violino

    Todos os itens abaixo usam uma busca de índice, apesar do CASTs

    DECLARE @T TABLE (DT DATETIME PRIMARY KEY)

INSERT @T values ('2024-08-07 00:14:11.363')

--Returns 0 rows as expected from above
SELECT *
FROM @T
WHERE DT = CAST('2024-08-07 00:14:11.3630000' AS datetime2(7))

--Returns 0 rows - unexpected
SELECT *
FROM @T
WHERE DT = CAST('2024-08-07 00:14:11.3633333' AS datetime2(7))

--Returns 1 rows so explicit cast to datetime2 helps
SELECT *
FROM @T
WHERE CAST(DT AS datetime2(7)) = CAST('2024-08-07 00:14:11.3633333' AS datetime2(7))

--Returns 1 rows - not sure why casting the column to the datatype it already has helps!
SELECT *
FROM @T
WHERE CAST(DT AS datetime) = CAST('2024-08-07 00:14:11.3633333' AS datetime2(7))

    † A justificativa para este comportamento ( novo no nível de compatibilidade 130 ) é

    Precisão aprimorada ao converter para tipos de data/hora com maior precisão. Esteja ciente de que os valores de data e hora são armazenados como ticks que representam 1/300 de segundo. Os tipos mais recentes de hora e data e hora2 armazenam um número discreto de dígitos, onde o número de dígitos corresponde à precisão.

    Eu verifiquei os livros on-line do SQL Server 2000 e isso diz paradatetime

    Dados de data e hora de 1º de janeiro de 1753 a 31 de dezembro de 9999, com precisão de um trezentos centésimos de segundo (equivalente a 3,33 milissegundos ou 0,00333 segundos). Os valores são arredondados para incrementos de 0,000, 0,003 ou 0,007 segundos

    Portanto, este comportamento é consistente com o que sempre foi documentado, embora possa causar resultados potencialmente inesperados.

    • 6

  2. Misturar tipos de dados é uma má ideia. Se o tipo de banco de dados for datetime, a variável deverá ser datetime.

    O problema que você tem é que a conversão implícita de datetime para datetime2, para ShipDateTimeUTC, produzirá 2024-08-07 00:14:11.3633333 que é maior que 2024-08-07 00:14:11.3630000.

    • 4

relate perguntas