Настройка распределенных информационных систем и интеграции между различными конфигурациями «1С:Предприятие» — стандартная задача для администраторов и программистов. Однако при развертывании сложных связок (например, одной базы «1С:Управление нашей фирмой» и нескольких баз «1С:Бухгалтерия предприятия») специалисты часто сталкиваются с труднообъяснимыми ошибками на этапе создания подключения.
В этой статье мы подробно разберем одну из самых коварных ошибок синхронизации, которая парализует обмен данными: «Значение поля "Код" не уникально». Мы выясним глубинную причину этого сбоя, проанализируем, почему стандартное копирование баз приводит к системным конфликтам, и рассмотрим правильный, безопасный алгоритм решения проблемы.
Рассмотрим классический сценарий. В ИТ-ландшафте предприятия развернуты три новые информационные базы актуальных версий: одна база «1С:Управление нашей фирмой» (УНФ) и две абсолютно идентичные базы «1С:Бухгалтерия предприятия» (БП1 и БП2), отличающиеся только ведущимися в них организациями. Всем базам корректно назначены индивидуальные префиксы.
Синхронизация между УНФ и первой базой БП1 настраивается через прямое соединение без каких-либо затруднений. Однако при попытке настроить аналогичное прямое подключение между УНФ и второй базой БП2 система моментально выдает ошибку уникальности кода. При настройке обмена через универсальный формат (Enterprise Data) ошибка может проявиться на этапе загрузки данных в базу-приемник.
В журнале регистрации и на экране пользователя появляется следующее диагностическое сообщение:
{ОбщийМодуль.ОбменДаннымиСервер.Модуль(8978)}: Ошибка при вызове метода контекста (Записать)
УзелОбменаОбъект.Записать();
по причине:
Значение "27c67872-c2d2-46f9-bb6b-3c5d15234377" поля "Код" не уникально
Попытки найти указанный идентификатор (GUID) через стандартный поиск ссылок или специализированные обработки в составе конфигурации не приносят результатов. На первый взгляд кажется, что этого идентификатора физически нет ни в одном справочнике или документе ни одной из баз данных.
Чтобы понять, откуда берется загадочный GUID, проанализируем внутренние механизмы Библиотеки стандартных подсистем (БСП), на базе которой построены все современные конфигурации 1С. Выясним, как именно платформа идентифицирует участников обмена данными.
Каждая информационная база при первом запуске генерирует свой уникальный глобальный идентификатор. Этот GUID записывается в системную константу ИдентификаторИнформационнойБазы. Когда мы инициируем создание новой синхронизации, происходят следующие процессы:
ИдентификаторИнформационнойБазы.Почему же у двух разных рабочих баз (БП1 и БП2) оказался один и тот же уникальный идентификатор? Ответ кроется в способе создания этих баз. В подавляющем большинстве случаев вторая база создается простым копированием первой (через создание резервной копии СУБД, копирование файла 1Cv8.1CD или развертывание из общего бэкапа).
Вместе с таблицами данных из БП1 в БП2 полностью копируется и значение константы ИдентификаторИнформационнойБазы. Для платформы и механизмов БСП эти две базы остаются абсолютно одинаковыми «близнецами», несмотря на то, что в них изменены названия организаций, ИНН и префиксы документов.
Когда УНФ пытается подключить вторую бухгалтерию, она считывает из нее тот же самый GUID, который уже был записан в плане обмена для первой бухгалтерии. Система пытается создать дублирующий узел в плане обмена, что приводит к закономерному отказу.
В процессе поиска решения некоторые специалисты прибегают к обходным путям. Например, находят узел плана обмена в базе-приемнике и с помощью специализированных обработок изменяют код узла вручную (добавляя к нему единицу или меняя один символ в GUID).
Рассмотрим, почему такой подход крайне опасен и какие скрытые угрозы он в себе несет:
Единственным архитектурно верным решением является генерация нового уникального идентификатора для скопированной базы данных. Это позволит сделать ее полноценной, независимой системой в ИТ-окружении предприятия. Выполним эту процедуру по шагам.
Шаг 1. Очистка несостоявшихся настроек обмена
Перед началом исправления технического идентификатора необходимо полностью удалить все зависшие, недонастроенные или созданные с ошибками синхронизации как в управляющей базе (УНФ), так и в скопированной базе (БП2). Перейдите в раздел «Администрирование» — «Синхронизация данных» — «Настройки синхронизации» и удалите сбойные подключения.
Шаг 2. Генерация нового уникального идентификатора базы
Нам необходимо перезаписать значение системной константы в скопированной базе (БП2). Для этого запустите БП2 в режиме «1С:Предприятие» под пользователем с административными правами. Откройте обработку «Групповое изменение реквизитов» (или любую другую обработку, позволяющую выполнять произвольный код на встроенном языке) и выполните следующий код:
НовыйИдентификатор = Новый УникальныйИдентификатор();
Константы.ИдентификаторИнформационнойБазы.Установить(Строка(НовыйИдентификатор));
ЗаписьЖурналаРегистрации("СменаИдентификатора", УровеньЖурналаРегистрации.Информация,,, "Идентификатор базы успешно изменен на: " + Строка(НовыйИдентификатор));
Если вы хотите выполнить процедуру максимально аккуратно, можно просто очистить эту константу, записав в нее пустую строку:
Константы.ИдентификаторИнформационнойБазы.Установить("");
При следующем обращении к любым функциям обмена Библиотека стандартных подсистем обнаружит отсутствие идентификатора, автоматически сгенерирует новый корректный GUID по стандартам платформы и запишет его в базу данных.
Шаг 3. Учет режима копии информационной базы
Обратите внимание на важную особенность поведения платформы «1С:Предприятие 8.3». При первом запуске базы данных, перенесенной на другой сервер или восстановленной из резервной копии, БСП выводит диалоговое окно с вопросом: «Информационная база была перемещена или восстановлена из резервной копии?».
Если вы нажимаете кнопку «Это копия информационной базы», система блокирует все регламентные задания и внешние подключения, чтобы копия не отправляла реальные данные внешним контрагентам и не портила рабочие обмены. Если вы нажимаете кнопку «Информационная база перемещена», блокировки снимаются, но константа идентификатора сохраняет свое старое значение. Именно поэтому при создании новой рабочей базы на основе копии ручное обновление константы через приведенный выше код является обязательным.
Шаг 4. Очистка кэша сервера и клиентских приложений
В клиент-серверном варианте работы (под управлением MS SQL Server или PostgreSQL) сервер приложений «1С:Предприятие» активно кэширует конфигурацию, значения констант и структуру планов обмена. Чтобы изменения вступили в силу немедленно и без сбоев, настоятельно рекомендуется выполнить следующие действия:
1C:Enterprise 8.3 Server Agent).reg_1541 на сервере приложений).Шаг 5. Повторная настройка синхронизации
После генерации нового идентификатора и очистки кэша вернитесь в базу «1С:Управление нашей фирмой» и запустите мастер создания новой синхронизации данных с «1С:Бухгалтерия предприятия» (БП2). Система обратится к БП2, считает абсолютно новый, уникальный GUID, успешно создаст под него узел в плане обмена и запишет его без конфликтов уникальности.
Соблюдение этого простого и правильного регламента при копировании информационных баз позволит вам избежать множества труднодиагностируемых ошибок и обеспечит стабильную, бесперебойную работу распределенной ИТ-системы вашего предприятия.