Eu sei que não é uma boa prática ter uma conversão de tipo implícita. Mas esse é um comportamento realmente inesperado quando um valor mais baixo pode de repente se tornar mais alto.
declare @LastSelectedDate DATETIME = '2021-11-09 13:52:29.187'
declare @LastSelectedDate_1 DATETIME2(7) = '2021-11-09 13:52:29.1866667'
SELECT IIF(@LastSelectedDate_1 > CAST(@LastSelectedDate AS DATETIME2), 1, 0)
SELECT IIF(@LastSelectedDate_1 > @LastSelectedDate, 1, 0)
Isso é um bug ou estou perdendo alguma coisa? Estou usando o sql server 2016.
sim, não tenho ideia de por que eles pensaram que esse comportamento seria uma boa ideia.
É "por design" em vez de um bug
Especificamente
datetime
, esse final3
é tratado como se fosse3
recorrente edatetime
o final7
é tratado como se fosse6
recorrente.datetime
esse fim0
não são afetados. (estas eram as únicas possibilidades para esse tipo de dados, pois tem 300 "tiques" por segundo)Restringir o nível de compatibilidade para resolver esse único problema parece uma solução de marreta. Você pode convertê-lo explicitamente
datetime2(3)
para evitar issoDevoluções