Обновить историю данных 1с
В технологической платформе 8.3.11 был введен специальный механизм — «История данных». Этот механизм видится достаточно полезным, так как предоставляет ту функциональность, которую не редко приходится реализовывать вручную. В этой статье я попробую рассказать о том, что это за механизм, для чего он нужен и как с ним работать.
Общая информация
Начнем с общей теоретической информации о том, что такое история данных и как она устроена.
Описание и возможности
История данных — это механизм позволяющий хранить в базе данных упорядоченные по времени версии объектов конфигурации. Под версией понимаются данные, которые были в объекте на момент редактирования и состояние метаданных на момент редактирования. Хранить историю можно как для всего объекта целиком, так и для отдельных реквизитов — имеется возможность тонкой настройки работы механизма для каждого реквизита, в том числе табличные части.
Включать и выключать историю можно как из конфигуратора, так и средствами встроенного языка, все это дает возможность управлять историей для каждого пользователя отдельно.
Само по себе хранение истории достаточно бесполезная функция, поэтому с историей данных можно выполнять следующие операции:
- записывать версию данных;
- получать данные определенной версии;
- удалять данные определенной версии;
- получать разницу между двумя версиями одного объекта;
- прочие полезные возможности.
На момент написания статьи (8.3.13) история данных поддерживается для следующих объектов:
- общие реквизиты;
- константы;
- справочники;
- документы;
- бизнес-процессы;
- задачи;
- регистры сведений;
- планы обмена;
- планы счетов;
- планы видов характеристик;
- планы видов расчетов;
- расширения конфигурации.
Работа с историей данных регулируется правами доступа и отражается в журнале регистрации.
Устройство механизма
История данных хранится в специальных таблицах информационной базы. Кроме самих данных в этих таблицах хранятся метаданные прежних версий объектов. Версии метаданных создаются в момент изменения этих самых метаданных у объекта и никак не связаны с изменением данных объекта.
Также следует помнить, что на данный момент система не отличает включение версионирования для реквизита от создания реквизита и отключение версионирования реквизита от удаления реквизита.
Создание версии объекта состоит из двух этапов. Сначала, автоматически или с помощью специального метода, фиксируется факт изменения объекта и информация об этом изменении попадает в очередь. Перенос данных из очереди в таблицы базы выполняется методом ОбновитьИсторию(), этот метод можно выполнять асинхронно, например регламентным заданием. Идущие подряд изменения одного объекта не «склеиваются» и фиксируются отдельно, вне зависимости от периодичности обновления истории данных.
Настройка версирования объектов осуществляется либо из конфигуратора либо при помощи встроенного языка. Конфигуратор логично использовать в тех случаях, когда история данных потребуется во всех режимах работы приложения или на нее завязана какая-то прикладная логика. Использование встроенного языка потребуется для реализации более гибкой системы, например когда пользователя потребуется самому выбирать для каких объектов хранить историю данных.
Для управления историей данных объектов в конфигураторе реализовано свойство «История данных», оно присутствует как у основных объектов (у справочников, например) так и у подчиненных — реквизиты, табличные части с их реквизитами, ресурсы регистров сведений.
Свойство «История данных»
По умолчанию свойство «История данных» установлено в значение «Использовать» у:
- стандартных реквизитов;
- реквизитов объектов;
- реквизитов табличных частей;
- измерений регистров сведений (без возможности отключения);
- ресурсов регистров сведений.
Использование механизма
Для обращения к истории данных используется свойство глобального контекста ИсторияДанных, методы этого этого свойства будут рассмотрены ниже.
Управление использованием истории данных
Ниже приведены примеры того, как, средствами встроенного языка, можно управлять использованием истории данных. Отмечу, что значения свойства ИсторияДанных (полученные «через точку») берутся из конфигуратора и могут не соответствовать действительности, для получения актуальной информации нужно пользоваться методом ПолучитьНастройки().
(1) Насколько понимаю хранение происходит в системных таблицах, к которым через запрос нет прямого доступа.
Вся работа происходит через МенеджерИсторииДанных.
Немного доработал.
В процедуру
ОбновитьСтруктуруРеквизитов()
в цикле после
ОбъектМетаданных = Метаданные.НайтиПоПолномуИмени(ЗначениеМетаданные.Значение);
добавил
Настройка=ИсторияДанных.ПолучитьНастройки(ОбъектМетаданных);
и в добавление реквизита заменил
НовСтрока.Использование = истина;
на
НовСтрока.Использование = ?(не Настройка =Неопределено,Настройка.ИспользованиеПолей[Реквизит.Имя],истина);
поудобней будет. чтоб видеть сразу текущую настройку.
(3) Спасибо, на днях обновлю публикацию с исправлениями
(4) В данной обработке уже есть регламентное задание на базе бсп (скриншот во вложении)
"Внимание, без обновления истории данных версии появляться не будут!" - на платформе 8.3.13 история обновляется без запуска метода "ОбновитьИсторию()"! Установил настройки объекту обработкой и все, больше ничего не делал. Почему так? В 1С изменили алгоритм?
(8) Есть неподтвержденная информация, что на более новых версиях платформы при открытии формы истории объекта платформа вызывает обновление истории данных для этого элемента принудительно.
Просмотры 4465
Загрузки 24
Рейтинг 11
Создание 08.08.18 10:17
Обновление 02.09.20 16:38
№ Публикации 882670
Конфигурация Конфигурации 1cv8
Операционная система Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
Код открыт Да
См. также
Групповая корректировка записей регистров (Управляемое приложение) v 2.2 Промо
Обработка предназначена для групповой корректировки записей регистров Накопления, Сведений и Бухгалтерии. Разработана специально для Управляемого приложения.
2 стартмани
06.09.2013 72971 382 kser87 69
Предпросмотр PDF, JPG, PNG, TIFF, Word, Excel
Предварительный просмотр присоединенных файлов PDF, JPG, PNG, TIFF, Word, Excel через расширение. Позволяет изменять масштаб, поворачивать и листать. Не требует подключения к интернету и внешних компонент.
2 стартмани
01.11.2021 4527 50 TyurinArt 23
Управление платформенными обработками (расширение для типовых) [update 8.3.20]
Расширение использует недокументированную возможность для управления платформенными обработками. Например, чтобы подменить "Активные пользователи" или доработать "Конструктор запросов".
1 стартмани
07.10.2021 6029 10 SeiOkami 24
Универсальная обработка переноса данных из основной конфигурации в расширение
Обработка предназначена для разработчиков, для тех случаев, когда ранее дописанный функционал, перенесен в расширение и появляется необходимость перенести данные из объектов основной конфигурации в объекты расширения. Перенос осуществляется настройкой соответствия объектов основной конфигурации объектам расширения.
5 стартмани
05.10.2020 13356 81 biz-intel 71
Универсальная выгрузка/загрузка данных для отличающихся конфигураций (JSON, Такси+ОФ) Промо
Простой перенос через JSON данных между двумя базами 1С (документов, справочников, ПВХ, ПВР, счетов). Аналогична произвольной выгрузке в типовой "Выгрузка/загрузка XML", но может использоваться для отличающихся конфигураций. Подходит для любых пар баз с любым интерфейсом (управляемый + обычный). Без настроек. Не требует идентичности конфигураций и платформ. При переносе типы данных сопоставляются по наименованиям метаданных, объекты и ссылки по UID.
1 стартмани
22.10.2014 230941 4478 ekaruk 189
Улучшенная обработка универсального обмена данными в формате XML (УФ)
Улучшенная обработка "Универсальный обмен данными" с полноценными возможностями СКД для выборки данных (не только для отборов).
1 стартмани
23.06.2020 16105 170 Lem0n 1
Панель команд текущего объекта (документа, справочника и т.д.) со следующим возможностями: Редактор реквизитов, таблиц и движений текущего объекта, Анализ прав доступа к текущему объекту, Поиск ссылок на объект с отборами, Сторно движений документа, Выгрузка/загрузка текущего объекта между базами. Реализована всплывающей панелью в форме объекта. Подключается как расширение конфигурации (*.cfe) либо отдельными обработками.
2 стартмани
01.05.2020 17784 118 sapervodichka 3
Яндекс сервисы [Расширение]
Расширение для работы с Яндекс-сервисами (предиктор,переводчик,проверка орфографии)
1 стартмани
24.10.2019 18002 11 noprogrammer 12
Обработка "Распознавание штрихкода с помощью утилиты Zbar" для Документооборот ред. 2 Промо
В связи с тем, что стандартный функционал программы «Документооборот» ред. 2.1 дает возможность распознавания штрихкодов только форма EAN-13, данная обработка - альтернативный способ для распознавания штрихкода в программе 1С: Документооборот ред. 2 с помощью утилиты Zbar, которая распознает в том числе и в формате Code 128 (один из стандартных штрихкодов кодирования документов, например, «Управление торговлей» ред. 11), а также с возможностью поэтапно проследить все действия от распознавания до прикрепления к документу или простой загрузки в каталоги файлов в базе 1С.
5 стартмани
05.09.2016 30486 187 SEOAngels 11
Работа с файлами (обычная и управляемая форма)
Нужно загрузить файл с клиента на сервер или же, наоборот, файл загрузить с сервера на клиент, а впридачу все это на web-клиенте, да еще и асинхронно? Нет ничего проще, читай далее, как это сделать!
1 стартмани
10.06.2019 48380 261 Xershi 78
Электронная таблица средствами 1С (Версия 2.0)
Функционал электронной таблицы для программ на платформе 1С реализован на основе табличных документов. Функционал реализован в виде обработки. Большую часть формы обработки занимают листы (закладки) с табличными документами, которые выполняет роль электронной таблицы. Листы могут быть добавлены, удалены или переименованы. Ограничение по количеству листов определяется возможностью платформы. В формулах электронной таблицы можно использовать любые языковые конструкции, процедуры и функции 1С, ссылки на другие ячейки электронной таблицы расположенные в том числе и на других листах. Допустимо обращаться к ячейкам электронной таблицы по имени именованной области. В случае использования в формулах электронной таблицы данных из самой таблицы пересчет зависимых ячеек с формулами производится автоматически. Электронную таблицу можно сохранить в файл.
Данная команда выполняется только с правами Администратор.
Если необходимо для конкретного объекта создать версию данных принудительно, то необходимо выполнить после записи объекта код:
Так как же это все таки работает.
Все версии данных, при сохранении объектов попадают в очередь (таблица dbo._DataHistoryQueue0 на сервере SQL), и накапливаются там, пока не выполнится команда
Далее записи перемещаются в dbo._DataHistoryVersions, собственно из этой таблицы мы и видим данные, когда заходим в клиенте в раздел «История изменений»
Вроде бы ничего сложного, можно пользоваться.
Оказывается, есть нюансы:
А) Необходимо вести историю данных, причем сохранять изменения, которые делали пользователи, а не регламентные задания.
Б) Так же необходимо учесть, если объект пересоздается в другом месте БД, необходимо перенести и его историю. Например: оборудование демонтировали. В БД есть два объекта 1) Оборудование подразделения и 2) Демонтированное оборудование подразделения. При демонтаже в первом объекте запись удаляется, а во-втором создается путем копирования части реквизитов (структуры объектов не одинаковые).
Решение:Для решения пункта А) нам необходимо в объектах использовать процедуру
, где Ссылка на объект – ссылка на объект, для которого необходимо записать версию, т.е. объект, которые мы только что записали.
Почему после записи?
Потому что версия формируется не из формы, а из сохраненной записи БД.
Почему не используется
Потому что изменения, вызванные регламентными заданиями (например перезапись объекта), если таковые имеются, создадут версию данных. При каждом выполнении регламентного задания будет создаваться версия данных и помещаться в очередь. Соответственно при выполнении
все эти версии будут привязаны к объекту.
Для решения Б) нам придется немного схитрить. Дело в том, что готовой функции переноса истории с объекта в объект нет. Так что будем переписывать историю
После записи во-второй объект («Демонтированное оборудование подразделения»), нам необходимо его получить и добавить историю, которая была у объекта Источника:
, где Ссылка на объект – ссылка на объект источника, историю которого мы хотим передать новому объекту.
После переноса истории данных, во-втором объекте будут видны только те поля истории, которые совпадают по наименованию и типу с первым объектом.
Поля, которые нужны только для отображения истории первого объекта, и не используются во-втором объекте можно скрыть от пользователей и не заполнять при переносе из первого объекта.
Вроде бы задача решена, но что нам делать с очередью ИсторииДанных, которая продолжает расти, увеличивая нашу базу не по дням, а по часам.
К сожалению, во встроенной функции ИсторияДанных такой команды нет, поэтому пришлось делать костыльное решение. В SQL создал плановое задание из двух шагов:
Первый шаг, чистить таблицу очереди истории данных
Второй шаг, сжимает БД.
Если второй шаг не выполнять, БД не уменьшится в размерах.
В итоге размер БД сократился в 20 раз. Именно столько накопилось в очереди за 2 месяца использования истории данных.
Специальные предложения
Боже мой, что же у Вас всё так сумбурно написано :-( Вот так и не смог понять - ради чего это всё тут написано - что за такие сложности при работе с историей?
Я, просто, не использую типовой механизм, у меня очень давно используется самописное универсальное решение - и я просто не могу понять - откуда проблемы?
У самописки - было только два "тонких места" - это работа в РИБ (особенно когда возникло желание существенно "упаковать" данные истории - чтобы не использовать ссылки UID по 32 байта и не дублировать одинаковые строки); и вынос истории в отдельную базу (ибо хранить её - в той же базе - это бред "сивой кобылы", такой же, нет, ещё больший, как и бред хранить в той же базе присоединённые файлы - когда они есть почти у всех первичных документов в виде куче сканов).
А у Вас тут прям какие-то совершенно непонятные проблемы!
Ну ясен пень - что необходимость вызывать "ИсторияДанных.ОбновитьИсторию()" в основном это бред - историю придётся писать вручную, по старинке, через подписки на события через "ИсторияДанных.ЗаписатьВерсию(. )" - ибо, если кто-то сейчас пишет историю, то наверняка кто-то может её сейчас или через 5 минут уже анализировать (часто бывает - записываешь - и сразу смотришь - что там изменилось).
А переходить на отложенное выполонение через "ИсторияДанных.ОбновитьИсторию()" имеет смысл только выборочно - при массовых изменениях данных в обработках.
А вот, про перенос истории мне вообще не ясно - ЗАЧЕМ?
Как и про чистку таблицы "dbo._DataHistoryQueue0", она что - сама при вызове указанных выше функций записи истории не очищается?
(1)
Это все написано для тех кто использует стандартные механизмы платформы и не изобретает велосипед с регистрами.
Проблема которая здесь описана, связана с необходимостью вести историю данных исключая хранения ненужных версий данных, и необходимостью переноса истории данных, если объект был перемещен в другой справочник, или документ. При такой реализации использовать ИсторияДанных.ОбновитьИсторию() не получится, и очередь версий данных сама не почистится, а накопление очереди приведет к необоснованному росту БД со всеми вытекающими проблемами.
Вероятнее всего Вам не понятна статья, потому что вы с такими проблемами в своей работе не встречались.
(2)да, вероятно не встречался - ибо эта встроенная история бред бредом! Но статья у Вас всё равно сумбурно написана!
. Несколько раз перечитал, но задачу "Б" так и не понял: что значит пересоздается, GUID остается?. Что за "другое место БД"?. Объекты одного типа или разных? У этих объектов часть реквизитов совпадает?
(4)
Есть два документа1) Оборудование подразделения и 2) Демонтированное оборудование подразделения
В первом хранится оборудование, эксплуатируемое подразделением. В первом учитываются ремонты, простои, плановые остановки
Второй документ хранит оборудование, выведенное из эксплуатации и затраты по этому оборудованию за весь цикл его жизни.
Два документа имеют часть реквизитов одинаковых, а часть разных. Во-втором документе ТЧ аналогичная первому документу скрыта на форме и при переносе документа не заполняется. Пустая. А ТЧ затрат заполнена.
При выводе из эксплуатации оборудование из первого документа удаляется, а во-втором создается путем копирования одинаковых реквизитов(кроме ТЧ) и выборками из регистров затрат.
Время от времени специалистам необходимо видеть, какие работы проводились с оборудованием и кто вносил изменения в документ.
Так же демонтированное оборудование иногда возвращают в работу.
В связи с этим есть необходимость видеть всю историю по данному оборудованию.
GUID у объектов разные
Объекты одно типа
У этих объектов совпадают реквизиты только те, по которым необходимо видеть историю.
(5) У меня ощущение, что не правильная архитектура выполненной задачи потом порождает всякие костыли. Могу ошибаться, но справочники 1) Оборудование подразделения и 2) Демонтированное оборудование подразделения - должен быть один справочник, у которого имеется статус.
Задача "А".
1. В примере обрабатывается только запись из формы (это же модуль формы в примере)?
2. Почему не использовать событие ПриЗаписи() объекта, а там уже установить условие, что запись выполняется пользователем (само условие опускаю)? В этом случае получать объект по ссылке не нужно, что избавит от тормозов.
3. В продолжение события ПриЗаписи() объекта. Будет ли в этом случае корректно отрабатывать транзакция? Т.е. не стоит писать историю при отказе.
4. Для случая "А" исключено создание регламентного задания с ОбновитьИсторию()? Если да, то получается, нужно обрабатывать запись истории для каждого объекта индивидуально?
Все равно не совсем понял логику. ОбновитьИсторию() делает то же самое, что и ЗаписатьВерсию(), только для всех объектов?
Я установил в конфигураторе использование истории данных БЕЗ каки-либо обработок. История пишется и просматривается. Теперь не понимаю, для чего ОбновитьИсторию()? Удалится ли история через какое-то время или что еще может случиться?
История данных. Флаг - "Обновлять историю данных сразу после записи" в свойствах объекта.
У меня история данных становится доступной сразу, даже если флаг не установлен, хотя по идеи история должна помещаться в очередь и становится доступной после вызова метода ОбновитьИсторию() у менеджераИсторииДанных, по крайнее мере такая инфа на ИТС и зазеркалье. Получается метод ОбновитьИсторию для этих целей не нужен?
(7) Такая же ситуация: копнув таблицы _datahistoryqueue0 и _datahistoryversions - обратил внимание, что при не установленном флаге как у вас - пишется все в _datahistoryqueue0 а в _datahistoryversions пусто. Но стоить вызвать просмотр истории версии данных, то запись мгновенно уходит из первой таблицы и попадает во вторую. Получается - принудительная обработка очереди.
Возникла подобная ситуация: в некоторых регламентных заданиях осуществляется перенос дат на текущую дату документов, отобранных по определенных критериям (чтобы у пользователей они были всегда сверху или снизу, сортировка в списках всегда по дате). И, соответственно, пишутся сотни версий, в которых нет ценной информации. Решил следующим образом (увидел пример, кстати, в какой-то обработке с инфостарта), код упрощен:
После получения объекта, в котором будет изменена дата:
В модуле обработчика подписки на событие ПриЗаписи:
Т.е., с помощью изменения реквизита Отказ структуры ЗаписьИсторииДанных можно гибко управлять созданием версии.
За свою практику работы 1C программистом я видел два варианта хранения истории изменения данных: в основной базе регистр сведений с полем типа хранилище значений, заполняется по подписке на событие записи и в отдельной базе, доступ к которой происходит по OLE. Стандартное решение - БСП, подсистема "Версионирование объектов". Возможность хранения истории данных очень полезна, когда нужно найти причину ошибки в данных или просто найти крайнего ответственного. И вот наконец такую возможность включили в платформу, по информации сайта Заметки из Зазеркалья.
Конечно, платформа версии 8.3.11 еще пока находится в тестировании , в типовых конфигурациях это решение появится еще не скоро, но любопытство побеждает.
Посмотрим, что за механизм такой. Устанавливаем на компьютер платформу версии 8.3.11. 2831 Для тестирования подойдет В синтакс-помощнике появился менеджер истории данных, видно его методы.
История данных поддерживается для объектов: общие реквизиты, справочники, документы, бизнес-процессы, задачи, регистры сведений. В свойствах полей появилась настройка "История данных" (внизу рисунка).
Для некоторых стандартных реквизитов настройка пока не появилась (например, Пометка удаления). Возможно, это глюк особенность тестовой версии. Для простоты будем считать, что в конфигураторе новой версии у всех объектов (документы, справочники) установлено История данных = НеИспользовать, у реквизитов История данных = Использовать. Для табличных частей это свойство не имеет смысла, поскольку задается отдельно для каждого реквизита табличной части.
Откроем обработку " НастройкаХраненияДанных ", которая позволяет изменять настройки в режиме предприятие и находить отличия.
- Кнопка "Заполнить метаданные" выводит дерево метаданных по конфигурации. Пока настройки предприятия не заданы, колонка "История данных" показывает настройки из конфигуратора. Содержимое колонки можно изменять.
- Кнопка "Установить настройки" применяет одноименный метод к каждому объекту метаданных из дерева.
- Кнопка "Обновить историю" записывает изменения данных из временного хранения на постоянное. В документации рекомендуют метод ИсторияДанных.ОбновитьИсторию() вызывать раз в сутки, регламентным заданием, желательно НЕ в транзакции.
После установки свойства "История данных" документа "Приходная накладная" изменения начинаются фиксироваться. Создаем документ "Приходная накладная" № 3, сохраняем, затем изменяем реквизит Сумма по документу: вместо 3 пишем 0, сохраняем.
Переходим в обработку "Восстановить данные", в качестве текущего объекта выбираем документ "Приходная накладная" № 3.
Метод "ВыбратьВерсии" пока не показывает ни одной версии. Нажимаем "Обновить историю" из первой обработки. Теперь метод "ВыбратьВерсии" возвращает нам таблицу значений. Две версии - две строки. Вид изменения имеет два значения по версиям: сначала мы создали документ, потом изменили. В таблице значений несколько колонок скрыты.
Вывод: механизм интересный, заявленные функции выполняет. Примеры кода, обработки внутри прикрепленого файла.
После первых 10 скачиваний - планирую повышение цены .
P.S. В комментариях подсказали, что если для объекта ведется история данных, то в его системном меню есть отчет по истории данных.
И в завершение предлагаю помедитировать над кодом, обслуживающим объекты ИсторияДанных (DataHistory) из файла mngbase_root.res, который входит в состав платформы 8.3.11. Такого кода там много, хватит на всех желающих. Открывал в Notepad++.
Кто в курсе, для чего нужны галки "Обновлять историю данных сразу после записи" и "Выполнять обработку после записи версии истории данных" на закладке "Прочее" свойств Справочника в конфигураторе?
Читал что история обновляется методом ИсторияДанных.ОбновитьИсторию(), думал галка "Обновлять историю данных сразу после записи" на это и влияет, так нет, что с галкой, что без нее, история записывается.
В модуле менеджера есть процедура "ОбработкаПослеЗаписиВерсийИсторииДанных", так и она не отрабатывает ни при установленной галке "Выполнять обработку после записи версии истории данных", ни при снятой.
Так кто подскажет, на что влияют эти галки?
(5) почему мимо, вот это не о том что в шапке?
"Автоматическое формирование истории данных выполняется в несколько этапов:
1. Фиксируется необходимость создания версии. При этом есть возможность указать, что запись должна произойти в ускоренном режиме (свойство версионируемого объекта «Обновлять историю данных сразу после записи» программно меняется через параметр ОбновлятьИсториюСразуПослеЗаписи), или требуется выполнение постобработки после записи версии в истории данных (свойство «Выполнять обработку после записи версии истории данных» программное обращение через параметр ВыполнитьОбработкуПослеЗаписиВерсии), или требуется добавить дополнительные данные (метод ДобавитьДополнительныеДанные()).
Стоит отметить, что свойство «Обновлять историю данных сразу после записи» не рекомендуется устанавливать для видов объектов метаданных 1С, для которых предполагается большое количество элементов и частое их изменение."
Вообще-то и в первой ссылке есть ответ. В главе "Обработка изменения данных" кратко описаны этапы асинхронной работы механизма платформы.
как я написал в первом посте, ничего не меняется при установке/снятии этих галок!
т.е. при снятой галке "Обновлять историю данных сразу после записи" запись истории должна происходить только при выполнении ИсторияДанных.ОбновитьИсторию(), так?, а она все равно происходит тут же. и при установленной галке "Выполнять обработку после записи версии истории данных" должна выполняться процедура "ОбработкаПослеЗаписиВерсийИсторииДанных", но и этого не происходит, кароче, понятно что ничего не понятно!
Я всё-таки повторю предложение посмотреть в конфигурации. Возможно, например, в базе работает регламентное задание, которое обновляет историю и поэтому Вы не "видите" изменений в поведении базы.
Читайте также: