Как исправить ошибку SQL Server «Не удалось найти объект dbo._Document591X1Z» при обновлении 1С

При переходе на новые версии платформы (например, 8.3.27.1989) и обновлении конфигураций (ЗУП КОРП 3.1 и другие) специалисты часто сталкиваются с критической ошибкой Microsoft OLE DB Driver: Не удалось найти объект "dbo._DocumentNNNX1Z". Эта проблема блокирует процесс реструктуризации базы данных и может привести к простою системы. В данной статье мы подробно разберем, почему возникают таблицы с таким суффиксом, и как восстановить работоспособность базы данных.

Разберем природу ошибки: что такое таблицы с суффиксом X1Z

Для начала проанализируем, как 1С работает с данными на уровне SQL-сервера. Когда мы создаем расширение и добавляем в него новые реквизиты для существующих объектов (документов, справочников), платформа не меняет основную таблицу (например, _Document591). Вместо этого она создает дополнительную таблицу для хранения данных расширения.

Рассмотрим структуру именования:

1. _Document591 — основная таблица объекта в базе данных SQL.
2. _Document591X1 — таблица первого расширения, где хранятся его данные.
3. _Document591X1Z — временная таблица, создаваемая платформой 1С исключительно в момент реструктуризации (обновления конфигурации). Буква Z в конце указывает на то, что это промежуточный объект, в который переносятся данные перед окончательной модификацией схемы.

Выясним причину ошибки: если платформа сообщает, что объект не найден, это означает, что в служебных таблицах метаданных (например, Config или DBSchema) запись о необходимости использования этой таблицы есть, но фактически в базе SQL она либо не создалась из-за сбоя, либо была удалена преждевременно. Часто это происходит из-за некорректного завершения «динамического обновления» или конфликтов в хранилище расширений.

Способ 1: Принудительное обновление метаданных расширений

Самый простой и зачастую самый эффективный метод — заставить платформу заново пересчитать структуру всех расширений. Рассмотрим этот процесс по шагам:

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

1. Внесем любое несущественное изменение (например, добавим пробел в комментарии к расширению).
2. Нажмем кнопку «Обновить конфигурацию базы данных» (F7).
3. Согласимся с изменениями.

Зачем это нужно? При таком действии 1С инициирует сверку описания метаданных в расширении с физической схемой таблиц в SQL. Если таблицы X1 отсутствовали, платформа попытается создать их заново, опираясь на текущее состояние расширения.

Способ 2: Тестирование и исправление (ТиИ)

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

Нам необходимо отметить следующие пункты:

• Проверка логической целостности конфигурации.
• Проверка ссылочной целостности.
• Реструктуризация таблиц информационной базы.

Важный нюанс: если при запуске ТиИ сразу вылетает ошибка Не удалось найти объект...X1Z, значит, проблема закралась в саму таблицу DBSchema. В этом случае реструктуризация через ТиИ может не запуститься, и нам придется прибегнуть к более радикальным методам.

Способ 3: Очистка кэша и работа с хранилищем

Как отмечают участники обсуждения, проблема часто обостряется, если конфигурация или расширения подключены к хранилищу. Перед обновлением рекомендуется:

1. Отключить все расширения от хранилища.
2. Очистить локальный кэш конфигуратора на рабочем сервере и клиентской машине.
3. Попробовать выполнить обновление конфигурации базы данных.

Проанализируем ситуацию с динамическими обновлениями. Если вы «злоупотребляли» демоническими обновлениями (обновление без выгона пользователей), в таблице ConfigCAS могли накопиться некорректные версии расширений. Полная очистка временных файлов 1С на сервере (папка srvinfo) часто помогает платформе «увидеть» актуальную структуру таблиц SQL.

Способ 4: Выгрузка и загрузка в формате .dt

Если база данных находится в состоянии, когда ни реструктуризация, ни обновление расширений не проходят, попробуем метод «пересборки» всей базы:

1. Создадим резервную копию.
2. Выполним выгрузку информационной базы в файл .dt.
3. Создадим новую пустую базу в SQL Server.
4. Загрузим .dt в новую базу.

При загрузке из .dt платформа 1С создает структуру таблиц SQL «с нуля», основываясь только на описании метаданных. Это позволяет исключить любые «фантомные» ссылки на таблицы X1Z, которые остались в старой базе из-за сбоев SQL. Если же ошибка возникает даже на этапе выгрузки в .dt, это сигнализирует о глубоком повреждении таблицы Config.

Анализ системных объектов: Идентификаторы объектов метаданных

Обратим внимание на критическую ошибку, упомянутую в обсуждении. Если расширение затрагивает системный справочник ИдентификаторыОбъектовМетаданных (таблица _Reference176 в примере), это может привести к фатальным последствиям.

Почему это опасно? Справочник идентификаторов используется платформой для сопоставления объектов 1С с их внутренними ID. Если расширение пытается добавить в него реквизиты, возникает «зацикливание»: чтобы обновить расширение, нужно обновить справочник идентификаторов, но чтобы обновить этот справочник, нужно корректно инициализировать расширение.

Посмотрим на пример того, как проверить, какие объекты расширены, через запрос к SQL (только для чтения!):

SELECT * 
FROM dbo.DBSchema 
WHERE [Name] LIKE '%X1Z%'

Если запрос возвращает записи, а таблицы физически нет — мы нашли подтверждение рассинхронизации.

Чего ни в коем случае нельзя делать

Рассмотрим вопрос автора о ручном создании таблиц dbo._Document591X1Z. Никогда не создавайте эти таблицы вручную через SQL Management Studio!

Причины:

• Вы не знаете точного состава полей (имена колонок типа _Fld1234 генерируются платформой динамически).
• Типы данных в SQL могут не соответствовать ожидаемым типам 1С (например, составные типы).
• Это не решит проблему, так как после успешной (по мнению SQL) операции платформа попытается удалить эту таблицу или переименовать её, что приведет к новым конфликтам блокировок.

Итоговые рекомендации

Для успешного перехода на платформу 8.3.27 и выше при наличии большого количества расширений, придерживайтесь следующего алгоритма:

1. Перед обновлением основной конфигурации примените все изменения расширений и убедитесь, что база находится в стабильном состоянии.
2. Если ошибка X1Z возникла, попробуйте поочередно отключать расширения (снимать флаг «Использовать»), чтобы вычислить проблемный объект.
3. Проверьте, не расширяются ли системные справочники. Если это так, перенесите эти данные в новые собственные объекты расширения.
4. Используйте метод выгрузки/загрузки .dt как наиболее надежный способ нормализации схемы данных SQL.