При активной работе с расширениями в платформе 1С:Предприятие 8.3 разработчики часто сталкиваются со специфическими механизмами СУБД, которые платформа использует для изоляции и интеграции данных расширений. Одним из наиболее опасных и неприятных сбоев является внезапное исчезновение таблиц с суффиксом X1 (например, _Reference374X1) и последующая блокировка базы данных ошибкой: «Попытка переключить менеджер имен базы данных без сохранения информации». При этом ни обновить конфигурацию, ни вернуться к конфигурации базы данных стандартными средствами конфигуратора становится невозможно.
В этой статье мы подробно разберем, почему возникает эта проблема, как устроен механизм таблиц расширений в MS SQL Server, и рассмотрим пошаговые сценарии спасения базы данных и восстановления утерянных данных.
---
Когда мы заимствуем объект метаданных (например, справочник Организации) из основной конфигурации в расширение и добавляем ему новый реквизит или табличную часть, платформа 1С не просто добавляет новую колонку в существующую физическую таблицу СУБД. Платформа полностью перестраивает хранение данных для этого объекта:
X1. Например, если основная таблица справочника имела имя _Reference374, то для расширения создается таблица _Reference374X1, а также аналогичные таблицы для всех его табличных частей (например, _Reference374_VT56976X1)._Reference374 во вновь созданную таблицу _Reference374X1._Reference374 очищается (или удаляется), а платформа на уровне ядра перенаправляет все запросы приложения (как на чтение, так и на запись) к новой таблице с суффиксом X1.X1 в основную таблицу, после чего удалить структуру X1.Сбой происходит в тот момент, когда в процессе обновления (реструктуризации) базы данных транзакция прерывается или завершается аварийно. В этот момент физические таблицы X1 могут быть удалены СУБД, но в служебных таблицах 1С (таких как params и config, где хранится так называемый Менеджер имен базы данных) остается запись о том, что данные должны находиться именно в таблицах с суффиксом X1. Возникает критическая рассинхронизация метаданных и физической структуры СУБД.
---
Если база данных уже находится в заблокированном состоянии и выдает ошибку HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, Недопустимое имя объекта "dbo._Reference374X1", нам потребуется восстановить отсутствующие таблицы непосредственно в MS SQL Server. Выясним последовательность действий по шагам.
Шаг 1. Поиск структуры оригинальных таблиц. Для воссоздания структуры утерянных таблиц нам понадобится их точное описание. Проще всего получить его из резервной копии этой же базы (или из рабочей базы, если сбой произошел на копии). Зайдите в SQL Server Management Studio (SSMS) живой базы, найдите целевую таблицу (например, _Reference374X1) и связанные с ней таблицы табличных частей (например, _Reference374_VT56976X1). Для быстрого сопоставления объектов метаданных с именами таблиц в СУБД можно использовать обработку для анализа структуры хранения базы данных.
Нажмите на таблицу правой кнопкой мыши и выберите пункт Script Table as -> CREATE To -> New Query Editor Window. Вы получите готовый SQL-скрипт создания структуры таблицы со всеми индексами и ограничениями.
Шаг 2. Создание таблиц в поврежденной базе. Выполните сгенерированные скрипты CREATE TABLE в контексте поврежденной базы данных. Обратите внимание, что вам необходимо создать всю цепочку утерянных таблиц (как самого справочника, так и всех его табличных частей, которые были затронуты расширением).
После создания пустых таблиц перезапустите Конфигуратор 1С. Попытка обновления конфигурации базы данных теперь должна пройти успешно, так как физические объекты снова на месте.
Шаг 3. Перенос утерянных данных. На данном этапе база успешно запустится, однако заимствованный справочник (в нашем примере — Организации) окажется абсолютно пустым, так как мы создали новые пустые таблицы. Чтобы вернуть данные из резервной копии или рабочей базы, выполните перенос данных с помощью SQL-скрипта:
-- Создаем временную хранимую процедуру для безопасной выгрузки данных
CREATE PROCEDURE dbo.myproc_restore
AS
SET NOCOUNT ON;
SELECT TOP (1000000) *
FROM [РабочаяБаза].[dbo].[_Reference374X1]
GO
-- Наполняем восстановленную таблицу в тестовой базе данными из рабочей
INSERT INTO [ТестоваяБаза].[dbo].[_Reference374X1]
EXECUTE [dbo].myproc_restore
GO
-- Удаляем временную хранимую процедуру после успешного переноса
DROP PROCEDURE IF EXISTS [dbo].myproc_restore
GO
Аналогичную операцию необходимо проделать для всех связанных таблиц табличных частей справочника. После этого данные в вашей базе будут полностью восстановлены.
---
Начиная с версии платформы 8.3.15, по умолчанию используется оптимизированный двухфазный механизм реструктуризации (v2). Именно его внутренняя логика зачастую инициирует некорректное удаление таблиц X1 при малейших сетевых микросбоях. Мы можем принудительно заставить платформу выполнить обновление старым, максимально стабильным и проверенным временем методом.
Для этого запустите конфигуратор из командной строки с явным указанием параметра совместимости реструктуризации:
"C:\Program Files\1cv8\8.3.17.1386\bin\1cv8.exe" DESIGNER /F "ПутьКВашейБазе" /ConfigurationDbStructureMergeMode Standard
Параметр /ConfigurationDbStructureMergeMode Standard заставит платформу выполнить обновление в режиме совместимости со старыми релизами. В этом режиме реструктуризация таблиц расширений выполняется прямолинейно, без фонового переключения менеджера имен, что гарантирует успешное завершение операции обновления.
---
Если конфигуратор намертво заблокирован ошибкой менеджера имен и не позволяет удалить расширение или обновить базу метаданных, попробуйте сбросить блокировку через пользовательский интерфейс:
---
Иногда менеджер имен «застревает» в промежуточном состоянии, когда физические таблицы СУБД существуют, но платформа отказывается сопоставлять их из-за рассинхронизации кэша. Проанализируем, как заставить платформу полностью пересчитать всю карту метаданных:
ВременнаяКонстантаДляСбросаКэша или пустой справочник.F7).params.---
Для того чтобы обезопасить себя от подобных критических сбоев при работе с расширениями в будущем, рекомендуем придерживаться нескольких простых правил разработки:
Организации, Контрагенты, Номенклатура), лучше отказаться от расширений и выполнить эту задачу классическим способом — через редактирование основной конфигурации на поддержке с сохранением возможности изменения. Это убережет базу данных от создания сложных конструкций с префиксами X1 и минимизирует риски потери важных бизнес-данных.