gratuita - sql server management studio

¿Por qué SQL Server pierde un milisegundo?

Question

Tengo una tabla estructurada de esta manera:

CREATE TABLE [TESTTABLE]
(
[ID] [int] IDENTITY(1,1) NOT NULL,
[DateField] [datetime] NULL,
[StringField] [varchar](50),
[IntField] [int] NULL,
[BitField] [bit] NULL
)

Ejecuto el siguiente código:

BEGIN
INSERT INTO TESTTABLE (IntField, BitField, StringField, DateField)
VALUES (''1'', 1, ''hello'', {ts ''2009-04-03 15:41:27.378''});
SELECT SCOPE_IDENTITY()
END

Y entonces

select * from testtable with (NOLOCK)

y mi resultado muestra:

2009-04-03 15:41:27.*377*

para la columna de DateField .

¿Alguna idea de por qué parece que estoy perdiendo un milisegundo?

Answer 1

DATETIME no tiene una precisión infinita; probablemente esté utilizando un valor que no se puede representar con precisión con los bits disponibles.

Answer 2

El tipo de datetime SQL Server solo tiene una resolución de 1/300 de segundo (~ 3.33̅ ms), por lo que probablemente esté viendo un error de redondeo.

Consulte la referencia de MSDN Datetime SQL Server

Answer 3

He escuchado, pero no puedo encontrar una referencia oficial, que SQL Server almacena valores de fecha y hora con una precisión de 3 milisegundos.

Answer 4

SQL Server 2008 tiene mucha más precisión disponible. El tipo datetime2 almacenará con precisión valores como este: 2008-12-19 09: 31: 38.5670514 (precisión de 100 nanosegundos).

Referencia: hora y fecha y hora2 - Exploración de los nuevos tipos de datos de fecha / hora de SQL Server 2008

Answer 5

SQL Server solo almacena tiempo a aproximadamente 1/300 de un segundo. Estos siempre caen en los 0, 3 y 7 milisegundos. Por ejemplo, contar desde 0 en el incremento más pequeño:

00: 00: 00.000
00: 00: 00.003
00: 00: 00.007
00: 00: 00.010
00: 00: 00.013
...

Si necesita esa precisión de milisegundos, no hay una forma agradable de evitarlo. Las mejores opciones que he visto son almacenar el valor en campos numéricos personalizados y reconstruirlo cada vez que recupera el valor, o almacenarlo como una cadena de un formato conocido. Luego puede (opcionalmente) almacenar una fecha "aproximada" en el tipo de fecha nativa por el bien de la velocidad, pero introduce una complejidad conceptual que a menudo no se desea.

Answer 6

SQL Server solo tiene una precisión de 1/300 de segundo. Redondeará los valores al 1/300 más cercano.