При переходе на релиз 3.0.71.63 (и смежные версии) в конфигурации 1С:Бухгалтерия предприятия 3.0 пользователи часто сталкиваются с прерыванием процесса обновления информационной базы. Ошибка может проявляться как в Конфигураторе, так и в пользовательском режиме, причем наличие настроенного электронного документооборота (ЭДО) часто является катализатором проблемы. Рассмотрим подробно причины возникновения этих ошибок и разберем проверенные способы их устранения.
Одной из наиболее распространенных причин сбоя является некорректная работа механизма ограничений доступа на уровне записей (RLS) при выполнении обработчиков обновления. Проанализируем ситуацию: в процессе обновления некоторые объекты метаданных, относящиеся к ЭДО, переименовываются или помечаются как удаленные (например, Справочник.УдалитьСоглашенияОбИспользованииЭД). Если у пользователя, под которым запускается обновление, помимо полных прав назначены специализированные роли ЭДО, система может выдать ошибку доступа к полям, которые уже изменены или физически отсутствуют в новой структуре базы.
Выясним, как это исправить. Решение заключается в минимизации прав администратора на время выполнения обновления:
Выполнение обмена электронными документами и Чтение электронных документов, их необходимо снять.Полные права и Администратор системы.Для пользователей с полными правами дополнительные роли ЭДО являются избыточными, так как полные права перекрывают любые ограничения. После успешного обновления роли можно вернуть, но, как показывает практика, в этом нет необходимости.
Часто стабильность процесса обновления зависит от версии используемой платформы 1С:Предприятие. В обсуждении отмечалось, что на платформе версии 8.3.15 наблюдались ошибки реструктуризации и блокировки фоновых заданий. Рассмотрим рекомендации по выбору окружения:
Во-первых, если обновление в Толстом клиенте завершается ошибкой, попробуем запустить процесс через Тонкий клиент. Тонкий клиент менее требователен к локальному кэшу метаданных и более корректно обрабатывает динамические изменения структуры при выполнении обработчиков в пользовательском режиме.
Во-вторых, обратим внимание на версию платформы. Хотя программа может предлагать обновиться на самую свежую версию, для релизов линейки 3.0.71 наиболее стабильной зарекомендовала себя платформа 8.3.12.1685 (или более поздние сборки ветки 8.3.13, например 8.3.13.1865). Если вы используете версию 8.3.14 или 8.3.15, попробуйте временно запустить базу на более старой, но стабильной платформе для прохождения этапа обновления конфигурации.
Другой неприятный сюрприз при переходе с релиза 3.0.70 на 3.0.71 — ошибка в регистре сведений РассчитанныеОтборыПоНовостям_РедкоМеняющиеся. Система сообщает о наличии дублей, что блокирует реструктуризацию базы. Выясним причину: это происходит из-за некорректного кэширования настроек новостей, которые платформа пытается пересчитать при обновлении.
Посмотрим на алгоритм исправления этой проблемы:
Регистр сведений: Рассчитанные отборы по новостям (редко меняющиеся).После очистки регистра попробуем снова запустить обновление в Конфигураторе. Дубли исчезнут, и реструктуризация таблиц пройдет успешно.
Если вышеуказанные способы не помогают, и система продолжает ссылаться на несуществующие поля (например, поле ДоговорКонтрагента в объектах ЭДО), проанализируем состояние серверного кэша. В клиент-серверном варианте работы метаданные могут «залипнуть» в памяти сервера приложений.
Выполним следующие шаги для очистки:
C:\Program Files\1cv8\srvinfo).snccntx. Это принудительно очистит кэш сеансовых данных.Если окно обновления в пользовательском режиме просто закрывается без сообщений, а в Конфигураторе база считается обновленной, но фактически функционал заблокирован («Требуется завершить обновление»), мы можем запустить процесс принудительно через программный код. Посмотрим, как это сделать:
Включим возможность отладки и откроем консоль кода (или создадим внешнюю обработку) со следующим фрагментом:
// Принудительный запуск процедур обновления информационной базы
ПараметрыОбновления = Справочники.ДополнительныеОтчетыИОбработки.СоздатьЭлемент();
БиблиотекаОбновленияИнформационнойБазы.ВыполнитьОбновлениеИнформационнойБазы();
Однако более безопасным методом является запуск базы с параметром ЗапуститьОбновлениеИнформационнойБазы в строке запуска или через вызов формы монитора обновлений:
СтандартныеПодсистемыСервер.УстановитьПараметрЗавершенияОбновления(Ложь);
Это заставит систему при следующем входе заново проанализировать состояние всех обработчиков и попытаться выполнить те, которые завершились аварийно из-за ошибок доступа к справочникам ЭДО.
Мы рассмотрели комплексный подход к решению проблем обновления релиза 3.0.71.63. Главное правило — перед началом масштабных действий всегда создавайте резервную копию базы данных. В большинстве случаев достаточно просто отключить лишние роли у администратора и очистить регистр новостей. Если ошибка сохраняется, переходите к манипуляциям с платформой и очисткой серверного кэша. Помните, что релиз 3.0.71.77 и выше уже содержит исправления многих описанных ошибок, поэтому при возможности старайтесь обновляться сразу на более актуальную версию, минуя проблемные промежуточные релизы.