← На главную

При выполнении регламентной процедуры тестирования и исправления (ТиИ) информационной базы в режиме «Проверка логической целостности расширений конфигурации» администраторы и разработчики могут столкнуться со следующим диагностическим сообщением:

«Область данных: неразделенная. Вспомогательные данные не соответствуют текущим расширениям конфигурации. Объект метаданных: РегистрСведений.ТаблицыГруппДоступа. Обнаружена таблица расширения конфигурации InfoRgChngR34872X1 для объекта, неизмененного расширениями конфигурации».

При запуске процедуры в режиме исправления платформа сообщает: «Данные InfoRgChngR34872X1 перенесены в таблицу расширяемой конфигурации». Разберем детально внутренние механизмы платформы «1С:Предприятие 8.3», выясним, почему возникает такая ситуация, даже если указанный регистр не заимствован напрямую в расширение, и можно ли безопасно выполнять исправление на рабочей базе.

Техническая природа обнаруженной таблицы

Проанализируем системное наименование таблицы InfoRgChngR34872X1 на уровне СУБД:

1. Префикс InfoRg обозначает принадлежность к объекту метаданных Регистр сведений.
2. Суффикс ChngR указывает на то, что это внутренняя таблица регистрации изменений для механизмов планов обмена (обмена данными платформы 1С). Это не основная таблица с записями регистра, а таблица очереди изменений.
3. Индекс X1 (или X<n>) означает, что таблица была создана динамически для конкретного расширения конфигурации.

Таким образом, платформа сигнализирует не о повреждении пользовательских данных самого регистра РегистрСведений.ТаблицыГруппДоступа, а о наличии изолированной таблицы регистрации изменений, которая больше не сопоставлена с текущими метаданными подключенных расширений.

Причины возникновения несоответствия

Выясним причину, почему таблица была создана для объекта, который разработчик явно не включал в расширение:

1. Автоматическое расширение составных ссылочных типов. Начиная с платформы 8.3.20 (при режиме совместимости выше 8.3.19), ссылки вида ЛюбаяСсылка, СправочникСсылка и определяемые типы автоматически расширяются ссылочными типами, добавленными в подключенные расширения конфигурации. Если в расширении создан хотя бы один собственный справочник или документ, а в основной конфигурации у регистра есть реквизит с типом ЛюбаяСсылка (как в реквизите ТипТаблицы регистра РегистрСведений.ТаблицыГруппДоступа), платформа вынуждена автоматически перестраивать механизмы регистрации изменений для поддержки новых ссылочных типов.
2. «Осиротевшие» таблицы регистрации. Если расширение разрабатывалось на более ранней версии платформы, затем база обновлялась, расширение выгружалось, отключалось или изменялось без полной монопольной реструктуризации, связь между структурой расширения и вспомогательной физической таблицей изменений теряется. Платформа обнаруживает таблицу InfoRgChngR...X1, но по актуальным метаданным расширения регистр считается неизмененным.

Безопасность выполнения исправления

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

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

Пошаговый порядок исправления на рабочей базе

Разберем по шагам безопасный процесс устранения несоответствия:

1. Создание резервной копии. Обязательно выгрузим информационную базу в файл выгрузки (.dt) либо снимем полный дамп средствами СУБД (PostgreSQL, MS SQL Server). Это базовое правило перед любыми операциями ТиИ.
2. Обеспечение монопольного доступа. Завершим все активные пользовательские сеансы, фоновые и регламентные задания. Установим блокировку начала сеансов.
3. Запуск тестирования и исправления. В конфигураторе перейдем в меню Администрирование > Тестирование и исправление.... Выберем режим Тестирование и исправление (исправление). Установим флажок на пункте Проверка логической целостности расширений конфигурации. Начиная с платформы 8.3.24, при необходимости можно также отметить сопутствующую опцию Реструктуризация таблиц расширений конфигурации.
4. Контроль планов обмена. Поскольку исправление затрагивает таблицы регистрации изменений, после завершения ТиИ проверим узлы обмена (РИБ или синхронизацию с другими конфигурациями через БСП). В узлах обмена могут появиться дополнительные зарегистрированные изменения для отправки, что является нормальным поведением после объединения очередей изменений.

Рассмотрим также альтернативный вариант запуска через командную строку. Для пакетного исправления целостности расширений можно запустить Конфигуратор со следующим ключом:

1cv8.exe DESIGNER /IBConnectionString <СтрокаПодключения> /IBCheckAndRepair -ConfigurationExtensionsLogIntegrity

Параметр -TestOnly указывать не нужно, чтобы платформа сразу применила исправления к служебным таблицам базы данных.