← На главную

Проанализируем крайне неприятную и опасную ситуацию: в СУБД Microsoft SQL Server по какой-то причине отсутствует физическая таблица регистра сведений (например, dbo._InfoRgXXXX), однако в дереве метаданных Конфигуратора 1С этот регистр по-прежнему присутствует. При любой попытке удалить объект, выполнить реструктуризацию или обновить конфигурацию базы данных платформа аварийно завершает работу (происходит крэш) либо выдает критическую ошибку вида Invalid object name с кодом ошибки 42S02.

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

Почему возникает рассинхронизация и крэш платформы

Платформа 1С:Предприятие при операциях изменения или удаления объектов метаданных выполняет транзакционную проверку и реструктуризацию физических таблиц в СУБД. Если объект удаляется из дерева метаданных, платформа пытается обратиться к соответствующей таблице в SQL (для анализа данных или выполнения инструкции DROP TABLE). Когда таблица в базе физически отсутствует, СУБД возвращает ошибку отсутствия объекта, с которой механизм реструктуризации ряда версий платформы не может корректно справиться и аварийно завершает процесс.

Посмотрим на типовой стек ошибки из технологического журнала или системных сообщений:

Ошибка СУБД: Microsoft SQL Server Native Client: Invalid object name 'dbo._InfoRg12066'. HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02

Способ 1. Создание таблицы-заглушки в СУБД (Рекомендуемый метод)

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

1. Выясняем точное имя отсутствующей таблицы:

   Попробуем получить имя таблицы программным путем с помощью функции ПолучитьСтруктуруХраненияБазыДанных. Выполним следующий фрагмент кода во внешней обработке:

   Скопировать код

   
   СтруктураБД = ПолучитьСтруктуруХраненияБазыДанных();
   Отбор = Новый Структура;
   Отбор.Вставить("Метаданные", "РегистрСведений.ИмяПроблемногоРегистра");
   НайденныеСтроки = СтруктураБД.НайтиСтроки(Отбор);
   
   Если НайденныеСтроки.Количество() > 0 Тогда
       Сообщить("Имя таблицы в SQL: " + НайденныеСтроки[0].ИмяТаблицыХранения);
   КонецЕсли;
   

   Если прямое обращение через встроенный язык также приводит к аварийному завершению работы сеанса, определим имя таблицы через трассировку SQL Server Profiler, сбор расширенных событий (Extended Events) или по тексту ошибки в журнале регистрации и технологическом журнале.

2. Генерируем скрипт создания таблицы:

   Выгрузим файл конфигурации (.cf) из поврежденной базы через меню Конфигурация - Сохранить конфигурацию в файл. Развернем из этого файла новую чистую базу на SQL Server. В SQL Server Management Studio (SSMS) найдем в чистой базе созданную таблицу проблемного регистра, нажмем по ней правой кнопкой мыши и выберем пункт Script Table as - CREATE To - New Query Editor Window.

3. Создаем таблицу в рабочей базе:

   Сверим имя таблицы в скрипте с именем, которое зафиксировано в рабочей базе. Если имена совпадают (или если имя скорректировано под рабочую базу), выполним сгенерированный SQL-скрипт создания пустой таблицы в рабочей базе данных.

4. Завершаем обновление в Конфигураторе:

   Теперь, когда физическая таблица присутствует в SQL, откроем Конфигуратор рабочей базы, удалим ненужный объект метаданных и штатно обновим конфигурацию базы данных (клавиша F7). Платформа найдет таблицу, выполнит системные инструкции удаления и зафиксирует целостность метаданных.

Способ 2. Исправление метаданных через файловую базу и сравнение-объединение

Рассмотрим альтернативный способ, который помог автору вопроса восстановить базу без прямого написания DDL-скриптов в СУБД.

1. Создаем полный бэкап: обязательно делаем резервную копию базы данных средствами СУБД перед началом любых манипуляций.
2. Сохраняем конфигурацию: выгружаем файл конфигурации .cf из поврежденной SQL-базы.
3. Разворачиваем файловую копию: создаем новую пустую файловую информационную базу и загружаем в нее сохраненный файл .cf. В файловой базе принудительно удаляем проблемный регистр сведений из дерева метаданных и сохраняем изменения (F7).
4. Выгружаем исправленный файл: выгружаем из файловой базы новый .cf файл, в котором проблемный регистр уже отсутствует.
5. Сравнение и объединение: открываем поврежденную SQL-базу в Конфигураторе, переходим в меню Конфигурация - Сравнить, объединить с конфигурацией из файла и выбираем подготовленный исправленный .cf. Соглашаемся с удалением объекта и выполняем обновление базы данных.
6. Повторное добавление объекта: после успешного применения изменений создаем регистр заново в рабочей конфигурации с чистой структурой и обновляем конфигурацию базы данных.

Способ 3. Очистка незафиксированных изменений в таблице ConfigSave

Если падение Конфигуратора происходит сразу при открытии или попытке обновления из-за зависшей незавершенной реструктуризации, разберем сброс промежуточного состояния метаданных на уровне СУБД.

В базе данных 1С системная таблица ConfigSave хранит редактируемую, но еще не примененную к базе данных конфигурацию. Выполним команду в SQL Server Management Studio:

DELETE FROM ConfigSave;

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

Обязательные действия после восстановления

Проанализируем обязательные регламентные шаги после выполнения любых низкоуровневых исправлений структуры:

1. Перезапуск службы кластера 1С: останавливаем службу 1C:Enterprise 8.3 Server Agent, чтобы сбросить кэш метаданных кластера серверов.
2. Очистка серверного и локального кэша: удаляем содержимое служебных каталогов кэша на сервере (каталоги вида snccntx... в каталоге srvinfo) и пользовательские кэши на клиентских машинах.
3. Тестирование и исправление: запускаем в Конфигураторе утилиту Администрирование - Тестирование и исправление с установленными флагами Проверка логической целостности и Реструктуризация таблиц информационной базы.