1с где хранится история отборов
В технологической платформе 8.3.11 был введен специальный механизм — «История данных». Этот механизм видится достаточно полезным, так как предоставляет ту функциональность, которую не редко приходится реализовывать вручную. В этой статье я попробую рассказать о том, что это за механизм, для чего он нужен и как с ним работать.
Общая информация
Начнем с общей теоретической информации о том, что такое история данных и как она устроена.
Описание и возможности
История данных — это механизм позволяющий хранить в базе данных упорядоченные по времени версии объектов конфигурации. Под версией понимаются данные, которые были в объекте на момент редактирования и состояние метаданных на момент редактирования. Хранить историю можно как для всего объекта целиком, так и для отдельных реквизитов — имеется возможность тонкой настройки работы механизма для каждого реквизита, в том числе табличные части.
Включать и выключать историю можно как из конфигуратора, так и средствами встроенного языка, все это дает возможность управлять историей для каждого пользователя отдельно.
Само по себе хранение истории достаточно бесполезная функция, поэтому с историей данных можно выполнять следующие операции:
- записывать версию данных;
- получать данные определенной версии;
- удалять данные определенной версии;
- получать разницу между двумя версиями одного объекта;
- прочие полезные возможности.
На момент написания статьи (8.3.13) история данных поддерживается для следующих объектов:
- общие реквизиты;
- константы;
- справочники;
- документы;
- бизнес-процессы;
- задачи;
- регистры сведений;
- планы обмена;
- планы счетов;
- планы видов характеристик;
- планы видов расчетов;
- расширения конфигурации.
Работа с историей данных регулируется правами доступа и отражается в журнале регистрации.
Устройство механизма
История данных хранится в специальных таблицах информационной базы. Кроме самих данных в этих таблицах хранятся метаданные прежних версий объектов. Версии метаданных создаются в момент изменения этих самых метаданных у объекта и никак не связаны с изменением данных объекта.
Также следует помнить, что на данный момент система не отличает включение версионирования для реквизита от создания реквизита и отключение версионирования реквизита от удаления реквизита.
Создание версии объекта состоит из двух этапов. Сначала, автоматически или с помощью специального метода, фиксируется факт изменения объекта и информация об этом изменении попадает в очередь. Перенос данных из очереди в таблицы базы выполняется методом ОбновитьИсторию(), этот метод можно выполнять асинхронно, например регламентным заданием. Идущие подряд изменения одного объекта не «склеиваются» и фиксируются отдельно, вне зависимости от периодичности обновления истории данных.
Настройка версирования объектов осуществляется либо из конфигуратора либо при помощи встроенного языка. Конфигуратор логично использовать в тех случаях, когда история данных потребуется во всех режимах работы приложения или на нее завязана какая-то прикладная логика. Использование встроенного языка потребуется для реализации более гибкой системы, например когда пользователя потребуется самому выбирать для каких объектов хранить историю данных.
Для управления историей данных объектов в конфигураторе реализовано свойство «История данных», оно присутствует как у основных объектов (у справочников, например) так и у подчиненных — реквизиты, табличные части с их реквизитами, ресурсы регистров сведений.
Свойство «История данных»
По умолчанию свойство «История данных» установлено в значение «Использовать» у:
- стандартных реквизитов;
- реквизитов объектов;
- реквизитов табличных частей;
- измерений регистров сведений (без возможности отключения);
- ресурсов регистров сведений.
Использование механизма
Для обращения к истории данных используется свойство глобального контекста ИсторияДанных, методы этого этого свойства будут рассмотрены ниже.
Управление использованием истории данных
Ниже приведены примеры того, как, средствами встроенного языка, можно управлять использованием истории данных. Отмечу, что значения свойства ИсторияДанных (полученные «через точку») берутся из конфигуратора и могут не соответствовать действительности, для получения актуальной информации нужно пользоваться методом ПолучитьНастройки().
Работает, но не сильно. Очищает историю только у текущей открытой формы. Переоткрываешь форму - история отбора на месте.
Вот спасибо.. А история хранится в самой базе. Взял файл базы - закинул вообще на другой комп. Отбор на месте!
Официальный ответ от 1С на вопрос как почистить историю отбора.
Такой возможности не предоставляется.
Можно только вытеснить устаревшие записи из истории отборов, установив новые
В конфигураторе стоит "(История отбора)". А где она хранится вообще?
Копал, копал. Думал, в каком-нибудь из *.pfl файлов, ан-нет. Удалил их все. Запускаю 1с - есть история. Выгрузил-загрузил базу - есть история. Видимо в какой-то внутренней таблице. А как ее прочитать?
Ой. А где кэш? Погуглил - вроде в Application Data?
Мой алгоритм:
Вышел из 1с.
Проверил завершение процесса в диспетчере задач.
Удалил папку в АppData (c:\Documents and Settings\yku\Application Data\1C) 1С вообще (переименовал чтобы настройки не терять).
Запустил 1С - история осталась.
Вышел из 1С.
Опять удалил папку c:\Documents and Settings\yku\Application Data\1C .
Еще удалил папку c:\Documents and Settings\yku\Local Settings\Application Data\1С.
Попробовал запустить 1С. История осталась.
Вышел из 1С.
Удалил обе папки 1С.
Удалил темп из папки Windows и из Local Settings.
Запустил 1С - есть история.
Выгрузил базу из конфигуратора.
Запустил Virtualbox.
В виртуалке: Сделал снапшот системы.
В виртуалке: Создал пустую базу и загрузил данные.
В виртуалке: Запустил 1С - есть история.
В виртуалке: Вернулся к снапшоту.
Скопировал в виртуалку файл 1Cv8.1CD из базы.
В виртуалке: Запустил базу из папки - история есть.
Так вот. Если Вы имели ввиду кэш внутри 1Cv8.1CD - то как его удалять? Если же "внешний" кэш, то очень жаль, так как не помогает :(
Если нет идей как прочитать, то как его хотя бы удалить? Неужто только стандартная выгрузка/загрузка XML в идентичную конфигурацию?.
ЭлементыФормы.ДействияФормы.Кнопки.Подменю1.Кнопки.Очистить();
Где Подменю1-кнопка истории отборов.
Проверено. Работает.
ЭлементыФормы.ДействияФормы.Кнопки.Подменю1.Кнопки.Очистить();
Где Подменю1-кнопка истории отборов.
Проверено. Работает.
Речь о том, чтобы хранить в базе историю изменения реквизитов объектов.
Объекты в данном случае - это справочники, документы, планы обмена, планы видов характеристик и т. д., в общем то, что вводится пользователем вручную, для чего требуется хранить историю изменения реквизитов и на что можно сделать ссылку.
Состав объектов произвольный и определяется программистом, то есть можно, к примеру, настроить механизм только для всех справочников и выборочных документов.
Общая идею проста, как четыре рубля одной монетой.
А вот при ближайшем рассмотрении выяснилось пара нюансов.
А при превращении мыслей в статью и вовсе все поменялось.
Для начала, делаем периодический регистр сведений "История реквизитов" без привязки к регистратору.
Затем, очень хочется иметь в этом регистре сведений измерение "Объект" типа "Любая ссылка", но этого делать нельзя.
Причина та, что тогда мы теряем возможность удалять помеченные на удаление объекты, поскольку на них будут ссылки в регистре.
Если же это измерение делать ведущим, то при удалении мы потеряем всю историю по этому объекту, которая удалится вместе с самим объектом.
А с другой стороны и без этого реквизита совсем уж никуда, ни отчета сформировать, ни просто даже объект найти.
Поэтому, в каждый объект, для которого требуется регистрация изменений реквизитов, добавляем реквизит "GUID" типа "Строка (32)".
Кроме того, в регистр сведений "История реквизитов" добавляем измерение "GUID объекта" типа "Строка (32)".
Так я хотел написать сначала.
А потом хорошо подумал.
Во-первых, очень плохо делать разные соединения с таблицами объектов в запросах, чтобы получить нужный объект по реквизиту "GUID".
Во-вторых, журнал регистрации фирмой 1С реализован таким образом, что в нем в реквизите "Данные" хранится именно ссылка на объект, а никакой не GUID.
Просто при удалении объектов журнал регистрации не участвует в проверке ссылочной целостности и после удаления объекта в нем в реквизите "Данные" показывается знакомая многим надпись " . ".
В-третьих, GUID вместо ссылок придется тогда вставлять и в остальных полях, то есть в пользователе, старом значении и новом значении.
В-четвертых, дешевле сделать свой алгоритм удаления помеченных объектов, нежели так изголяться.
Тем паче, что типовой алгоритм крайне скуден.
Правда, в рамках данной статьи описывать альтернативный алгоритм удаления помеченных объектов я не буду, ограничусь лишь тем, что скажу, что этот алгоритм должен при удалении помеченных объектов в регистре сведений "История реквизитов" все ссылки на удаляемые объекты заменять пустыми ссылками.
Почему пустыми?
Да все просто, чтобы ссылочная целостность базы не нарушалась.
Поэтому добавляем измерение "Объект" типа "Любая ссылка".
Вместо типа "Любая ссылка" можно проставить галочки у конкретных объектов, без разницы.
Помимо объекта нужно иметь информацию о реквизите, который меняется.
Поэтому добавляем измерение "Реквизит" типа "Строка (25)" или "Справочник.РеквизитыОбъектов", кому как больше нравится.
Я для примера сделал строкой.
Затем добавляем информацию о пользователе, сделавшем изменения.
Для этого добавляем ресурс "Пользователь" типа "Справочник.Пользователи".
Кроме того, добавляем ресурс "Имя компьютера" типа "Строка (25)".
Кому 25 символов мало, может изменить на нужное количество.
Для того, чтобы знать, в какой распределенной базе меняли реквизит, в случае использования распределенных баз, нужно добавить ресурс "Распределенная база" типа план обмена "Распределенные базы".
И, наконец, добаляем два ресурса, "СтароеЗначение" и "НовоеЗначение" составного типа.
В составе типов "Число", "Строка", "Булево", "Дата" и "Любая ссылка".
Размерность типов "Число" и "Строка" проставляется максимальная из возможных, чтобы в нее уместилось содержимое любого реквизита.
Здесь есть досадный момент, в состав типов нельзя включить строку неограниченной длины.
Поэтому механизм нельзя будет применять для строк неограниченной длины, содержимое которых длиннее максимального размера строки в составе нашего типа.
Теперь по поводу настроек в объектах.
Во всех объектах, для которых будет регистрироваться история, требуется прописать следующий код.
Переменная "НаборЗаписейИсторияОбъектов" вынесена в переменные модуля по той причине, что для нового объекта проверку реквизитов нужно делать в процедуре "ПередЗаписью", а заполнять реквизит "Объект" значением "Ссылка" в процедуре "ПриЗаписи", поскольку в процедуре "ПередЗаписью" еще нет ссылки для нового объекта.
Пример приведен для иерархического подчиненного справочника.
Если брать другой объект, например, документ, то состав служебных реквизитов будет другой, не "Код", "Наименование", "Родитель" и "Владелец", а "Дата" и "Номер".
В следующих статьях будут рассмотрены примеры использования механизма, описанного в данной статье.
Эта доработка общего журнала документов ("ЖурналОбщий.ФормаСписка") ТиС 9.2 позволяет использовать закладки формы для механизма отбора документов отличным от ЗакладкиОтбора() способом: закладки хранят историю отборов, разных по виду и значениям.
Как они работают:
- При установке нового отбора добавляется и перемещается на первую позицию новая закладка с заголовком-значением отбора.
- В случае если отбор ранее использовался и на форме есть его закладка, она становится текущей.
- При достижении определенного количества закладок, новые закладки добавляются за счет "выбываемых", которые "сворачиваются". Их можно открыть через последнюю закладку "Другие. "
- При переключении на выбранную закладку соответствующий отбор устанавливается автоматически.
- Для удаления закладок щелкнуть на закладку "Другие" и выбрать действие "Удалить закладки. "
Реализовано сохранение и установка текущих значений для каждой закладки о:
- текущем документе
- текущем интервале журнала
- текущей колонке (кроме колонок "Текст" без идентификатора)
Порядок использования в ТиС 9.2:
1. Текст файла вставить в модуль формы "ЖурналОбщий.ФормаСписка" между описаниями переменных модуля и блоком процедур и функций (или перед строкой "// ПРОЦЕДУРЫ И ФУНКЦИИ МОДУЛЯ")
2. Переименовать штатные процедуры модуля:
ПриУстановкеБыстрогоОтбора() в ПриУстановкеБыстрогоОтбораТиС()
ПриЗакрытии() в ПриЗакрытииТиС()
3. По желанию. Задать количество видимых закладок и закладок всего (видимых и скрываемых)
здесь сделано:
Доработка ориентирована на общий журнал ТиС 9.2, однако также может применяться и в любой другой конфигурации, т.к. вся обработка закладок идет уже после установки отбора, который в ТиС 9.2 отрабатывается в процедуре ПриУстановкеБыстрогоОтбора()
То есть, чтобы "заточить" закладки под свою конфигурацию, нужно немного изменить в ней эту аналогичную процедуру
Остались реквизиты формы, отвечающие за отбор. Для удобства обращение к ним и установка их свойств и значений вынесено в отдельные ПолучитьРеквизитФормы() и УстановитьРеквизитФормы()
Изменения от 26.12.2007
Сохранение текущего интервала журнала для каждой из закладок по умолчанию отключено.
При смене интервала журнала (меню "Действия" - "Интервал") пользователю предлагается сохранить выбранный интервал:
"ДА" - текущий интервал сохраняется и восстанавливается при повторном выборе закладки,
"НЕТ" - при выборе закладки интервал устанавливается в соответствии с настройками, действующими на момент открытия журнала
"Отмена" - оставить настройки сохранения интервала без изменения.
Настройку реагирования на смену границ интервала можно сделать, изменив в модуле инициализацию переменных:
По умолчанию вопрос о сохранении интервала выдается только при смене начала интервала журнала.
Установка обеих переменных в 0 отключает сохранение интервала журнала вообще.
Назначение объекта конфигурации «Хранилище настроек» понятно из названия — хранить различные пользовательские настройки. Область применения данного объекта широка — в любой, хоть сколь-нибудь серьезной конфигурации требуется хранить какие-либо пользовательские настройки.
Для удобства программистов в каждой конфигурации существует несколько стандартных хранилищ настроек, кроме этого есть возможность создать столько дополнительных хранилищ настроек, сколько будет нужно.
Хранилища настроек в конфигураторе
Сначала разберемся со стандартными хранилищами настроек, которые присутствуют в любой конфигурации 1С начиная с версии 8.2.
Стандартные хранилища настроек
Итак, по умолчанию, в конфигурации имеются следующие хранилища настроек:
- ХранилищеВариантовОтчетов — для доступа к настройкам вариантов отчетов.
- ХранилищеПользовательскихНастроекОтчетов — для доступа к пользовательским настройкам отчетов.
- ХранилищеНастроекДанныхФорм — для доступа к пользовательским настройкам данных форм.
- ХранилищеОбщихНастроек — для доступа к общим настройкам.
- ХранилищеСистемныхНастроек — для доступа к системным настройкам.
- ХранилищеПользовательскихНастроекДинамическихСписков — для доступа к пользовательским настройкам динамических списков.
К каждому из этих хранилищ можно обратиться как к свойству глобального контекста.
Стандартные хранилище программист может использовать для своих нужд, сохраняя различные настройки в разрезе пользователя, объекта и самой настройки.
Для работы с хранилищами настроек (как со стандартными, так и с добавленными программистом) используются следующие методы.
Запись и получение настройки:
ХранилищеОбщихНастроек.Сохранить(НазваниеОбъекта, НазваниеНастройки, ЗначениеНастройки, ОписаниеНастройки, ИмяПользователя);
ЗначениеНастройки = ХранилищеОбщихНастроек.Загрузить(НазваниеОбъекта, НазваниеНастройки, ОписаниеНастройки, ИмяПользователя);
Читайте также: