Как отключить флаг модификации метаданных в УРБД 1С 7.7 и загрузить данные без обновления конфигурации?

← На главную

При работе с распределенными информационными базами (УРБД) в «1С:Предприятие 7.7» администраторы часто сталкиваются со следующей проблемой. В центральной базе (ЦБ) вносятся незначительные изменения в конфигурацию (например, добавляется реквизит справочника или правится модуль). В это же время на периферийных точках (ПБ) пользователи продолжают активно работать и выгружают файлы обмена. Когда эти файлы приходят в центральную базу, штатный механизм загрузки блокирует операцию, выдавая ошибку о том, что конфигурация была изменена и сначала необходимо обновить конфигурацию на периферийной базе.

Что делать, если периферийная точка в данный момент недоступна, а данные из нее необходимо загрузить в ЦБ прямо сейчас? В этой статье мы подробно разберем, как устроен механизм регистрации изменений метаданных в УРБД, и рассмотрим три проверенных способа обхода этой ошибки: от точечного редактирования базы данных до корректировки файлов обмена.

Выясняем причину: как УРБД контролирует соответствие метаданных

Прежде чем переходить к практическим действиям, проанализируем ситуацию и поймем, как «1С 7.7» определяет, что конфигурации баз различаются. В системе УРБД за регистрацию всех изменений отвечает специальная таблица регистрации изменений — 1SUPDTS (в DBF-версии это файл 1SUPDTS.dbf, а в SQL-версии — таблица _1SUPDTS).

Когда вы сохраняете изменения в Конфигураторе центральной базы, система автоматически делает записи в эту таблицу для каждой из существующих периферийных баз. Эти записи указывают, какие именно объекты метаданных были изменены. Ключевым признаком изменения самой структуры конфигурации (файла метаданных 1Cv7.md) является запись, у которой идентификатор объекта равен пустому значению.

Если периферийная база присылает свой пакет данных, а в ЦБ для этой базы числится незакрытый (непереданный) флаг изменения метаданных, система блокирует загрузку во избежание нарушения логической целостности. Наша задача — временно «обмануть» систему, показав ей, что конфигурации ЦБ и ПБ идентичны.

Важное предупреждение: Описанные ниже методы безопасны только в том случае, если изменения в конфигурации ЦБ были неструктурными (например, добавлены текстовые модули, печатные формы или несущественные реквизиты, не влияющие на существующие данные). Если вы удалили реквизиты, изменили типы данных или структуру регистров, ручной обход блокировки может привести к необратимому разрушению базы данных!

Решение 1: Прямое редактирование таблицы регистрации изменений 1SUPDTS

Это наиболее быстрый и надежный способ решения проблемы, который не требует распаковки и изменения самих файлов обмена. Мы удалим флаг изменения конфигурации непосредственно из базы данных ЦБ.

Рассмотрим пошагово, как это сделать:

Обязательно создаем резервную копию! Любые операции прямого редактирования таблиц базы данных несут в себе риски повреждения файлов. Перед началом работы выгоняем всех пользователей из базы и делаем архивную копию ЦБ.
Закрываем Конфигуратор и сессии «1С:Предприятие» в центральной базе.
В зависимости от того, на каком движке работает ваша база данных (файловый DBF или клиент-серверный MS SQL), выбираем соответствующий инструмент редактирования:

Вариант А: Для файловой базы (DBF)

Нам понадобится любой специализированный DBF-редактор (например, DBF Commander, DBF Navigator или аналогичный). Использовать Microsoft Excel категорически запрещено, так как он повреждает структуру заголовков файлов DBF при сохранении.

Открываем в DBF-редакторе файл 1SUPDTS.dbf, расположенный в каталоге базы данных ЦБ.
Находим строки, которые удовлетворяют двум условиям одновременно:
- В поле DBSIGN содержится трехсимвольный код вашей проблемной периферийной базы.
- В поле OBJID значение является пустым (в формате DBF пустое значение представляет собой строку из 9 пробелов: " ").
Аккуратно удаляем найденные строки из таблицы.
Сохраняем изменения и обязательно выполняем физическую упаковку таблицы (Pack), если ваш редактор поддерживает эту функцию, чтобы физически стереть помеченные на удаление записи.

Вариант Б: Для клиент-серверной базы (MS SQL)

Если ваша база развернута на MS SQL Server, задача упрощается. Нам не нужно монопольно блокировать файлы, достаточно выполнить один точечный SQL-запрос через SQL Server Management Studio (SSMS).

Открываем SSMS и подключаемся к вашему серверу баз данных.
Выбираем базу данных ЦБ и открываем редактор запросов.
Выполняем следующий запрос, который мгновенно очистит признаки изменения метаданных для конкретной периферийной точки:


-- Замените 'ПБ1' на трехсимвольный код вашей периферийной базы
DELETE FROM _1SUPDTS 
WHERE DBSIGN = 'ПБ1' 
  AND OBJID = '         ';

После удаления строк запускаем 1С:Предприятие в режиме «Монитор» или обычном режиме и выполняем загрузку файла обмена из ПБ. Система больше не увидит препятствий и успешно загрузит все документы и справочники.

Решение 2: Обход ошибки через редактирование файлов обмена

