В процессе эксплуатации систем на базе 1С:Предприятие 8.3 в связке с СУБД PostgreSQL администраторы иногда сталкиваются с критической ошибкой вида _const11847 does not exist. Эта проблема проявляется при попытке создания резервной копии информационной базы (через выгрузку .dt), при выполнении тестирования и исправления (ТиИ) или даже при попытке открыть конкретный объект в режиме «1С:Предприятие». Ситуация осложняется тем, что сама база может оставаться условно рабочей, но её обслуживание становится невозможным.
В данной статье мы подробно разберем, почему возникает это рассогласование, как диагностировать проблему и какими методами можно восстановить работоспособность базы данных, сохранив при этом все накопленные сведения.
Для начала проанализируем ситуацию с технической точки зрения. Ошибка прямо указывает на то, что на уровне СУБД PostgreSQL отсутствует таблица, которую платформа 1С ожидает увидеть согласно своим внутренним метаданным. Рассмотрим основные причины такого поведения системы:
rphost или аварийная перезагрузка сервера СУБД, транзакция в PostgreSQL могла откатиться, в то время как 1С зафиксировала изменение в таблице метаданных Config.Прежде чем приступать к «лечению», нам необходимо точно выяснить, какому объекту метаданных соответствует проблемная таблица _const11847. Выясним это, используя встроенные возможности платформы.
Рассмотрим программный метод получения структуры хранения. Для этого можно создать внешнюю обработку и выполнить следующий код:
Структура = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Строка Из Структура Цикл
Если Строка.ИмяТаблицыХранения = "_const11847" Тогда
Сообщить("Объект найдем: " + Строка.ИмяМетаданных);
КонецЕсли;
КонецЦикла;
Также мы можем воспользоваться меню «Функции для технического специалиста» (в старых версиях — «Все функции»). Если при попытке открыть конкретную константу (например, СинхронизироватьДанныеСПриложениемВИнтернете...) система выдает ту же самую ошибку — объект идентифицирован верно.
Проанализируем ситуацию: возможно, таблица физически существует, но 1С не может корректно к ней обратиться. Первым делом выполним стандартную административную процедуру:
%ProgramData%\1C\1cv8\srvinfo для Windows или /home/usr1cv8/.1cv8/ для Linux).Если очистка кэша не помогла, значит, мы имеем дело с реальным отсутствием таблицы в PostgreSQL.
Если база данных находится в эксплуатации и возможности откатиться на бэкап пятимесячной давности нет, рассмотрим самый эффективный метод восстановления структуры. Суть заключается в том, чтобы заставить 1С создать новую физическую таблицу и связать её с существующим объектом метаданных.
Разберем по шагам:
Удалить_КлонКонстанты) с тем же типом данных, что и проблемная (в нашем примере — Булево)._const22500.psql) и выполнить SQL-запрос для определения имен полей новой таблицы._const11847). Используем команду ALTER TABLE:
-- Переименовываем саму таблицу
ALTER TABLE _const22500 RENAME TO _const11847;
-- Если в таблице есть поля (а они есть), их также нужно привести
-- в соответствие с ожидаемыми. Обычно это _fldXXXX.
-- Посмотреть точные имена можно через Information_Schema.
После того как мы переименовали таблицу в СУБД, 1С «увидит» её при обращении к оригинальной константе. Теперь мы можем вернуться в Конфигуратор и удалить созданный нами «клон» — он больше не нужен, так как мы восстановили физическую сущность для основного объекта.
Рассмотрим еще один вариант, который часто применяют опытные администраторы баз данных. Если мы знаем структуру полей (её можно подсмотреть в аналогичной рабочей базе или через функцию ПолучитьСтруктуруХраненияБазыДанных()), мы можем создать пустую таблицу напрямую в PostgreSQL.
Для константы типа Булево структура обычно очень простая. Примерный SQL-запрос может выглядеть так:
CREATE TABLE _const11847 (
_fld11847_type bytea,
_fld11847_rttr bytea,
_fld11847_boolean boolean
);
-- Права доступа должны принадлежать пользователю, под которым 1С подключается к базе
ALTER TABLE _const11847 OWNER TO "v8_user";
После создания пустой таблицы необходимо запустить 1С в режиме Тестирование и исправление с галочкой «Создавать объекты при наличии ссылок на несуществующие». Платформа сама инициализирует запись в этой таблице значением по умолчанию.
В современных версиях платформы (начиная с 8.3.15) доступна утилита командной строки ibcmd. Она позволяет выполнять проверку целостности базы данных на уровне серверных структур.
Проанализируем возможность использования команды:
ibcmd infobase --db-type=PostgreSQL --db-server=localhost --db-name=my_db dump --file=base.dt
Иногда запуск выгрузки через ibcmd позволяет обойти некоторые ошибки графического интерфейса Конфигуратора или получить более детальный лог того, на каком именно этапе происходит сбой обращения к СУБД.
Проанализируем риски: любое прямое вмешательство в таблицы СУБД через SQL-запросы может привести к потере целостности, если вы не уверены в своих действиях. Поэтому:
pg_dump) перед началом любых манипуляций. Даже «сломанная» база в дампе лучше, чем окончательно уничтоженная база после неудачных правок.Таким образом, проблема отсутствия физической таблицы при наличии метаданных решается путем восстановления соответствия между логическим уровнем 1С и физическим уровнем СУБД. Выбирайте наиболее подходящий метод в зависимости от ваших навыков и прав доступа к системе.