|
Что за особенность преобразования типов datetime2 и datetime
|
|||
---|---|---|---|
#18+
Всем привет! Подскажите, почему если в дате 3 значимых числа после точки, то преобразование к datetime2 и datetime дает неодинаковый результат? if cast('2018-12-20 15:35:36.5230000' as datetime2) <> cast('20181220 15:35:36.523' as datetime) print '1' if cast('2018-12-20 15:35:36.5200000' as datetime2) <> cast('20181220 15:35:36.52' as datetime) print '1' СКЛ-сервер 2017 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 18:28 |
|
Что за особенность преобразования типов datetime2 и datetime
|
|||
---|---|---|---|
#18+
Патамушта точность этих типов данных разная. Чти справку. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 19:00 |
|
Что за особенность преобразования типов datetime2 и datetime
|
|||
---|---|---|---|
#18+
Диам, сервер не хранит '2018-12-20 15:35:36.5230000' или '20181220 15:35:36.523' сервер хранит int, а в int ваши строки это большие разницы ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 05:55 |
|
Что за особенность преобразования типов datetime2 и datetime
|
|||
---|---|---|---|
#18+
спасибо ответившим. Поиск причины возник из-за косяка, который начался в MS Access после перехода на MS SQL2017. Если форма построена на основе родного DAO-рекордсета, то родная акцессная команда обновления записи на форме приходит к СКЛ-серверу с блоком WHERE, где указаны все поля обновляемой таблицы. И если среди этих полей есть поле с типом datetime, то СКЛ-сервер делает преобразование значения, передаваемого в блоке WHERE в тип datetime2. И вот, если в таблице сохранено значение с 3 знаками после точки, то такая запись не будет обновлена. И Акцесс на попытку обновления записи получит уведомление об ошибке "Запись была изменена другим пользователем". Решение - отвязывать форму от DAO-рекордсета. Временное решение - в таблицах, где дата сохраняется с точностью до миллисекунд, обновить значения, чтобы срезать миллисекунды. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2021, 23:35 |
|
Что за особенность преобразования типов datetime2 и datetime
|
|||
---|---|---|---|
#18+
PizzaPizza Диам, сервер не хранит '2018-12-20 15:35:36.5230000' или '20181220 15:35:36.523' сервер хранит int, а в int ваши строки это большие разницы с каких это пор datetime стал int-ом ? "физически", - это тип с фиксированной запятой ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2021, 23:48 |
|
Что за особенность преобразования типов datetime2 и datetime
|
|||
---|---|---|---|
#18+
court, насколько интернет не врет, актуального описания от МС нет, но есть понимание, что хранится дата в виде двух интов (в одном 8 bytes), что можно конечно охарактеризовать как число с фиксированной запятой инт,инт https://www.sqlshack.com/sql-server-datetime-data-type-considerations-and-limitations/ ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2021, 23:58 |
|
Что за особенность преобразования типов datetime2 и datetime
|
|||
---|---|---|---|
#18+
PS. хотя он сравнивает as a floating-point value. И это тоже годится, так как 8 бит (инт/float/double) есть 8 бит и неотличимы при хранении, разница только в описании типа. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2021, 00:09 |
|
Что за особенность преобразования типов datetime2 и datetime
|
|||
---|---|---|---|
#18+
Диам, конвертация - это одно, а проверка на потерю обновлений - другое. В твоем случае второе не проходит из-за ошибок первого. Акцесс считает, что такой записи, какую он получил, в базе больше нет. По части второго при работе с sql server - ты вообще такие слова - timestamp или rowversion встречал когда-нибудь? заведи в редактируемой таблице поле типа rowversion (старый акцесс такого типа может и не знать, он был про timestamp осведомлен), и жизнь с обновлениями, может быть, наладится. (То есть, в конце-концов наладится, но может быть еще какие магические телодвижения с бубном потребуются...) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2021, 00:12 |
|
|
start [/forum/topic.php?fid=46&msg=40036479&tid=1685204]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
180ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 280ms |
0 / 0 |