Если вы по каким-то причинам опасаетесь напрямую редактировать таблицы базы данных, мы можем пойти другим путем — скорректировать номера транзакций в самом пришедшем из периферии файле обмена.

В основе контроля версий УРБД лежит сверка номеров отправленных и полученных пакетов. Если ПБ присылает файл обмена, где номер подтверждения принятой конфигурации меньше, чем текущий актуальный номер версии конфигурации в ЦБ, возникает блокировка. Мы можем вручную «подделать» это подтверждение в файле обмена.

Разберем этот метод по шагам:

Для начала выполните штатную выгрузку данных из центральной базы (ЦБ) для нашей проблемной периферийной точки. Файл данных создавать не обязательно, нам нужен только сам факт генерации транзакции обмена.
Откройте полученный архив выгрузки из ЦБ (обычно это ZIP-архив с именем вида CP*.zip или аналогичным) и извлеките из него небольшой текстовый файл 1Cv77Dld.id.
Откройте этот файл в любом текстовом редакторе (например, Блокноте) и найдите строку, содержащую информацию о сессиях обмена. Она выглядит примерно так:
{"Download ID", "GUID", "Код_ПБ", "GUID", "Код_ЦБ", "GUID", "N|Код_ПБ"}
Здесь символ N — это число, обозначающее номер последней транзакции выгрузки из ЦБ. Запомните это число (допустим, это число 12).
Теперь возьмите проблемный архив обмена, пришедший из ПБ (тот самый, который отказывается загружаться), и извлеките из него файл данных 1Cv77Chs.dat.
Откройте этот файл в текстовом редакторе. Будьте осторожны, файл может быть очень большим, поэтому лучше использовать редакторы типа Notepad++ или AkelPad, которые легко справляются с большими файлами.
В самом начале файла (обычно в первых пяти строках) найдите секцию подтверждений Acknowledgements. Там будет строка вида:
{"M|Код_ЦБ"}
Где M — это номер версии конфигурации, которую «видит» периферийная база. Это число гарантированно будет меньше нашего числа N (например, там будет стоять 11).
Вручную замените число M на число N (в нашем примере меняем 11 на 12). Таким образом, мы сообщаем центральной базе, что периферия якобы уже «знает» о новой конфигурации.
Сохраните изменения в файле 1Cv77Chs.dat и запакуйте его обратно в ZIP-архив обмена ПБ.
Запустите загрузку измененного архива в ЦБ. Загрузка пройдет успешно и без ошибок.

Решение 3: Радикальный метод (Полное отключение УРБД)

Бывают ситуации, когда обмен заходит в полный тупик: базы рассинхронизировались настолько, что восстановить стандартный обмен стандартными средствами невозможно, а работать нужно срочно. В таком случае распределенную базу данных можно деинициализировать — превратить ее в обычную локальную базу. Это снимет любые ограничения на изменение конфигурации и загрузку сторонних данных.

Проанализируем процесс деинициализации базы данных:

Создаем полную копию базы данных (копируем весь каталог для DBF или делаем резервную копию средствами SQL Server).
В каталоге базы данных физически удаляем файлы, отвечающие за настройки обмена УРБД:
- 1SDBSET.DBF и его индекс 1SDBSET.CDX (хранят список информационных баз, участвующих в обмене).
- 1SDWNLDS.DBF и его индекс 1SDWNLDS.CDX (история загрузок и выгрузок пакетов).
- 1SUPDTS.DBF и его индекс 1SUPDTS.CDX (таблица регистрации изменений).
Теперь нам необходимо отредактировать заголовок базы данных. Для этого открываем файл 1SSYSTEM.DBF с помощью DBF-редактора.
Находим колонку (поле) с именем DBSETUUID. В распределенной базе это поле заполнено длинным 36-значным уникальным идентификатором GUID.
Полностью очищаем значение этого поля — удаляем все символы и заполняем поле пробелами.
Сохраняем изменения в файле 1SSYSTEM.DBF.
Запускаем Конфигуратор 1С. Обратите внимание, что в меню «Администрирование» пункт «Распределенная ИБ» теперь стал неактивным — база считает себя автономной.
Для того чтобы зафиксировать изменения, внесите любое мелкое, чисто косметическое изменение в конфигурацию (например, добавьте пробел в описание любого справочника) и сохраните конфигурацию.
Запустите базу данных в монопольном режиме. Программа автоматически переиндексирует таблицы и восстановит точку актуальности (ТА).

После проведения этой процедуры база становится полностью независимой. При необходимости вы можете заново настроить УРБД и создать новые периферийные базы, если это потребуется в будущем.

Резюме и рекомендации

Мы подробно рассмотрели особенности работы с компонентой УРБД в «1С 7.7» и изучили три эффективных метода решения проблемы с блокировкой загрузки из-за модификации метаданных. Подведем итоги:

Прямая зачистка 1SUPDTS — самый быстрый и изящный способ, не требующий лишних манипуляций с файлами обмена.
Корректировка файлов обмена — отличный вариант, если у вас нет прямого доступа к редактированию таблиц БД или вы боитесь нарушить целостность таблиц.
Деинициализация базы — радикальное решение, применяемое при глубоком сбое структуры распределенной системы.

Всегда помните золотое правило администратора 1С: перед выполнением любых низкоуровневых операций с базами данных обязательно делайте полную резервную копию!