Смещение дат 2000 1с

В диалоге "Добавление информационной базы/группы" при создании информационной базы на СУБД 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 .

После создания информационной базы значение данного параметра не может быть изменено. Для изменения значение смещения дат необходимо создать новую информационную базу и выполнить копирование старой базы через выгрузку информационной базы в файл и загрузку информационной базы из файла.

Возникла задача пометить на удаление документы за 1 год. Эта операция выполняется перед бесследным удалением и включает выставление отметки и удаление движения по регистрам. Пробное удаление штатными средствами одного месяца заняло 4 часа. Это означало, что 12 месяцев удалялись бы 48 часов (2 суток). Забегая вперед, скажу, что прямым доступом к 1С документы удаляются за 30-40 минут. Обращение к MSSQL выполнялось через .Net framework и компонент .Net Bridge.

Определение имен таблиц MSSQL

Структура базы данных 1С весьма запутана и состоит из малозначимых для человека названий. 1С содержит функцию определения структуры хранения по имени объекта. В основу разработки положена эта функция ПолучитьСтруктуруХраненияБазыДанных, которая согласно русскому названию возвращает описание структуры. В этой структуре важны 2 поля Назначение, которое должно быть равно «Основная», и название таблицы ИмяТаблицыХранения.

Определение смещения дат

Таблица _YearOffset содержит число, обозначающее смещение года дат. Оно принимает значение 0 или 2000. Так со смещением 2000 дата 01.01.2014 будет храниться в базе данных как 01.01.4014. Соответственно при отборе по датам (удаление происходит за период времени) нужно учитывать смещение. Смещение можно получить следующим кодом 1С:

Установка пометки на удаление документов

Имея названия таблиц документов и зная, что поля _Date_Time, _Marked и _Posted отвечают за дату, отметку об удалении и отметку о проведении соответственно, можно одним SQL-запросом пометить их все на удаление. Делается это так:

Установка пометки на удаление в журналах документов

Не смотря на установку отметки на удаление у документов, в журналах документов хранятся дубли отметок об удалении на каждый документ. Список журналов, где участвует документ можно получить из метаданных документа так: Метаданные.ЖурналыДокументов
Отметка на удаление через поля _Marked и _Posted происходит аналогично через команду:

Удаление движений регистров

При удалении документов 1С удаляет движения документа по регистрам. В случае прямого доступа эти движения нужно удалить самостоятельно. Список регистров можно получить через метаданные ДокументМетаданные.Движения.
Команда, которой выполняется удаление движений следующая:

Заключение

Как оказалось, добиться убыстрения работы 1С примерно на 2 порядка не так сложно, достаточно выполнить 3 вида команд. В конечной обработке логика расширена за счет выбора документов по видам, добавлением таймаута, добавлением транзакции, пакетным выполнением команд.

PS. Список возникающих проблем и пути устранения:
1. Обработка игнорирует документы, где запрещено проведение, например, корректировка записей регистров. В корректировке записей регистров удаление документа связано со снятием активности записей регистров.
2. Результат удаления не отражается в планах обмена. Решается одновременным запуском обработки в связанных базах.
3. Не затрагивает таблицы итогов. Решается пересчетом итогов через Конфигуратор-Тестирование и Исправление-Пересчет итогов.

Ой, у вас баннер убежал!

Читают сейчас

Похожие публикации

• 20 декабря 2017 в 10:26

Немного про .NET Framework и .NET Core [плюс полезные ссылки]

Работаем с долгими API в ASP.NET Core правильно или тонкости переезда на новую платформу

Переход с ASP.NET к ASP.NET Core 2.0

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Комментарии 33

командаСмещение = sqlConnection.CreateCommand();
чтениеСмещение = командаСмещение.ExecuteReader();
командаДокумента.ExecuteNonQuery();

Вообще-то, вопрос прямого доступа к БД в 1С является критически важным для сложных проектов.

В частности, в компании где я работал, управление структурой изделия и ряд других функций производственного блока реализованы в виде хранимых процедур и функций. Т.к. «штатный» 1С код на два порядка медленнее, что делает операции, по сути, невозможными.
На уровне SQL операция выполняется за 20-30 сек, в 1С, соответственно, 30-50мин.
И дело даже не в комфорте, просто нужные дневные операции при этом невозможно ввести даже за полные сутки. А не то, что за рабочий день…

