Проанализируем крайне неприятную ситуацию, с которой сталкиваются многие разработчики: при обновлении расширения происходит сбой, и конфигуратор 1С аварийно закрывается. После этого возникает проблема: мы можем зайти в Конфигуратор, но попытки открыть режим Предприятия (под любым пользователем) приводят к ошибке «Нарушение прав доступа!» или «Пользователь ИБ не идентифицирован».
Если мы попытаемся продолжить работу в Конфигураторе, то любые действия с расширениями (удаление, добавление, отключение галочек) приводят к появлению пустого окна с кнопками «Закрыть» и «Перезагрузить». Штатное тестирование и исправление (проверки целостности расширений и реструктуризации) также выдают пустые ошибки, а выгрузка базы в формат .dt перестает работать. Разберем по шагам, почему это происходит и как восстановить работоспособность информационной базы.
Сбой возникает из-за того, что транзакция обновления расширения прервалась некорректно. В служебных таблицах базы данных платформа ставит специальную отметку о начале реструктуризации. Если конфигуратор завершил работу аварийно (из-за переполнения журнала транзакций на сервере СУБД, нехватки места на диске или сетевого сбоя), этот статус остается «зависшим».
В итоге при каждой попытке запуска сеанса 1С в режиме Предприятия, платформа видит этот незавершенный статус и не может корректно считать структуру метаданных, а также актуальные права пользователей. Из-за этого доступ полностью блокируется. Пустые окна при попытках выгрузки базы или тестирования — это прямые следствия заблокированной структуры.
Самое эффективное решение этой проблемы в клиент-серверном варианте (MS SQL Server или PostgreSQL) заключается в ручной очистке зависшего статуса обновления в системных таблицах. Перед выполнением любых манипуляций с базой на уровне СУБД настоятельно рекомендуем остановить службу сервера 1С и сделать полный бекап базы данных средствами самого SQL-сервера.
Нам понадобятся таблицы SchemaStorage (хранит версии схем метаданных) и таблица Config. Прямым SQL-запросом мы принудительно вернем статус схемы в нормальное, рабочее состояние и очистим «хвосты» зависшей транзакции динамического обновления.
Откроем SQL Server Management Studio или pgAdmin и выполним следующий скрипт:
USE [ИмяВашейБазы];
-- Возвращаем рабочий статус схеме метаданных
UPDATE SchemaStorage SET Status = 100;
-- Удаляем записи, оставшиеся от неудачной транзакции применения конфигурации/расширений
DELETE FROM Config WHERE FileName = 'commit';
DELETE FROM Config WHERE FileName = 'dbStruFinal';
Выполнение команды UPDATE SchemaStorage SET Status = 100 принудительно снимает блокировку незавершенной реструктуризации. Удаление записей с именами commit и dbStruFinal очищает кэш незавершенного применения изменений. Как подтверждает практика, после этого конфигуратор снова начнет работать с расширениями, и база успешно запустится.
Если у вас нет прямого доступа к SQL или сбой носит менее критичный характер, давайте попробуем удалить проблемные расширения через параметры командной строки запуска 1С. Для этого мы можем использовать ключ /DeleteCfg.
Сформируем команду запуска (рекомендуется выполнять на копии базы):
/DeleteCfg -Extension ИмяПроблемногоРасширения/DeleteCfg -AllExtensionsЭтот метод заставляет платформу инициализировать процедуру удаления еще на этапе загрузки, что иногда позволяет обойти блокировку интерфейса конфигуратора.
Если конфигурация заблокировалась, проанализируем еще один интересный и безопасный способ сброса кэша. В ряде случаев помогает запуск базы данных в режиме Конфигуратора или Предприятия с использованием предыдущего (более старого) релиза платформы 1С.
Если на вашем сервере или ПК установлена более старая версия платформы, запустите базу через нее. Достаточно просто дождаться окна ввода логина и пароля, а затем закрыть программу. В некоторых случаях при таком старте платформа обнаруживает несоответствие версий кэша сеансов и самостоятельно выполняет внутреннюю очистку зависших статусов неудачного обновления.
Рассмотрим ситуацию с файловым вариантом работы (база данных .1CD). В таком случае выполнить SQL-запрос UPDATE SchemaStorage напрямую не получится.
Для прямого редактирования внутренних таблиц в файловой базе существуют специализированные сторонние утилиты для низкоуровневого просмотра (например, Tool_1CD). Однако редактирование структуры базы таким способом — крайне рискованный процесс, требующий глубоких знаний структуры формата 1CD. В случае файловой базы самым надежным, быстрым и правильным решением будет восстановление последней резервной копии базы данных.
Чтобы больше не сталкиваться с подобными ситуациями, проанализируем первопричины: