Часто в процессе развития и поддержки конфигурации накапливается множество устаревших объектов: документов, справочников, регистров и отчетов. Возникает логичная задача — очистить базу от «мусора». Однако просто взять и удалить объект метаданных из конфигуратора — большой риск. Рассмотрим подробнее, как максимально убедиться, что данный объект действительно больше нигде не используется, и разберем по шагам правильную методологию удаления.
В платформе 1С реализовано штатное удаление с контролем ссылочной целостности. Если мы попытаемся удалить объект метаданных, на который есть прямые ссылки в других объектах конфигурации (например, справочник указан в качестве типа реквизита в документе), система просто не даст этого сделать, выведя окно с указанием мест использования.
Кроме того, если речь идет о проверке данных в пользовательском режиме (наличие ссылок в существующих записях базы), проанализируем типовые конфигурации (на базе БСП: Розница, ЗУП, ERP, Бухгалтерия). В них встроен стандартный отчет Места использования ссылок. Выбираем нужный элемент или список элементов, запускаем отчет, и система покажет, в каких документах или регистрах остались записи с участием нашего объекта.
Если мы хотим быстро оценить масштабы использования документов определенного вида в базе (своеобразный «пузомер»), напишем небольшой скрипт. Посмотрим на пример кода, который перебирает метаданные документов и подсчитывает количество созданных документов каждого вида. Это поможет выявить документы, которые вообще не вводились пользователями.
Для Каждого ТекущийДокумент Из Метаданные.Документы Цикл
Имя = "Документ." + ТекущийДокумент.Имя;
Запрос = Новый Запрос("ВЫБРАТЬ КОЛИЧЕСТВО(ТекДок.Ссылка) КАК Количество ИЗ " + Имя + " КАК ТекДок");
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
КоличествоДокументов = Выборка.Количество;
// Здесь можно вывести данные в таблицу или сообщить пользователю
// Строка.Имя = Имя;
// Строка.Количество = КоличествоДокументов;
КонецЕсли;
КонецЦикла;
Данный подход показывает использование объектов в прошедшем времени. Если количество равно нулю, это первый сигнал к тому, что документ является кандидатом на удаление.
Штатный контроль конфигуратора отслеживает только явные связи в структуре метаданных. Выясним причину многих ошибок: разработчики забывают про текстовые ссылки в программном коде. Обязательно выполним глобальный поиск по имени объекта в конфигурации. Имя удаляемого объекта может остаться:
ОпределяемыеТипы и ПланыВидовХарактеристик.Если удалить объект, но не вычистить связанные с ним строки кода, база выдаст ошибки при компиляции или во время работы пользователей. Для более глубокого анализа часто применяют сторонние инструменты разработчика (различные подсистемы ИР) или переходят на разработку в 1C:EDT, которая проверяет битые ссылки в коде «на лету».
Особое внимание уделим планам обмена (РИБ, Конвертация Данных, EnterpriseData). Если удалить объект в центральной базе, при миграции в подчиненные узлы система просто физически «грохнет» объект, и там уже не будет возможности корректно разобрать ссылочную целостность.
Перед удалением необходимо:
Также проанализируем фоновые задания. Если существует объект РегламентныеЗадания, который периодически обращается к удаляемому регистру, после реструктуризации это задание начнет стабильно падать с ошибкой, засоряя журнал регистрации.
Даже если мы провели все проверки, всегда остается риск, что что-то пойдет не так, или кому-то из пользователей внезапно понадобится «неиспользуемый» отчет. Поэтому опытные разработчики не удаляют объекты сразу. Рассмотрим идеальный алгоритм — метод карантина.
Удалить_. Например, документ становится Удалить_СтарыйДокументРасчета.Такой многоступенчатый подход убережет вас от потери важных исторических данных и предотвратит обрушение обменов или интерфейса в перекроенной нетиповой конфигурации.