К слову, триггеры исполняются в рамках транзакции запущенной 1С — что и позволяет исполнять произвольный код в нужный момент и соблюдать целостность выполняемого как 1С так и MSSQL кода.

Самое сложное в этой схеме — при изменении любой задействованной таблицы в конфигураторе необходима перекомпиляция ХП (т.к. меняются имена таблиц/полей.) Однако, вопрос решается запуском специальной обработки после сохранения конфы.

В целом — работоспособность схемы проверена более чем надежно. Система работает уже порядка 6 лет (хотя я и уволился — но был там буквально пару месяцев назад, поддерживаю сотрудничество).

Кстати, предприятие входит в топ-10 налогоплательщиков региона. Т.е. совсем даже и не мелкое. А структура изделия может включать в себя до 20000 ДСЕ (детале-сборочных единиц). И 20к это не лимит, это имеющиеся реальные изделия. Вообще, формального, лимита на размер структуры нет.

P.S. версия 8.1/8.2 поверх MSSQL 2005
P.P.S. — убей не пойму, что мешает 1С сделать подобный инструментарий штатным, не требующим плясок с бубном и прочей фигни, расширив таким образом, области применимости 1С в разы…

Мдаа… В своё время, будучи студентом, я помогал перевести систему с Искры (кажется 226й) на клон XT (да-да, 4.77Mhz, 640KiB памяти, EGA монитор). И вот там тоже было порядка 20к «имеющихся реальных изделий». Мы изрядно повозились, но вписались. И вот теперь, имея в 1000 раз более быструю систему и в 1000 раз больше памяти люди снова решают ту же задачу и снова не не вписываются «в полные сутки, а не то, что в рабочий день».

Всё-таки удивительная это штука: прогресс.

1с очень любит делать вложенные запросы.

Скорее всего, вместо того, чтоб приджоинить таблицу 1с в цикле запускает запрос на удаление каждого документа

Никто не говорит, что этого делать не надо.
Почему при удалении 100млн строк нужно столько же раз проверить права, выполнить процедуры вместо того, что бы сделать это 1 раз?

Думаю для тех, кто хотя бы немного знаком с 1С известно, что прямая работа с БД — это нарушение лицензионного соглашения, но оставим этот вопрос.

Официальная позиция 1С по прямому доступу многим известна, не стоит так явно выдавать свою ангажированность. Тем не менее мыслящим людям рекомендую ознакомиться со статьей 1334 п.1 ГК РФ часть 4 «Исключительное право изготовителя базы данных», статьей 25 п.1 и п.3 «Свободное воспроизведение программ для ЭВМ и баз данных. Декомпилирование программ для ЭВМ» Закона об авторском праве и смежных правах. А также подумать, почему в 1С появилась родная функция ПолучитьСтруктуруХраненияБазыДанных и почему до сих пор не создано ни одного прецедента преследования по этому пункту лицензии. Комментарий выше: «Вообще-то, вопрос прямого доступа к БД в 1С является критически важным для сложных проектов» как бы намекает на ответ.

Если автор так уверен, что его действия содержат полный список операций, которые делает система при установке пометки удаления документов непосредственно средствами платформы, и сами операции настолько неоптимальны, что на их выполнение средставами 1С уходит аж на 2 порядка больше времени, то почему бы не написать, что именно платформа 1С делает не так?

Давайте разбираться спокойно без фанатизма. Где конкретно автор критикует 1С и говорит, что она делает что-то не так? Если бы я дублировал запросы 1С по каждому документу индивидуально, то получил бы схожее время работы.

Собрать трассировку профайлером — простейшая операция, зато статья получилась бы куда интереснее.

Нравится тратить впустую время, изучайте профайлером результат работы 1С и публикуйте статью. Мне не интересны темы, не приводящие к результату. А конкретно данная тема приводит к значительной экономии моего времени и времени пользователей.

Вот интересно, будь это не 1С, а другая ORM, тоже бы полезли менять БД напрямую, без понимания работы системы?

