Подтвердить что ты не робот

Почему SQL Server потерял миллисекунду?

У меня есть таблица, структурированная следующим образом:

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

Я выполняю следующий код:

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

   SELECT SCOPE_IDENTITY()  
END

И затем

select * from testtable with (NOLOCK)

и мой результат показывает:

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

для столбца DateField.

Любые идеи, почему я, кажется, теряю миллисекунду?

4b9b3361

Ответ 1

SQL Server хранит время примерно до 1/300 секунды. Они всегда падают на 0, 3 и 7 миллисекунд. Например. подсчитывая от 0 в наименьшем приращении:

00: 00: 00,000
00: 00: 00,003
00: 00: 00,007
00: 00: 00,010
00: 00: 00,013
...

Если вам нужна эта миллисекундная точность, там нет приятного пути. Лучшие варианты, которые я видел, - это хранить значение в полях пользовательских номеров и перестраивать его каждый раз, когда вы извлекаете значение, или хранить его как строку известного формата. Затем вы можете (необязательно) сохранить "приблизительную" дату в родном типе даты для скорости, но она вводит концептуальную сложность, которая часто не нужна.

Ответ 3

Тип SQL Server datetime имеет только 1/300 секунды (~ 3,33 мс), поэтому вы вероятно, видя ошибку округления.

См. Ссылка MSDN Datetime SQL Server

Ответ 4

SQL Server работает только с точностью до 1/300 секунды. Он будет округлять значения до ближайшего 1/300-го.

Ответ 5

DATETIME не имеет бесконечной точности - вы, вероятно, используете значение, которое не может быть точно представлено доступными битами.

Ответ 6

Я слышал, но не могу найти официальную ссылку, что SQL Server хранит значения datetime с точностью до 3 миллисекунд.