Часто при поддержке нескольких распределенных баз разработчики сталкиваются с неочевидным поведением платформы 1С. Рассмотрим типичную ситуацию: в нескольких базах были независимо друг от друга созданы справочники или реквизиты с абсолютно одинаковыми именами. Пока вы сравниваете конфигурации визуально, платформа показывает, что объекты идентичны. Но как только дело доходит до обновления базы данных из единого хранилища, система воспринимает эти объекты как разные. В результате старые объекты удаляются вместе со всеми накопленными пользовательскими данными, а на их месте создаются новые, пустые таблицы. Разберем по шагам, почему так происходит и как правильно решить эту проблему. Для упрощения технического обслуживания распределенных систем можно использовать автоматическое архивирование, обновление и тестирование нескольких баз 1С по расписанию.
Проанализируем механику работы метаданных 1С. Каждый созданный объект (справочник, документ, регистр, реквизит) имеет скрытый 128-битный уникальный внутренний идентификатор — GUID. Если доработки в разные базы вносились независимо (например, программист создавал справочники вручную в каждой базе), платформа всегда генерирует для них совершенно разные идентификаторы, даже если имена (синонимы) совпадают символ в символ.
Внутренние идентификаторы сохраняются неизменными только в случаях, когда объекты переносятся путем объединения с файлом .cf или при штатном получении из хранилища конфигурации. Во всех остальных случаях (включая копирование через буфер обмена Ctrl+C / Ctrl+V) генерируется новый GUID.
Выясним причину такого двойственного поведения конфигуратора. Проблема кроется в том, что платформа использует разные алгоритмы на разных этапах работы:
Как же узнать эти внутренние идентификаторы? Штатно в интерфейсе Конфигуратора их не видно. Однако программно их можно получить, например, через функцию БСП ОбщегоНазначения.ИдентификаторОбъектаМетаданных(), которая возвращает ссылку с идентификатором.
Рассмотрим первый способ решения проблемы без потери данных, который доступен прямо в конфигураторе. Наша задача — заставить платформу заменить старые идентификаторы на новые правильные (эталонные), сохранив при этом физические таблицы базы данных.
.cf с правильными (эталонными) метаданными, например, из хранилища конфигурации..cf. В настройках обязательно снимите флажок Установить соответствие по именам объектов. Так вы увидите реальный расклад по несовпадающим метаданным.Проанализируем более технический подход. Если объектов много и сопоставлять их вручную слишком долго или велик риск ошибки, можно синхронизировать GUID на уровне исходных файлов XML.
.cf, выгрузив её в отдельную папку.uuid, в котором записан внутренний идентификатор.После этой процедуры внутренние идентификаторы метаданных будут полностью синхронизированы, и базу можно будет безболезненно подключить к единому хранилищу.
Посмотрим на самый безопасный, хоть и более трудозатратный, архитектурный вариант. Если расхождений в идентификаторах критически много, ручное сопоставление или правка XML могут привести к непредсказуемым ошибкам ссылочной целостности в базе. В такой ситуации эффективнее выполнить перенос данных между похожими конфигурациями 1С с сопоставлением объектов по произвольным полям поиска.
В такой ситуации правильнее всего создать чистую (пустую) базу данных из эталонного .cf файла (например, отраслевой УТ, на которую вы планируете переход). Затем, используя правила обмена (созданные, например, в конфигурации Конвертация данных 2.1), перенесите все исторические справочники, остатки и документы из старой базы в новую. При обмене через правила система сопоставит объекты по заданным вами ключевым полям (коду, наименованию, артикулу) и корректно запишет их в новую структуру метаданных с правильными GUID.
Всегда делайте резервные копии баз данных перед любыми манипуляциями с внутренними идентификаторами и объединением нетиповых конфигураций! А после завершения работ по сопоставлению или миграции полезно автоматически сравнить бухгалтерские проводки между базами для контроля корректности результата.