Нравится тратить впустую время, изучайте профайлером результат работы 1С и публикуйте статью. Мне не интересны темы, не приводящие к результату.

1. Что с итогами регистров? Таблицы итогов вы, похоже, не трогаете. Если итоги не пересчитать, база останется в несогласованном состоянии. А если пересчитать по-честному, разница в скорости станет не такой уж впечатляющей. Пересчитывать итоги прямыми запросами, думаю, даже вы не решитесь.

2. При таком удалении не исполняется логика отмены проведения, которая может быть не эквивалентна простому удалению движений. Возможный результат — опять же несогласованная база и ошибки при дальнейшей работе. Значит, данная обработка применима не для всех конфигураций и не для всех документов. Об этом нужно упомянуть в статье.

3. Обработка требует наличия вашей платной внешней компоненты. Об этом тоже нужно предупредить. Хотя в данном случае достаточно обычного ADODB.Connection.

P.S. Вы вообще эту обработку в продакшене использовали? Или она написана исключительно для пиара вашей ВК?

Одной из причин выбора метода прямого доступа стал как раз РИБ. В случае с РИБ время на удаление обычными средствами будет больше в разы. Время тратится не только на удаление в одной базе. Время дополнительно тратится на:
1. Формирование пакета обмена. В этот момент пользователям практически не реально работать в базе — обмен занимает основные таблицы.
2. Загрузку пакета обмена в каждую базу с занятием основных таблиц. Пользователям не реально работать в базе. Время на удаление будет сравнимо со временем пометки на удаление в первой базе.

В случае прямого доступа обработка и последующий пересчет итогов запускаются параллельно на всех связанных базах.

1. Что с итогами регистров? Таблицы итогов вы, похоже, не трогаете. Если итоги не пересчитать, база останется в несогласованном состоянии. А если пересчитать по-честному, разница в скорости станет не такой уж впечатляющей. Пересчитывать итоги прямыми запросами, думаю, даже вы не решитесь.

Пересчет делается через Конфигуратор-Тестирование и Исправление-Пересчет итогов

2. При таком удалении не исполняется логика отмены проведения, которая может быть не эквивалентна простому удалению движений. Возможный результат — опять же несогласованная база и ошибки при дальнейшей работе. Значит, данная обработка применима не для всех конфигураций и не для всех документов. Об этом нужно упомянуть в статье.

В обработке можно исключить документы с «особенной» логикой отмены проведения

3. Обработка требует наличия вашей платной внешней компоненты. Об этом тоже нужно предупредить. Хотя в данном случае достаточно обычного ADODB.Connection.

Обработка без проблем работает на ознакомительной версии. Код открыт. Специальные методы защиты алгоритма не предпринимались. Имея открытый код обработки можно переписать алгоритм под разные методы доступа к СУБД.

P.S. Вы вообще эту обработку в продакшене использовали? Или она написана исключительно для пиара вашей ВК?

Пересчет делается через Конфигуратор-Тестирование и Исправление-Пересчет итогов

О том, что в 1с v8.1 можно избежать проблему неуникальных индексов при наличии проблемных дат уже писал. Но нет, периодически возникают сомнения у новичков: а правда ли это.

1. Это проблема присуща толко MS SQL Server ( например на DB2 такой заморочки нет вообще). Изначально смещение — это формат хранения дат в субд.

2. Короткий пересказ мыслей разработчиков " Литерал ДАТАВРЕМЯ(1, 1, 1) адекватно представляется на всех СУБД и считается нулевой датой. Даты от ДАТАВРЕМЯ(1, 1, 1, 0, 0, 0) до ДАТАВРЕМЯ(1, 1, 1, 23, 59, 59) считаются временем без даты и тоже адекватно интерпретируются на всех СУБД. Различное поведение возможно для дат из диапазона с ДАТАВРЕМЯ(1, 1, 2) по ДАТАВРЕМЯ(1752, 12, 31, 23, 59, 59). Эти даты не могут быть представлены на MS SQL Server с нулевым смещением дат и могут интерпретироваться либо как нулевые даты, либо вызывать ошибку операций над данными.

В результате можно получить ошибку вроде Microsoft OLE DB Prov >

3. И хотя официальная позиция 1С туманна :), не стоит искать приключения .