Вход | Регистрация



Что такое смещение дат и зачем оно вообще нужно?

Что такое смещение дат и зачем оно вообще нужно?
Я
   И Р
 
30.10.18 - 19:13
"Ошибка инициализации модуля: ВнешняяОбработка.ВосстановлениеНомерации.МодульОбъекта
по причине:
{ВнешняяОбработка.ВосстановлениеНомерации.МодульОбъекта(22)}: Ошибка при вызове метода контекста (НайтиПоНомеру)

по причине:
Ошибка в значении типа 'Дата'
Дата '31.12.0001 23:59:59' не может быть записана в базу данных на MS SQL Server с нулевым смещением дат"

Что такое смещение дат и зачем оно вообще нужно?
 
 
   palsergeich
 
1 - 30.10.18 - 19:16
   dmpl
 
2 - 30.10.18 - 21:32
(0) А зачем такую дату записывать?
   vde69
 
3 - 30.10.18 - 23:10
смещение дат сделано ради экономии места...
   palsergeich
 
4 - 31.10.18 - 00:10
В диалоге "Добавление информационной базы/группы" при создании информационной базы на СУБД Microsoft SQL Server доступна установка параметра "Смещение дат". Раздел содержит дополнительную информацию о влиянии значения этого параметра на работу информационной базы.

Причина введения параметра
Необходимость установки данного параметра обусловлена отличием диапазонов значений дат, представимых объектом типа Дата в "1С:Предприятии 8" и представимых в полях типа DATETIME таблиц Microsoft SQL Server.

В "1С:Предприятии 8" даты могут принимать значения с 00:00:00 1 января 1 года по 23:59:59 31 декабря 9999 года, причем, записаны в базу данных могут быть даты с 00:00:00 1 января 1 года по 23:59:59 31 декабря 3999 года. Важно, что:

дата 00:00:00 1 января 1 года считается нулевой датой и значением по умолчанию для данных типа Дата;

даты с 00:00:00 1 января 1 года по 23:59:59 1 января 1 года считаются временем без даты.

В полях типа DATETIME таблиц Microsoft SQL Server могут быть представлены даты с 00:00:00 1 января 1753 года по 23:59:59 31 декабря 9999 года.

Таким образом, даты из с 00:00:00 1 января 1 года по 23:59:59 31 декабря 1752 года из "1С:Предприятия" невозможно записать без искажения в базу данных на Microsoft SQL Server.

Описание параметра
Для обхода этой особенности введен параметр информационной базы "Смещение дат".

Данный параметр определяет число лет, которое будет прибавляться к датам при их сохранении в базе данных Microsoft SQL Server и вычитаться при их извлечении. Он может принимать значения 0 или 2000.

Если установить смещение дат 0, то:

при записи дат в диапазоне с 00:00:00 1 января 1 года по 23:59:59 1 января 1 года даты будут переводиться в диапазон с 00:00:00 1 января 1753 года по 23:59:59 1 января 1753 года, а при чтении - обратно;
даты 1С:Предприятия с 00:00:00 2 января 1753 года по 23:59:59 31 декабря 3999 года будут записываться в базу данных без изменений;
попытка записи в базу данных дат с 00:00:00 2 января 1 года по 23:59:59 1 января 1753 года будет приводить к ошибке.
Если смещение дат установлено в 2000, то при записи в базу данных к дате будет прибавлено 2000 лет, а при чтении из базы данных - вычтено 2000 лет. Это позволит записывать в базу данных любые даты 1С:Предприятия. Однако, при этом незначительно снизится скорость работы с базой данных, и при просмотре базы данных средствами, отличными от 1С:Предприятия, все даты окажутся измененными.

Таким образом, если при работе с информационной базой может возникнуть необходимость хранения дат, предшествующих 1 января 1753 года, то в качестве значения параметра следует выбрать 2000. Если же такие даты встречаться не будут, то в качестве смещения дат можно выбрать 0.

Важно, что нулевое значение смещения дат может привести к нежелательным ошибкам. Эти ошибки возникают, если конфигурация все-таки выполняет попытки записи дат, предшествующих 1 января 1753 года, которые не планировались. Поэтому для смещения дат при создании информационной базы "1С:Предприятие 8.2" в качестве значения по умолчанию предлагает использовать значение 2000.
   И Р
 
5 - 05.11.18 - 16:01
(4) Большое спасибо! Более чем доступно!
   palsergeich
 
