← На главную

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

Принудительный запуск процедур обновления через параметры запуска

Разберем самый эффективный и «штатный» способ решения проблемы. Часто система «забывает» предложить запуск обработчиков обновления или этот процесс прерывается. Мы можем инициировать его принудительно, используя специальный ключ запуска. Проанализируем, как это сделать правильно:

1. Откроем Конфигуратор вашей информационной базы.
2. Перейдем в меню Сервис — Параметры.
3. Выберем закладку Запуск 1С:Предприятия — Основные.
4. В поле Параметры запуска введем следующую строку: ЗапуститьОбновлениеИнформационнойБазы Если мы запускаем базу через ярлык или командную строку, формат будет следующим: /С ЗапуститьОбновлениеИнформационнойБазы
5. Нажмем «ОК» и запустим систему в режиме «Предприятие» (клавиша F5 или через меню).

После этого система должна проигнорировать блокировку и начать выполнение фоновых или последовательных процедур обновления данных. Проанализируем результат: если окно обновления появилось и процесс пошел, дождитесь его окончания. Важный момент: после успешного входа не забудьте удалить эту строку из параметров запуска, иначе при каждом открытии программа будет пытаться инициализировать обновление заново.

Выполнение процедур обновления от имени администратора

Рассмотрим ситуацию, когда обновление было выполнено, но база не была запущена первым сеансом под пользователем с полными правами. Выясним причину: механизмы БСП (Библиотеки стандартных подсистем) требуют, чтобы первый запуск после изменения метаданных осуществил администратор. Именно в этот момент срабатывает код, который прописывает новые версии в регистры.

Попробуем следующий алгоритм действий:

1. Попросим всех пользователей выйти из базы (проверить это можно в консоли администрирования кластера или через «Активные пользователи», если вход возможен).
2. Запустим базу в режиме «Предприятие» отдельным сеансом (не через отладку из конфигуратора) под учетной записью с полными правами.
3. Если система предложит подтвердить легальность обновления — подтверждаем.
4. Дожидаемся появления рабочего стола или сообщения о завершении обновления.

Иногда помогает «хитрость» с правами: временно дадим обычному пользователю права Администратор системы и Обновление конфигурации базы данных, выполним запуск, а после успешного входа вернем права в исходное состояние. Это помогает, когда основной администратор по какой-то причине не может инициировать процесс.

Очистка локального и серверного кэша

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

Для локальной базы или тонкого клиента: самый надежный способ — удалить базу из списка в окне запуска 1С и добавить её заново. При этом папка с временными файлами (кэшем) будет создана с нуля, и старые данные не будут мешать входу.

Ручная очистка: необходимо перейти в директории:

1. %AppData%\1C\1Cv8
2. %LocalAppData%\1C\1Cv8

И удалить там все папки с именами-идентификаторами (вида eb456...). Не бойтесь, настройки пользователя хранятся в других местах, это лишь временные файлы конфигурации.

Серверный кэш: в случае клиент-серверного варианта (SQL), иногда требуется перезапуск службы 1C:Enterprise 8.3 Server Agent. Это сбросит серверные вызовы и зависшие параметры сеансов, которые могут транслировать ошибку об обновлении.

Корректировка регистра «Версии подсистем»

Если автоматические методы не помогают, нам придется заглянуть «под капот» системы. Информация о том, какая версия конфигурации сейчас актуальна, хранится в регистре сведений Версии подсистем. Разберем, как с ним работать:

1. Зайдем в базу через Конфигуратор и воспользуемся инструментом «Все функции» (или «Функции для технического специалиста») в режиме «Предприятие», если это возможно. Если вход заблокирован совсем, можно воспользоваться внешней обработкой для чтения/записи регистров.
2. Найдем регистр сведений Версии подсистем.
3. Посмотрим на записи. Если вы видите, что номер версии основной конфигурации (например, StandardSubsystems или имя вашей программы) отличается от того, что указано в справке «О программе», значит, произошел сбой записи.
4. Иногда помогает удаление строки с проблемной подсистемой. При следующем запуске система увидит отсутствие данных и инициирует процедуру первичной установки/обновления для этой части кода.

Работа с зависшими сеансами и фоновыми заданиями

Выясним еще одну причину: процесс обновления может быть заблокирован «призрачным» сеансом. Проанализируем ситуацию в консоли администрирования кластера серверов 1С:

• Откроем консоль, перейдем в ветку Сеансы нужной информационной базы.
• Проверим наличие активных фоновых заданий. Если среди них есть те, что запущены давно и имеют отношение к ОбновлениеИнформационнойБазы, их следует завершить принудительно.
• Проверим свойство базы Блокировка начала сеансов. Иногда после автоматического обновления скриптом блокировка не снимается сама. Нужно убедиться, что флаг «Установка блокировки включена» снят.

Крайние меры: правка кода (для опытных разработчиков)

Если ни один из вышеперечисленных методов не сработал, рассмотрим способ временного обхода проверки в коде. Это актуально для сильно кастомизированных конфигураций (например, УПП 1.3). Посмотрим на пример манипуляций в общем модуле:

1. В Конфигураторе найдем модуль СтандартныеПодсистемыПовтИсп (или аналогичный, на который ссылается ошибка в стеке вызовов).
2. Найдем процедуру, отвечающую за проверку возможности входа (например, ИнформационнаяБазаЗаблокированаДляОбновления).
3. Временно закомментируем вызов проверки параметров работы программы:
   Скопировать код

   
   // СтандартныеПодсистемыСервер.ПроверитьОбновлениеПараметровРаботыПрограммы( "ПараметрыСлужебныхСобытий", "ОбработчикиСобытий");
   

4. Обновим конфигурацию базы данных (F7).
5. Запустим «Предприятие». База должна пустить пользователя. Пройдем все этапы обновления данных.
6. Обязательно: вернем код в исходное состояние после того, как процедуры обновления завершатся.

Подводя итог, можно сказать, что в 90% случаев помогает именно параметр запуска ЗапуститьОбновлениеИнформационнойБазы в сочетании с запуском от имени администратора. Всегда начинайте с этого метода, прежде чем переходить к более радикальным мерам в коде или базе данных.