При работе с клиент-серверными базами «1С:Предприятие 8.3» на платформе MS SQL Server администраторы часто сталкиваются с критической ошибкой при попытке выгрузки информационной базы в файл *.dt или при запуске процедуры «Тестирование и исправление». Ошибка выглядит следующим образом: «Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Недопустимое имя объекта "dbo._RefSInfXXXXX"». В этой статье мы подробно разберем природу этого явления, выясним причины его возникновения и рассмотрим пошаговые методы восстановления работоспособности базы данных.
Для начала проанализируем ситуацию: что именно представляют собой таблицы с префиксом _RefSInf? В архитектуре 1С эти таблицы (Predefined Data Initialization Info) отвечают за хранение информации о состоянии инициализации предопределенных данных для различных объектов метаданных — справочников, планов видов характеристик, планов счетов и других. Когда платформа обращается к объекту, она проверяет наличие соответствующей записи в этой служебной таблице.
Рассмотрим причины исчезновения данных объектов. Проблема носит массовый характер и связана с зарегистрированными ошибками платформы (например, 70087249 и 70086815). Эти ошибки проявляются в версиях платформ 8.3.23, 8.3.24 и 8.3.25. Суть бага заключается в том, что в процессе реструктуризации таблиц или при обновлении конфигурации платформа ошибочно помечает эти служебные таблицы как пустые или ненужные и удаляет их из физической схемы SQL-сервера. Однако в системных таблицах самой 1С (таблица Config, поле DBSchema) информация о том, что эти таблицы должны существовать, сохраняется. Это приводит к диссонансу: логическая структура 1С требует наличия таблицы, а физическая структура MS SQL её не находит.
Важный момент: простое обновление платформы на исправленный релиз предотвратит удаление таблиц в будущем, но не восстановит те, что уже были удалены. Поэтому нам потребуется ручное или программное вмешательство.
Если количество «потерянных» таблиц велико, наиболее эффективным способом будет их прямое создание в консоли MS SQL Management Studio. Разберем, как вычислить недостающие объекты и создать их.
Для начала нам необходимо понять, какие именно таблицы отсутствуют. Если у вас есть архивная копия базы, в которой выгрузка еще работала, мы можем сравнить составы таблиц рабочей базы и копии. Проанализируем следующий скрипт, который выводит список недостающих таблиц:
-- Сравнение состава таблиц между рабочей базой и копией
USE [Имя_Вашей_Копии];
GO
SELECT TABLE_NAME INTO #TablesInCopy
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE';
USE [Имя_Вашей_Рабочей_Базы];
GO
SELECT TABLE_NAME INTO #TablesInWork
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE';
-- Вывод имен таблиц, которые есть в копии, но отсутствуют в рабочей базе
SELECT TABLE_NAME
FROM #TablesInCopy
WHERE TABLE_NAME NOT IN (SELECT TABLE_NAME FROM #TablesInWork)
AND TABLE_NAME LIKE '_RefSInf%';
DROP TABLE #TablesInCopy;
DROP TABLE #TablesInWork;
После того как список получен, нам нужно создать эти таблицы. Структура таблиц _RefSInf обычно включает поле _PDInitialized (тип binary(1)) и иногда дополнительные поля реквизитов, если они используются для инициализации. Рассмотрим пример скрипта для ручного создания одной такой таблицы:
USE [Имя_Вашей_Рабочей_Базы];
GO
IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = '_RefSInf17911')
BEGIN
CREATE TABLE dbo._RefSInf17911 (
[_PDInitialized] binary(1) NOT NULL,
[_Fld11192] numeric(7, 0) NOT NULL -- Имя поля может отличаться, проверьте структуру в копии!
);
END;
GO
Обратите внимание: состав колонок (имена полей _FldXXXX) должен строго соответствовать ожидаемому платформой. Рекомендуется подсматривать точные имена полей в архивной копии или через запуск «Тестирования и исправления», которое в протоколе может выдать ошибку с указанием недостающего поля.
Если вы не хотите работать напрямую с SQL, можно заставить платформу 1С пересоздать таблицы штатными средствами. Этот метод эффективен, когда объектов немного. Рассмотрим алгоритм действий:
ПолучитьСтруктуруХраненияБазыДанных() в обработке или посмотреть соответствие в таблице DBSchema._RefSInf, создаст их заново.Этот способ позволяет восстановить структуру без риска ошибиться в типах данных SQL-полей, так как платформа сама сформирует правильный запрос к СУБД. Для быстрого сопоставления служебных таблиц СУБД с объектами метаданных можно использовать обработку для анализа структуры хранения базы данных.
Существует еще один метод, который помогает восстановить таблицы инициализации программным путем. Мы можем воспользоваться встроенным языком 1С, чтобы инициировать процедуру обновления для конкретных метаданных. Рассмотрим пример кода, который можно запустить во внешней обработке:
// Для конкретного справочника
МетаданныеОбъекта = Метаданные.Справочники.Банки;
УстановитьОбновлениеПредопределенныхДанных(МетаданныеОбъекта, ОбновлениеПредопределенныхДанных.Автоматически);
Справочники.Банки.ОбновитьПредопределенныеДанные();
// Или для всей базы сразу (может занять время)
// ОбновитьПредопределенныеДанные();
После выполнения данного кода платформа попытается актуализировать записи в таблицах _RefSInf. Если физически таблицы отсутствуют, система может выдать ошибку, но в ряде случаев это инициирует корректное пересоздание структуры.
Для того чтобы ситуация не повторилась, выполним следующие шаги:
.bak), так как выгрузка в .dt может не сработать уже после начала процесса.Invalid object name, значит, ваша текущая платформа подвержена багу.Подводя итог, отметим, что проблема с таблицами _RefSInf является следствием технического несовершенства определенных релизов платформы. Сочетание ручного восстановления структуры через SQL и последующего обновления платформы до актуального стабильного релиза позволяет полностью устранить ошибку и вернуть базу в штатный режим работы. Для комплексной проверки корректности работы базы данных на стороне СУБД можно использовать инструмент для чек-апа и диагностики СУБД под 1С.