При работе с несколькими информационными базами 1С, особенно когда они создавались методом копирования, часто возникают ситуации, когда у разных баз оказываются одинаковые уникальные идентификаторы. Это может привести к серьезным проблемам при попытке настроить обмен данными между ними, поскольку система 1С воспринимает их как один и тот же источник. В данной статье мы подробно рассмотрим, почему это происходит и как решить проблему с дублированием идентификаторов серверных баз на PostgreSQL, а также как предотвратить подобные ситуации в будущем.
Для начала, давайте разберемся с основными понятиями, связанными с идентификаторами в системе 1С. В платформе 1С используются универсальные уникальные идентификаторы (UUID), которые также известны как глобальные уникальные идентификаторы (GUID). Эти 128-битные значения генерируются таким образом, чтобы обеспечить статистически уникальную идентификацию каждого объекта, записи или даже самой информационной базы в системе. Они критически важны для связей между объектами, метаданными конфигурации и, конечно же, для механизмов обмена данными.
Ключевым моментом для нашего обсуждения является различие между "ИдентификаторомИнформационнойБазы" и идентификаторами узлов обмена:
ИдентификаторИнформационнойБазы: Это специальная константа, которая предназначена для уникальной идентификации непосредственно всей информационной базы. Она должна быть уникальной для каждого отдельного экземпляра базы и используется для таких целей, как сбор статистики, внешнее управление или отслеживание. Если эта константа пуста, платформа 1С автоматически сгенерирует для нее новое значение. Важно отметить, что в большинстве случаев ИдентификаторИнформационнойБазы не должен непосредственно входить в состав планов обмена как идентификатор участника, чтобы он мог быть уникальным для каждой базы-узла обмена.Причины дублирования идентификаторов при копировании баз кроются в том, что простое копирование информационной базы (например, копирование папки с файловой базой, восстановление из файла .dt или бэкапа СУБД) без выполнения необходимых процедур по ее "различию" приводит к сохранению всех внутренних идентификаторов. Это включает как ИдентификаторИнформационнойБазы, так и идентификаторы предопределенных узлов обмена. В результате, система воспринимает несколько физически разных баз как одного и того же участника обмена, что вызывает конфликты и блокирует дальнейшую настройку.
Когда вы сталкиваетесь с ошибкой вида "обмен с этой базой уже есть, уникальный идентификатор базы не уникальный", первым делом возникает вопрос: какой именно идентификатор вызывает проблему? Наши коллеги на форуме попытались сначала решить проблему, изменив константу ИдентификаторИнформационнойБазы.
Для проверки и потенциального изменения этой константы можно использовать следующий код:
ИдентификаторИнформационнойБазы = Новый УникальныйИдентификатор;
Константы.ИдентификаторИнформационнойБазы.Установить(Строка(ИдентификаторИнформационнойБазы));
Этот код генерирует новый уникальный идентификатор и записывает его в константу ИдентификаторИнформационнойБазы. Однако, как показали сообщения пользователей, в данном конкретном случае это действие не помогло решить проблему. Проверка показала, что значения в константах уже не совпадали с тем, на что ругалась система обмена. Это явно указывает на то, что ошибка была связана не с самой константой ИдентификаторИнформационнойБазы, а с другим идентификатором, а именно — с идентификатором узла обмена.
Таким образом, мы выяснили, что в центре внимания должен быть не глобальный идентификатор базы, а специфический "код центрального узла" в планах обмена, который система использует для распознавания участников синхронизации.
Теперь, когда мы определили истинный источник проблемы, разберем по шагам, как изменить код узла обмена для устранения конфликта. Этот метод оказался эффективным и был подтвержден нашими коллегами.
Шаг 1: Подготовка и резервное копирование.
Прежде чем приступать к любым изменениям, особенно связанным с внутренними идентификаторами и обменом данными, критически важно выполнить полное резервное копирование всех участвующих информационных баз. Это позволит вам восстановить работоспособное состояние системы в случае непредвиденных ошибок или некорректных действий.
Шаг 2: Открытие плана обмена и поиск узла.
В базе, которая является источником дублирования (в нашем случае это одна из баз "Бухгалтерии"), перейдите к спискам планов обмена. Обычно они находятся в разделах "Администрирование" или "Синхронизация данных". Найдите предопределенный узел, который относится к текущей информационной базе. Часто он называется "Этот компьютер" или имеет название, соответствующее текущей базе. В его свойствах вы увидите поле "Код" или "Префикс узла".
Мы говорим о планах обмена, которые имеют тип "Универсальный". В этих планах обмена есть ваш центральный узел, к которому относится текущая информационная база. Именно его код нас интересует.
Шаг 3: Изменение кода узла.
Откройте карточку соответствующего узла обмена на редактирование. Вам необходимо изменить его код. Это может быть строковое значение, состоящее из двух символов (например, "ЦБ", "Б1", "Б2" и т.д.). Важно выбрать такой код, который будет уникальным среди всех ваших баз, участвующих в обмене. Например, если у вас уже есть узел с кодом "Б1", для новой базы вы можете использовать "Б2".
Обратите внимание: Для выполнения этой операции может потребоваться роль с полными правами или права администратора системы. Изменение кода узла производится вручную через интерфейс 1С в режиме предприятия.
Шаг 4: Повторная настройка обмена.
После изменения кода узла обмена в базе-источнике (например, в "Бухгалтерии"), перейдите в базу-приемник ("Управление торговлей") и повторите попытку настройки обмена с этой "новой" базой "Бухгалтерии". Система должна успешно создать новую настройку обмена, поскольку теперь она видит уникальный идентификатор узла.
Важный нюанс при уже настроенном обмене.
Если вы столкнулись с ситуацией, когда обмен с одной из дублирующихся баз уже был настроен, и вам нужно добавить вторую, то просто изменить код узла в "Бухгалтерии" может быть недостаточно. В таком случае, вам придется не только изменить код центрального узла в базе "Бухгалтерии", но и соответствующий код узла-корреспондента в настройках обмена в базе "Управление торговлей". То есть, потребуется синхронное изменение на обеих сторонах обмена, чтобы сохранить целостность связей.
Чтобы избежать подобных проблем в будущем и не тратить время на ручное исправление, мы настоятельно рекомендуем использовать правильные подходы при создании копий информационных баз для обмена данными:
Использование процедуры "Информационная база перемещена".
При первом запуске скопированной или восстановленной информационной базы 1С обычно предлагает диалог, где вы можете выбрать, является ли база копией или перемещенной. Выбор опции "Информационная база перемещена" (при условии, что вы действительно хотите, чтобы эта база стала независимым участником обмена) инициирует внутренние процессы по генерации нового идентификатора информационной базы и разблокировке работы с внешними ресурсами. Для файловых баз этот процесс контролируется служебным файлом DoNotCopy.txt, в который записывается новый идентификатор.
Создание новой пустой базы с последующей загрузкой данных.
Наиболее надежный подход для создания нового участника обмена — это сначала создать совершенно новую, пустую информационную базу. После этого, при необходимости, можно загрузить в нее данные из существующей базы (например, через выгрузку/загрузку данных в формате XML или средствами конфигурации), вместо прямого копирования уже рабочей базы. Этот метод гарантирует уникальность всех системных идентификаторов новой базы.
Использование средств СУБД с последующей проверкой 1С.
Для клиент-серверных баз на PostgreSQL вы можете использовать стандартные средства СУБД для резервного копирования и восстановления, например, утилиту pg_dump для создания дампа базы данных. Однако даже после восстановления с помощью СУБД крайне важно убедиться в уникальности идентификаторов на уровне самой платформы 1С, используя методы, описанные выше (проверка констант и узлов обмена).
В некоторых более сложных случаях, когда обмен уже был настроен и возникли глубокие дублирования объектов, помимо изменения кода узла обмена, могут потребоваться дополнительные действия:
Регистр сведений "Соответствие объектов информационных баз".
Этот служебный регистр хранит уникальные идентификаторы объектов, которые участвуют в обмене данными между разными базами. Если у вас наблюдается дублирование элементов справочников, документов или других объектов, причиной может быть наличие одинаковых идентификаторов в этом регистре, связанных с разными физическими объектами. Для исправления ситуации может потребоваться ручное редактирование записей в этом регистре или использование специализированных обработок для его корректировки.
Использование внешних обработок для поиска и исправления UUID.
В сообществе 1С разработаны и доступны различные внешние обработки, которые позволяют находить и редактировать уникальные идентификаторы объектов и метаданных. Такие обработки могут быть очень полезны для диагностики и ручного исправления в сложных случаях, когда стандартные средства платформы не предоставляют достаточного функционала или проблема имеет глубокий характер. Всегда используйте такие обработки с осторожностью и только после полного резервного копирования.
Таким образом, хотя изменение кода узла обмена, как было успешно реализовано нашими коллегами, является эффективным решением для проблемы обмена между базами с дублирующимися идентификаторами, важно понимать, что это лишь один из аспектов управления уникальностью информационных баз 1С. Для предотвращения подобных ситуаций в будущем и для более глубокого решения проблемы всегда учитывайте рекомендованные подходы к созданию и управлению копиями информационных баз, а также механизмами их уникальной идентификации.