← На главную

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

Выясняем причины возникновения блокировки

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

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

Решение 1: Устранение конфликта двух конфигураций поставщика

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

Для начала проверим текущее состояние. Зайдем в меню Конфигурация — Поддержка — Настройка поддержки. Если в списке отображается более одной строки (например, «ЗарплатаИУправлениеПерсоналом» и «ЗарплатаИУправлениеПерсоналомКорп»), значит, система пытается сопоставить объекты сразу с двумя эталонами.

Наиболее правильный метод решения здесь — оставить только актуальную конфигурацию поставщика. Если вы уверены, что база теперь должна быть КОРП, необходимо снять с поддержки старую конфигурацию ПРОФ, сохранив только КОРП-версию. Однако делать это нужно осторожно, чтобы не потерять связь объектов с реальным поставщиком.

Решение 2: Исправление структуры через полный файл конфигурации (.cf)

Если стандартное обновление через .cfu выдает ошибку доступности, проанализируем метод «лечения» базы через полную выгрузку. Этот способ помогает обновить конфигурацию поставщика и корректно пересчитать связи объектов.

Выполним следующие шаги:

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

Решение 3: Работа с хранилищем конфигурации

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

Если кнопка Конфигурация — Хранилище конфигурации активна, убедитесь, что все объекты свободны. Лучшим решением перед крупным обновлением будет полное отключение базы от хранилища. Это снимет все программные блокировки 1С.

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

Решение 4: Очистка кэша и принудительное завершение сеансов

Если программных причин (вроде хранилища или двух поставщиков) нет, выясним причину на уровне платформы. Иногда платформа 8.3.13 и выше ведет себя некорректно из-за механизмов фоновой реструктуризации.

Рассмотрим алгоритм технической очистки:

1. Остановите службу 1C:Enterprise Server (если база клиент-серверная).
2. Удалите содержимое папок кэша на сервере и на локальном компьютере:
   %LOCALAPPDATA%\1C\1cv8
%APPDATA%\1C\1cv8
3. Запустите консоль администрирования кластера и убедитесь, что в разделе «Сеансы» и «Блокировки» пусто. При необходимости удалите все сеансы вручную.
4. Попробуйте выполнить обновление в монопольном режиме, запустив конфигуратор с параметром /ClearCache.

Решение 5: Метод «Снятие с поддержки» (крайний случай)

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

После снятия с поддержки вы сможете беспрепятственно объединить конфигурацию с нужным .cf файлом. Однако помните: после этого базу нужно будет снова ставить на поддержку через Сравнение/Объединение с конфигурацией поставщика, чтобы сохранить возможность автоматических обновлений в будущем.

Дополнительные рекомендации по платформе 8.3

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

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

Подводя итог, можно сказать, что ошибка доступности объектов — это чаще всего следствие «запутанной» истории обновлений базы. Тщательная проверка настроек поддержки и использование полных .cf файлов вместо инкрементальных обновлений позволяют решить проблему в 90% случаев.