При работе с базами данных 1С иногда возникают специфические и деликатные задачи, требующие глубокого понимания архитектуры платформы. Одна из таких задач — необходимость полностью изменить внутренние идентификаторы (UUID/GUID) всех объектов метаданных в конфигураторе так, чтобы итоговую информационную базу невозможно было сопоставить с исходной по низкоуровневым идентификаторам. Это бывает необходимо для юридической или технической независимости новой ветки конфигурации от ее прародителя, чтобы исключить любые доказательства заимствования структуры метаданных.
Простое создание новой пустой базы и объединение конфигураций (без загрузки файла .cf) действительно меняет GUID метаданных в приемнике, но приводит к полной потере накопленных данных, так как таблицы СУБД для новой конфигурации будут созданы «с нуля» и связь со старыми таблицами прервется. Выясним причину этой проблемы и разберем по шагам несколько надежных и проверенных на практике методов, которые позволяют обойти это ограничение и сохранить все данные ИБ в целостности.
Прежде чем переходить к практическим действиям, проанализируем ситуацию на уровне СУБД. В платформе 1С:Предприятие существуют два разных типа идентификаторов:
Контрагенты или документа РеализацияТоваровУслуг). Этот идентификатор определяет, как будет называться физическая таблица в базе данных SQL (например, _Reference45 или _Document82).Наша цель — полностью переписать GUID метаданных (что повлечет за собой переименование всех таблиц в SQL), но при этом бережно перенести GUID самих данных, чтобы все внутренние ссылки в документах, регистрах и реквизитах остались рабочими.
Рассмотрим подробнее четыре основных метода решения этой задачи.
В современных версиях платформы 1С:Предприятие 8.3 реализован мощный механизм выгрузки конфигурации в файлы. С его помощью мы можем разобрать конфигурацию «на кирпичики», заменить идентификаторы на текстовом уровне и собрать обратно.
Выполним следующие шаги:
F7).В результате мы получаем конфигурацию, которая визуально и функционально полностью идентична исходной, но имеет абсолютно другие внутренние идентификаторы метаданных. Ни один инструмент сравнения конфигураций не сможет доказать их общее происхождение.
После того как новая конфигурация с измененными GUID создана, стандартная обработка ВыгрузкаЗагрузкаДанныхXML не сможет напрямую перенести данные из старой базы в новую. Посмотрим на пример работы этой обработки: она сопоставляет типы данных по их внутренним идентификаторам метаданных. Поскольку в новой конфигурации эти GUID изменились, обработка выдаст ошибку отсутствия типов.
Решением является использование мощного инструмента Конвертация данных 2.1. Разберем этот процесс по шагам:
MD83Exp.epf).Справочник.Контрагенты, Документ.ПоступлениеТоваровУслуг) в обеих базах совпадают, воспользуйтесь автоматическим созданием правил обмена. Сопоставление будет выполнено по наименованию.При такой настройке правила обмена при выгрузке зафиксируют GUID каждого элемента данных. При загрузке в новую базу элементы будут созданы с точно такими же GUID, что гарантирует полную сохранность ссылочной целостности (документы не потеряют свои субконто, аналитику и связи).
Если ваша информационная база имеет внушительный объем (сотни гигабайт или терабайты), то выгрузка и загрузка через XML-файлы займет слишком много времени и потребует колоссальных аппаратных ресурсов. В такой ситуации применим альтернативный метод «временного переименования» непосредственно в рабочей базе данных.
Проанализируем этот сценарий:
Контрагенты в _Удалить_Контрагенты, а документы — в _Удалить_РеализацияТоваровУслуг)._Удалить_ (заполненные данными) и новые пустые объекты с оригинальными именами.Посмотрим на пример кода, который выполняет такой перенос для справочника:
// Пример переноса элементов справочника "Контрагенты" на месте
ВыборкаСтарые = Справочники._Удалить_Контрагенты.Выбрать();
Пока ВыборкаСтарые.Следующий() Цикл
// Исключаем группы, если справочник иерархический
Если ВыборкаСтарые.ЭтоГруппа Тогда
НовыйЭлемент = Справочники.Контрагенты.СоздатьГруппу();
Иначе
НовыйЭлемент = Справочники.Контрагенты.СоздатьЭлемент();
КонецЕсли;
// Принудительно устанавливаем тот же уникальный идентификатор (GUID)
СтарыйGUID = ВыборкаСтарые.Ссылка.УникальныйИдентификатор();
НоваяСсылка = Справочники.Контрагенты.ПолучитьСсылку(СтарыйGUID);
НовыйЭлемент.УстановитьСсылкуНового(НоваяСсылка);
// Заполняем реквизиты
ЗаполнитьЗначенияСвойств(НовыйЭлемент, ВыборкаСтарые);
// Отключаем бизнес-логику для ускорения и корректности записи
НовыйЭлемент.ОбменДанными.Загрузка = Истина;
НовыйЭлемент.Записать();
КонецЦикла;
После завершения работы скрипта переноса для всех справочников, документов и регистров, удалите объекты с префиксом _Удалить_ из конфигуратора и выполните финальное обновление конфигурации базы данных. Старые таблицы будут физически удалены из базы данных СУБД, оставив только новые структуры.
Для высококвалифицированных администраторов баз данных существует радикальный и самый быстрый способ, выполняемый напрямую средствами СУБД. При изменении GUID метаданных в конфигураторе 1С генерирует новые имена таблиц в базе данных. Процесс реструктуризации при обновлении базы данных выполняет копирование данных из старой таблицы в новую, что при больших объемах занимает часы.
Для оптимизации этого процесса специалисты прибегают к следующему алгоритму:
_Reference12 создается _Reference34).DBSchema, хранящая бинарное описание соответствия объектов метаданных 1С и физических таблиц SQL.Важное предупреждение: Данный метод является недокументированным и поддерживается исключительно на ваш страх и риск. Ошибка в структуре таблицы DBSchema может привести к полной неработоспособности базы данных и невозможности ее открытия в конфигураторе.
Если ваша конфигурация разработана с использованием Библиотеки стандартных подсистем (БСП) (а это практически все типовые решения от 1С: Бухгалтерия, ERP, Управление торговлей и др.), то в ней обязательно присутствует служебный справочник Идентификаторы объектов метаданных.
В этом справочнике хранятся элементы, которые жестко привязаны к GUID объектов метаданных вашей конфигурации. На этих идентификаторах завязана работа ролей, прав доступа, дополнительных реквизитов, версионирования объектов и других ключевых подсистем БСП. После изменения GUID метаданных запуск системы в режиме «1С:Предприятие» вызовет лавину критических ошибок.
Чтобы избежать этого, выполните следующие действия сразу после загрузки новой конфигурации с измененными GUID:
ИсполняемыйФайл1С.exe ENTERPRISE /F "ПутьКБазе" /C ЗапуститОбновлениеИнформационнойБазы
Рассмотрим пример кода для принудительного обновления идентификаторов метаданных БСП:
// Принудительное обновление справочника идентификаторов объектов метаданных
Попытка
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(Истина, Ложь);
ЗаписьЖурналаРегистрации("ОбновлениеМетаданных", УровеньЖурналаРегистрации.Информация, , , "Справочник идентификаторов БСП успешно обновлен под новые GUID.");
Исключение
ЗаписьЖурналаРегистрации("ОбновлениеМетаданных", УровеньЖурналаРегистрации.Ошибка, , , "Ошибка обновления идентификаторов БСП: " + ОписаниеОшибки());
КонецПопытки;
Этот код очистит старые неактуальные записи, сопоставит новые GUID метаданных конфигуратора с элементами справочника БСП и создаст новые записи, восстановив полную работоспособность всех механизмов конфигурации.
Подводя итог, можно утверждать, что задача полной смены внутренних идентификаторов объектов в конфигураторе 1С с сохранением данных вполне решаема. Выбор конкретного метода зависит от объемов вашей базы данных и уровня вашей технической подготовки. Использование Конвертации данных гарантирует максимальную безопасность процесса, в то время как манипуляции с XML-файлами конфигурации позволяют провести глубокую деассоциацию структуры метаданных.