Что делать, если регламентное задание блокирует обновление периферийной базы РИБ с ошибкой "Вход в программу временно невозможен"?

Системный администратор 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Бухгалтерский учет
← На главную

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

Рассмотрим типичную проблему: после принятия изменений в конфигураторе периферийной базы 1С:Бухгалтерия 3.0, при запуске в режиме "Предприятие" процесс обновления завершается ошибкой:


{ОбщийМодуль.ОбщегоНазначения.Модуль(2308)}: Вход в программу временно невозможен в связи с обновлением на новую версию. Рекомендуется запрещать выполнение регламентных заданий на время обновления.
{ОбщийМодуль.ОбменДаннымиСервер.Модуль(1361)}: Ошибка загрузки приоритетных данных из сообщения обмена. См. подробности в журнале регистрации.

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

Причина ошибки: конфликт обновления и фоновых процессов

Основная причина такого поведения — это "гонка состояний". Когда вы загружаете обновление конфигурации в периферийную базу, система должна выполнить ряд процедур для применения этих изменений. В этот же момент могут запускаться регламентные задания (например, проверка новостей, обновление классификаторов, фоновый обмен данными). Эти фоновые процессы пытаются работать со старой структурой данных, в то время как система уже начала переход на новую. Это вызывает конфликт, который обработчики обновления расценивают как критическую ошибку и блокируют вход пользователя до ее устранения.

Стандартные методы, такие как запуск с ключами или отключение регламентных заданий на сервере, не всегда помогают, так как ошибка возникает на самом раннем этапе запуска базы, когда эти команды могут еще не успеть отработать. Давайте рассмотрим рабочие методики, которые помогли пользователям справиться с этой проблемой.

Решение 1: Обновление центральной базы до последнего релиза

Этот способ оказался успешным для автора исходной проблемы и является самым безопасным и простым. Часто в последующих релизах конфигураций разработчики 1С исправляют ошибки, связанные с процедурой обновления в РИБ.

Порядок действий:

  1. Создайте резервные копии центральной и всех периферийных баз.
  2. В центральной базе проверьте наличие более свежих обновлений конфигурации. Если они есть, обновите центральный узел до самого последнего доступного релиза.
  3. После успешного обновления центральной базы выполните штатный обмен данными, чтобы создать новое сообщение с обновлением для периферийного узла.
  4. В периферийной базе загрузите полученное сообщение. Сначала примените изменения в конфигураторе, а затем запустите базу в режиме "Предприятие".

Как показала практика, после обновления до самого актуального релиза процедура обновления в периферийной базе может "подвиснуть" на некоторое время, но затем успешно завершается. Этот метод стоит попробовать в первую очередь.

Решение 2: Сброс номера принятого сообщения

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

Порядок действий:

  1. Запустите периферийную базу в обычном режиме. Ошибка блокирует вход, но нам нужно получить доступ к стандартным обработкам. Если обычный вход невозможен, попробуйте запустить базу с ключом /Run "e1cib/command/Обработка.РегистрацияИзмененийДляОбмена.Форма", хотя это может не сработать. Если доступ получить удалось, переходите к следующему шагу. Важно: этот способ сработает, если ошибка позволяет хотя бы на мгновение открыть основной интерфейс.
  2. Откройте обработку "Регистрация изменений для обмена". Обычно ее можно найти через меню "Все функции".
  3. В открывшейся обработке выберите узел обмена, с которым возникла проблема (обычно это центральный узел).
  4. Найдите поле "Номер принятого сообщения". Текущее значение будет соответствовать последнему проблемному обмену.
  5. Измените это значение на 0 и сохраните изменения.
  6. После этого снова запустите процедуру загрузки данных из того же самого файла обмена (который вызвал ошибку).

Сброс номера заставит систему считать, что она еще не получала это сообщение, и инициировать процесс загрузки и обновления заново. Часто вторая попытка проходит успешно.

Решение 3: Временное изменение кода конфигурации

Внимание! Этот способ предназначен для опытных пользователей и программистов. Некорректное изменение кода может привести к полной неработоспособности базы. Обязательно сделайте резервную копию перед началом работ.

Суть метода заключается в том, чтобы найти и временно закомментировать строку кода, которая вызывает исключение и блокирует вход.

Порядок действий:

  1. Откройте проблемную периферийную базу в режиме "Конфигуратор".
  2. В тексте ошибки указан путь к проблемному коду: {ОбщийМодуль.ОбщегоНазначения.Модуль(2308)}. Это означает, что нам нужно открыть общий модуль ОбщегоНазначения и найти строку 2308.
  3. Используя поиск по конфигурации или прямое открытие модуля, найдите эту строку. Скорее всего, там будет код, проверяющий состояние обновления, и в случае проблемы вызывающий исключение. Выглядеть это может примерно так: 
    
// ... какой-то код проверки ...
Если ТребуетсяБлокировкаРаботыПользователей() Тогда
    // Вот эта строка вызывает ошибку
    ВызватьИсключение НСтр("ru = 'Вход в программу временно невозможен...'"); 
КонецЕсли;
// ...
  4. Закомментируйте строку, которая вызывает исключение, добавив в ее начале два слеша //. 
    
// ... какой-то код проверки ...
Если ТребуетсяБлокировкаРаботыПользователей() Тогда
    // // Вот эта строка вызывает ошибку
    // ВызватьИсключение НСтр("ru = 'Вход в программу временно невозможен...'"); 
КонецЕсли;
// ...
  5. Сохраните конфигурацию и обновите конфигурацию базы данных (клавиша F7).
  6. Запустите базу в режиме "Предприятие". Блокировка должна исчезнуть, и процесс обновления должен пройти до конца.
  7. Критически важно: после того как обновление успешно завершится и база станет работоспособной, вернитесь в конфигуратор, снимите конфигурацию с поддержки, раскомментируйте измененную строку и верните конфигурацию на полную поддержку. Игнорирование этого шага приведет к проблемам при будущих обновлениях.

Решение 4: Проверка и унификация среды выполнения

Иногда причина кроется не в коде, а в окружении: разные версии платформы 1С или проблемы с сетевым доступом к файлам обмена.

Порядок действий:

  1. Убедитесь, что на компьютере с центральной базой и на компьютере с периферийной базой установлена абсолютно одинаковая версия платформы 1С:Предприятие (вплоть до последней цифры релиза).
  2. В качестве эксперимента попробуйте развернуть копию периферийной базы на том же компьютере или сервере, где находится центральная база.
  3. Настройте для этой копии обмен через локальную папку.
  4. Проведите обмен. Если в таких "идеальных" условиях обмен и обновление пройдут успешно, значит, проблема связана либо с версией платформы на удаленной машине, либо с сетью.

Решение 5: Радикальные методы (с осторожностью)

Если ничего из вышеперечисленного не помогло, остаются только кардинальные меры. Их следует применять в последнюю очередь.

Вариант А: Отключение от РИБ и повторное подключение

Этот метод заключается в том, чтобы временно сделать периферийную базу не-РИБ, обновить ее и снова включить в состав РИБ. Внимание: этот способ сопряжен с высоким риском потерять связь с центральным узлом навсегда.

Как показывает практика, при отключении главного узла в периферийной базе платформа 1С версии 8.3 удаляет информацию о центральной базе. Попытка "восстановить" подчинение после обновления, скорее всего, не удастся. Поэтому данный метод не рекомендуется.

Вариант Б: Полное пересоздание периферийного узла

Это самый надежный, хотя и трудоемкий, из радикальных методов.

  1. В центральной базе удалите проблемный узел РИБ.
  2. Создайте новый узел для этой же периферийной базы.
  3. Сформируйте начальный образ информационной базы.
  4. На периферии разверните этот образ и настройте обмен с нуля.

Этот способ гарантированно решает проблему, так как вы начинаете с "чистого листа", но требует времени и может быть неудобен, если в периферийной базе есть неотправленные данные.

Превентивные меры

Чтобы минимизировать риск возникновения подобных ошибок в будущем, следуйте простым правилам:

← На главную