6 - 05.11.18 - 16:03
(5) Ты не подумаЙ, это не я такой умный, я тупо из ИТС скопировал(
   MM
 
7 - 05.11.18 - 16:18
(4) Вот только давно уже в MS SQL есть тип DATETIME2, который в таком смещении не нуждается, но менять 1С ничего не торопится.
https://docs.microsoft.com/ru-ru/sql/t-sql/data-types/datetime2-transact-sql?view=sql-server-2017
   Cyberhawk
 
8 - 05.11.18 - 17:28
Это карма у тебя такая за "номерацию"
   Cyberhawk
 
9 - 05.11.18 - 17:31
(7) От 2000 отказались только в 8.3. Наверное от 2005 в 8.4 не откажутся, а значит и датавремя2 тоже использовать не будут...
   trad
 
10 - 05.11.18 - 17:35
(8) нумераторов не счесть
 
 Рекламное место пустует
   Cyberhawk
 
11 - 05.11.18 - 17:39
(10) Хз о чем ты
   vde69
 
12 - 05.11.18 - 17:42
(7) реально видел базы 1с с типом полей  DATETIME2...
   trad
 
13 - 05.11.18 - 17:45
(11) ТС решил выделиться из серой толпы
   Провинциальный 1сник
 
14 - 05.11.18 - 18:19
(9) А что мешало хранить датавремя в строке? В семерке так и было.
   Cyberhawk
 
15 - 05.11.18 - 19:46
(13) А, ясно. Не, Я про карму не из-за гордыни автора, а из-за его грамотности имел в виду)
   Cyberhawk
 
16 - 05.11.18 - 19:47
(14) В строке вообще все можно хранить. Видимо, МС не пошли таким путем, потому что не строки кое-когда обрабатывать быстрее, чем строки?
   MM
 
17 - 06.11.18 - 09:39
(9) Что мешает при создании базы в зависимости от версии СУБД использовать подходящий тип? Ведь невозможно понижать версию СКЛ, иначе как через выгрузку-загрузку.
   Cyberhawk
 
18 - 06.11.18 - 09:54
(17) При следовании такому подходу на каждый чих будет по флажку. Диалог создания инфобазы будет перегружен.
   MM
 
19 - 06.11.18 - 10:09
(18) Так флажки-то и не нужны. Если версия выше 2005, то используй новый тип с 0 смещением, если нет, то старый, по умолчанию со смещением 2000.
   Cyberhawk
 
20 - 06.11.18 - 15:12
(19) Либо им неохота запариваться над обратной совместимостью или конвертацией инфобазы (что делать с базами в которых уже используется "старый" тип и/или используется смещение), либо очкуют, что после такого поведения полезут ошибки в коде (где идет попытка записи в БД дат ранее 1753 года)
   Eiffil123
 
21 - 06.11.18 - 16:06
А зачем 1Сники вообще дают такую возможность выбирать - делать смещение или нет? Почему это жестко в платформе не прописано?
   Cyberhawk
 
22 - 06.11.18 - 16:08
(21) Ну вот переложили ответственность на того, кто регистрирует базу в кластере: или чуть страдаешь от замедления, или от риска ошибок записи в БД. В первом случае непонятно, насколько это замедление.
   dmpl
 
23 - 06.11.18 - 18:14
(22) Кому может потребоваться записывать в базу 1С даты ранее 1900 года? Все случаи ошибок в базах с нулевым смещение дат были по одной причине: человек ошибся. И вместо 2018 года вбил, например, 0201 год.
   Cyberhawk
 
24 - 06.11.18 - 19:48
(23) Видимо, ты не сталкивался с логическими ошибками в прикладном коде, в результате которых легко могут предприниматься какие-нибудь попытки записи "пустых" дат 01.01.0001 (где только время) в реквизит БД, который имеет тип "дата-время". Вот ошибку и получаем-с.
   dmpl
 
25 - 06.11.18 - 21:00
(24) Неа, см. (4). Ошибка будет при попытке записать дату начиная с 02.01.0001. И да, эти логические ошибки доставят гораздо меньше проблем, если у пользователя что-то не получится сделать, чем если ты будет искать почему программа работает неправильно, и после нескольких часов трассировки выйдешь на неправильную дату.
   Cyberhawk
 
26 - 06.11.18 - 21:10
(25) А, ты прав, точняк: даты за 1 января 0001 года переводятся в даты за 1 января 1753 года. Ну все равно в 1С смещение 0 очкуют принудатильно использовать почему-то
   Cyberhawk
 
27 - 06.11.18 - 21:10
*принудительно
   dmpl
 
28 - 06.11.18 - 21:31
(26) В свете этого не совсем понятно, почему при наличии смещения должны быть тормоза. Если есть смещение - мы просто отнимаем 2000 лет, если смещение нулевое, мы сначала проверяем дату на 1 января 1753 года, и только потом или вычитаем, или ничего не делаем. Ветвление гораздо неприятнее для более-менее новых процессоров, т.к. при неправильном предсказании это приводит к перезапуску конвейера, что в разы тормознее операции вычитания, которая, скорее всего, вообще будет бесплатной, т.к. загрузить исполнительные устройства на 100% очень сложно.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует