1с бсп отключить обновление
После каждого обновления базы в ней запускаются обработчики обновления для того, чтобы проделать с данными базы манипуляции, необходимые в связи с изменившейся конфигурацией.
Таких обработчиков бывает 2 вида: основные и отложенные.
Суть их одна, но отложенные обработчики в отличие от основных можно выполнять уже после всех обновлений, в фоновом режиме, по ходу работы пользователя.
Обновлятор по умолчанию выполняет и те и другие обработчики в своём цикле обновления сразу.
И это правильно, так как зачастую применяется несколько обновлений. И если не выполнить все обработчики сразу – потом это может быть сделать весьма проблематично (будут возникать ошибки).
Что делать?
Если у вас включён контроль за выполнением отложенных обработчиков обновления, то обновлятор может в какой-то момент начать отказываться продолжать обновление базы.
Отключаем контроль за обработчиками
. нужно или отключить этот контроль (нежелательный вариант).
Выполняем обработчики в ручном режиме
. или (предпочтительный вариант) выполнить эти обработчики в ручном режиме, устранив ошибки в базе, препятствующие этому.
Для этого запустите базу в режиме пользователя.
Согласитесь, если это потребуется, на выполнение основных обработчиков обновления и дождитесь его окончания.
Далее зайдите в меню Все функции ( оно может быть скрыто из меню, о том как его показать читайте здесь ):
В этом меню раскройте раздел "Обработки":
И в нём найдите и откройте подпункт "Результаты обновления программы":
В этой обработке можно увидеть сведения о выполненных обработчиках и возможных проблемах с ними:
И если не все обработчики были выполнены - это будет отражено в этом окне.
Тогда их можно будет открыть по ссылке и запустить на повторное выполнение (через контекстное меню правой кнопкой или через кнопку "Запустить"):
В случае серверной базы отложенные обработчики обновления, которые не были выполнены обновлятором, выполняются через механизм регламентных заданий.
Это значит, что если у вас выключен запуск регламентных заданий на сервере - вы будете бесконечно долго и безрезультатно ждать выполнения этих отложенных обработчиков.
И вам нужно либо разблокировать запуск регламентных заданий на сервере, либо запустить регламентное задание с именем "Отложенное обновление ИБ" вручную.
Рассмотрим процесс ручного запуска необходимого нам регламентного задания.
В режиме пользователя зайдите в меню Все функции ( оно может быть скрыто из меню, о том как его показать читайте здесь ):
В открывшемся диалоге раскройте раздел "Обработки". Найдите и откройте там следующий пункт:
Выделите в списке задание "Отложенное обновление ИБ" и запустите его вручную, нажав на кнопку "Выполнить сейчас":
Учтите, что за один запуск выполняется лишь один из отложенных обработчиков. Поэтому запускайте это задание столько раз, сколько потребуется, чтобы выполнить все отложенные обработчики обновления.
Отдельный случай - это когда вам не удаётся выполнить проблемные обработчики даже в ручном режиме. Обычно это означает, что:
- либо есть проблемы в базе на уровне данных (например, неверное заполнение справочников или документов)
- либо разработчики обновления допустили ошибку в коде проблемного обработчика
В таких случаях я первым делом рекомендую искать на форумах решение возникшей проблемы по тексту ошибки выполнения обработчика, который доступен в этом окне.
Но может оказаться и так, что вам потребуется анализ и корректировка (на время выполнения) программного кода обработчика, при выполнении которого возникает ошибка. И в этом случае уже без помощи программиста, к сожалению, обойтись не удастся.
Задействуем специальный механизм при обновлении очень старых серверных баз
Как написано выше, обновлятор выполняет отложенные обработчики сразу вместе с основными. Это позволяет ему безопасно выполнять последовательное обновление базы на несколько релизов.
Но для серверных баз возможность такого выполнения отложенных обработчиков была не всегда (вернее БСП, на основе которой пишутся типовые конфигурации, её не всегда поддерживала).
И в этом случае требовалось:
- или обновлять базу в файловом режиме (что не всегда возможно) - там этой проблемы нет
- или применять обновления по одному и после каждого из них запускать базу в режиме пользователя и дожидаться выполнения всех отложенных обработчиков
Именно для этого случая я и придумал специальный режим выполнения обработчиков обновления, который включается в свойствах серверных баз вот так:
Внимательно прочтите технические особенности работы этого режима. Его следует применять только как временную меру при обновлении старых конфигураций сразу на несколько релизов.
Я рассчитываю, что эта возможность будет задействована только опытными пользователями, которые понимают, что делают.
Вы должны принять тот факт, что обновлятор (в этом особом режиме выполнения обработчиков) будет на некоторое время разблокировать запуск регламентных заданий на сервере.
Итак, вот как будет действовать обновлятор в этом особом режиме:
- Сначала он выполнит все обработчики обновления стандартным способом.
- Далее он проверит - остались ли в базе невыполненные отложенные обработчики обновления.
- Если такие обработчики остались, то он:
- Полностью снимет блокировку сеансов.
- Разблокирует запуск регламентных заданий в кластере.
- И будет в цикле ожидать пока регламентное задание "Отложенное обновление ИБ" само по расписанию выполнит все отложенные обработчики (то есть переведёт их в состояние "выполнено" или "ошибка"). По умолчанию регламентное задание "Отложенное обновление ИБ" запускается каждую минуту для выполнения очередного обработчика. Вы можете изменить настройки его запуска через расписание регламентного задания. Это может быть полезно для того, чтобы ускорить процесс выполнения отложенных обработчиков, если их много.
- После этого обновлятор вернёт блокировку сеансов базы и блокировку регламентных заданий, если они были установлены до этого.
При таком варианте выполнения обработчиков обновления - отчёт в этой части будет подробным, даже если вы не включили режим отладки.
Учтите, что отложенные обработчики могут выполняться и 5 минут и 2 часа. И это нормально и зависит от обновления и размера вашей базы. Ещё раз обратите внимание на возможность ускорения выполнения отложенных обработчиков путём изменения расписания запуска регламентного задания "Отложенное обновление ИБ". По умолчанию оно запускается один раз в минуту, выполняет один обработчик и делает паузу ещё на минуту. И если у вас 60 отложенных обработчиков, то этот процесс будет длиться уже 2 часа, хотя его можно прогнать за 20 минут, если настроить запуск регламентного задания, скажем, каждые 10 секунд без паузы.
Если вы захотите прервать ожидания выполнения отложенных обработчиков, то нажмите кнопку "Остановить всё" и дожидайтесь пока обновлятор сам прервёт ожидание.
В противном случае вам нужно будет самому зайти в диспетчер задач и завершить процесс с именем Connector1Cx86.exe или Connector1Cx64.exe. И далее самому проконтролировать в каком состоянии блокировки осталась база и её регламентные задания.
Если в отчёте начала появляться фраза "Ожидание выполнения отложенных обработчиков не требуется", значит вы дошли до версии конфигурации, когда выполнение отложенных обработчиков стало возможно в основном цикле обновления. В этом случае следует отключить особый режим выполнения обработчиков.
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Любите ли Вы динамическое обновление конфигураций так, как люблю его я? Обожаю что-нибудь с его помощью пропатчить на продакшене! Особенно в пятницу! Вечером! Перед майскими праздниками! Без предупреждения!
На самом деле нет! Динамическое обновление с одной стороны выглядит отличным механизмом платформы 1С, который позволяет вносить изменения в конфигурации "на лету". Главное, чтобы изменения не затрагивали структуру базы данных, в противном случае придется выполнять обновление монопольно и "выгонять" пользователей.
Согласитесь, при появлении ошибки в коде после очередных изменений просто берешь и обновляешь базу "на горячую" и никаких проблем! Главное всем, кому нужны были эти изменения, перезапустили сеанс и изменения вступят в силу!
С другой стороны может что-то пойти не так и Вы найдете небольшую, но весомую порцию багов у себя.
И никакие отговорки, что это были изменения для ТОП-менеджеров Вам не помогут!
Но как же так! Вы пользуетесь динамическим обновлением и у Вас нет никаких проблем? Коллеги рассказывают страшные истории, но Вы им не верите? "Просто они плохие 1Сники!", думаете Вы?
Как работает динамическое обновление
Наверное это странный вопрос, ведь ответ лежит на поверхности - это механизм позволяет обновить конфигурацию базы данных без остановки ее работы, внося изменения не требующие модификации на уровне базы данных. В официальной документации на ИТС есть информация в каких случаях платформа позволяет провести динамическое обновление. Вроде все просто. Но что если пойти дальше.
В любой информационной базе есть таблицы "Config" и "ConfigSave". Назначение этих таблиц также известно:
- Config - содержит основную конфигурацию информационной базы, которая соответствует актуальной структуре базы данных и используется активными сеансами.
- ConfigSave - содержит сохраненную конфигурацию. Ту самую, которую Вы редактируете в конфигураторе. Как только Вы нажимаете "Сохранить", все измененные объекты и связанная информация записывается именно сюда. После запуска обновления информационной базы все изменения из этой таблицы переносятся в таблицу Config. Если же выполнить команду "Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД", то вся информация об изменениях в этой таблице удалится.
Все просто, не так ли? Но пойдем еще дальше. Посмотрите на структуру таблиц для хранения данных конфигурации.
Структура таблиц идентична.
Описание полей такое:
- FileName - строка длиной 128, используется для хранения имени "файла", это некоторая часть конфигурации.
- Creation - дата создания записи.
- Modified - дата модификации записи.
- Attributes - целое число, назначение которого сейчас нет смысла рассматривать (на самом деле я точно не могу утверждать, только предполагаю зачем оно нужно. Но если Вы знаете, то напишите в комментариях).
- DataSize - размер данных в байтах, хранящийся в поле "BinaryData"
- BinaryData - непосредственно данные конфигурации.
- PartNo - номер части. Иногда размер данных объекта метаданных может быть очень большим и платформа его разбивает на части.
То есть конфигурация хранится некоторыми блоками. Вообще, структура хранения конфигурации в таблице базы соответствует тому, как устроена внутренняя структура форматом файлов CF. Подробнее об этом Вы можете узнать в отличной статье "Описание формата файлов конфигурации (CF, EPF, ERF)" от Андрея Овсянкина.
Со структурой таблиц и их назначением понятно. Пойдем дальше.
Когда Вы начинаете процесс обновления информационной базы, на первом этапе платформа 1С выполняет множество служебных действий, останавливаться на которых сейчас особо нет смысла. Самое интересное начинается после того, как Вы нажимаете заветную кнопку "Обновить динамически".
Среди множества служебных действий, платформа переносит данные об объектах из таблицы ConfigSave в Config:
В следующий раз, когда информационная база будет обновляться в обычном режиме, записи об объектам, созданных при динамическом обновлении, будут удалены и останутся только основные записи с актуальными данными конфигурации.
Это очень поверхностное описание и сам процесс имеет множество особенностей как со стороны работы БД, так и со стороны работы клиентских приложений платформы 1С. Но суть должна быть понятной.
Подробный пример динамического обновления
Для того, чтобы детальней погрузиться в происходящее при таком обновлении, рассмотрим все действия платформы 1С, до которых можно добраться законым способом. То есть мы не будем влазить в модули работы самой платформы и открывать то, за что можно получить повестку в суд. Мы лишь посмотрим что делает платформа на стороне базы данных. И этого нам будет достаточно!
В нашем примере есть некоторая конфигурация на базе БСП (хотя это и не важно), в которой добавлен очень важный общий модуль "ДляДинамическогоОбновления".
Модуль полностью клиентский, имеет в своем составе только одну функцию.
На первом шаге мы вносим изменения в модуль и нажимаем "Сохранить конфигурацию". При этом изменения в конфигурации сохранены, но не применены к информационной базе.
На этом шаге платформа 1С делает записи в таблицу "ConfigSave", некоторое промежуточное хранилище, из котого потом измененные элементы конфигурации должны будут перенесены в основную таблицу конфигурации "Config".
Вот вся история операций в таблице "ConfigSave" после сохранения конфигурации. Здесь подробная информация обо всех действия практически на физическом уровне, поэтому некоторые операции "INSERT" разделены на две (INSERT и UPDATE), а операция UPDATE может быть выделена как операции DELETE и INSERT. Но эти особенности сейчас не играют роли.
Кроме этого в таблице есть дата операции (Period) и идентификатор транзакции (__$start_lsn). По факту все эти действия выполняются в разных транзакциях, лишь некоторые из действий в таблице выполняются в единой транзакции.
Вся операция, как уже упоминалось выше, делится на два этапа:
- Записываем в таблицу информацию об изменениях конфигурации , в частности нашего общего модуля "ДляДинамическогоОбновления". Кстати, на скрине выше видно, что его идентификатор "cb327a01-e9cc-44e6-af31-5f30c88faeca", отсюда и эти названия похожие. Имена содержат суффикс "new", что говорит о промежуточной записи объектов.
- На следующем шаге промежуточные записи преобразовываем в нормальные , просто исключив "new" из имен элементов конфигурации.
Тут все достаточно просто, идем к следующему шагу. Вы нажимаете кнопку "Обновить информационную базу", но так как в базе есть сеансы, а изменения касаются только модулей, то платформа 1С предлагает выполнить динамическое обновление без завершения сеансов.
В этот момент платформа 1С сделала два действия:
- Скопировала записи из таблицы "ConfigSave" в таблицу "Config" с суффиксом "new", почти все действия выполнены в одной транзакции.
- Затем было обнаружено, что обновление невозможно продолжить из-за наличия активных сеансов. Был показан диалог для динамического обновления, а ранее добавленные записи удалены из таблицы "Config" в одной транзакции.
Изменений в таблице "ConfigSave" в этот момент не выполнялось.
И вот мы добрались до последнего шага - запуска динамического обновления. Соглашаемся с этой операцией и получаем следующее.
- В таблице "Config" сначала добавляются новые записи с суффиком "new" для последующих операций с ними. Примерно такие же действия мы видели в самом начале в таблице "Config", перед тем как было предложено выполнение динамического обновления. Но в этот раз также сделаны служебные записи "commit", "dynamicCommit" и "dbStruFinal", которые относятся непосредственно к динамическому обновлению (частично о них было упомянуто выше).
- Предварительные записи с суффиксом "new" теперь платформа преобразовывает в нормальные записи, также добавляет записи с форматом "_dynupdate_", плюс вставляет флаг динамического обновления "DynamicallyUpdated".
- Из таблицы "ConfigSave" удалены все сохраненные ранее записи. Все в одной транзакции.
- И напоследок из таблицы "Config" удаляются служебные данные "commit", "dynamicCommit" и "dbStruFinal".
Заметьте, каждый этап - почти всегда разные транзакции, это важно.
После этого конфигурация успешно обновлена динамически, база работает. Чтобы клиентам получить новые изменения достаточно перезапустить сеанс. Вроде все хорошо.
На самом деле это не все действия платформы 1С, т.к. еще обновляются данные в таблице "Params" и некоторые другие. Но мы это рассматривать сейчас не будем.
Разработчики ликуют и со словами "Я же говорил" продолжают убеждать коллег, что динамическое обновление это нормально!
Что может пойти не так
Весь процесс динамического обновления мы рассмотрели, но что же может случиться?
Представим простую ситуацию: что, если все обновление прошло успешно, кроме последнего этапа? Например, во время выполнения запросов на удаление служебных данных соединение с базой данных почему-то "отпало":
- Сбой сети.
- Регламентные работы на сервере, внезапно.
- Обслуживание базы, которое завершило блокирующий сеанс, опять же внезапно!
- Конфигуратор вылетел из-за ошибки внутренней.
- Разработчик 1С был странным и завершил сеанс конфигуратора во время обновления.
- И еще сотни причин, которые лень добавлять.
Чтобы такое проще было представить, можно добавить в базу данных триггер, который при попытке удаления служебной записи о динамическом обновлении упадет в ошибку.
Попытаемся теперь выполнить динамическое обновление и столкнемся с ошибками:
- Сначала во время обновления в конфигураторе поймаем ошибку.
- А при попытке зайти в конфигуратор повторно мы словим ошибку.
- При попытке повторить обновление мы уйдем в бесконечную ошибку вида.
Все, конфигуратор нам больше недоступен! Чистите кэш, пытайтесь выполнить обновление ИБ, удаляйте сеансовые данные! Все бесполезно! Можете еще взять бубен, но и он бесполезен!
После этого проблема будет полностью исправлена в 99% случаев.
И это все?
Такая ошибка вас не остановит? Говорите, что ну и ладно, что в конфигуратор не вошли, зато клиенты работают, а с конфигуратором бы разобрались? Ведь решения есть на просторах интернета!
Хорошо, а как вам такой же "обрыв" соединения на этапе обновления данных в таблице "Params". Сделаем другой триггер (отключите только предыдущий):
При попытке обновления записи "DynamicallyUpdated" в таблице "Params" мы получим падение. Конфигуратор закроется системной ошибкой. Не страшно, скажите Вы! Но в этот же момент все клиентские соединения также вылетят, причем с разными ошибками. Например, с такой.
А при попытке перезапустить клиентский сеанс, также будут происходить различные ошибки. Никто не сможет работать с информационной базой!
Но и тут не все потеряно!
Клиентские сеансы не могут зайти в базу, их всех выкинуло и так далее! Но мы все еще можем в большинстве (но не во всех) случаев зайти в конфигуратор! И при повторном обновлении также в большинстве (но не во всех) случаях мы восстановим работу информационной базы!
Итог, все вылетели из базы, мы словили адреналина, и восстановили работу после штатного повторного обновления. Вас и это не убедило, что динамическое обновление очень опасно?
Вы поистине яркий человек
Если Вам и этого мало, то как Вы думаете, что будет, если оба этих случая будут комбинированы? В этом случае Вы "выкинете" всех пользователей из информационной базы, а потом еще и не сможете войти в конфигуратор повторно. Пойдете после этого вручную очищать таблицу "Config" от служебны записей динамического обновления и надеяться, что это в этот раз поможет.
Вы удивительный человек!
А ведь есть еще проблемы другого рода:
- Повреждение сеансовых данных сервера. Возникают из-за какого-то особого поведения платформы 1С, меняется от релиза к релизу, сложно прогнозируемые и сложновоспроизводимые ошибки.
- Повреждение клиентского кэша, которое приводит к:
- Ошибкам запуска клиентского приложения при входе в информационную базу
- Случайным ошибкам во время работы приложения, таким как "Тип неопределен" или подобные.
Ниже есть ссылки на примеры различных проблем и их решение. Для воспроизведения таких проблем мне пришлось бы откопать код приложений платформы 1С, но это не очень правильно.
Это весело
Вы все еще считаете, что динамическое обновление это хорошо? Что нет ни единой причины, чтобы отказаться от него? Что все описанные ошибки, которые даже можно воспроизвести прямо на свежих версиях платформы (от 8.0 до 8.3.20), не являются критичными? Может вы еще и бэкапы не делаете?
Кстати, описанные выше проблемы аткуальный как для платформы 1С версии 8.0, так и для всех более новых версий, вплоть до 8.3.20.*. И это только вершина айсберга!
Надеюсь, информация из статьи поможет кому-то хотя бы задуматься над тем, что Вы делаете!
P.S. А Вы задумывались над тем, что установка расширений тоже может приводить к подобным проблемам? :)
Иногда хотелось бы конфигурацию базы данных обновить, но пропустить обработку обновления.
Причин этому много, основная - ошибки в процессе обновления.
При этом получить доступ к полному интерфейсу программы невозможно - можно только открыть внешнюю обработку или посмотреть журнал регистрации.
(Фирма 1С анонсировала ключ запуска приложения ОтключитьЛогикуНачалаРаботыСистемы.
цитирую:При этом блокируется открытие всех форм на рабочем столе. Для отладки.
но у меня это не сработало)
Поэтому пойдем другим путем. Открываем внешнюю обработку ОтменитьОбновлениеИнформационнойБазы.epf
и редактируем РегистрСведений.ВерсииПодсистем
Здесь нужно сделать две вещи:
- Поставить корректный (актуальный номер релиза), не забыв запомнить старый, он пригодится.
- Установить у всех элементов флажок Выполнена регистрация отложенных обработчиков
После этого 1С не будет запускать обновление при старте, и можно будет спокойно разобраться с ошибками.
Затем возвращаем все значения регистра в исходное состояние и перезапускаем программу.
Обработка обновления запустится заново.
И если вы исправили все ошибки - пройдет успешно.В редких случаях (тут могут быть как косяки разработчиков, так и ваши) нужно пропустить отдельные шаги обновления.
Например, в моем случае я получал ошибку: Не указана процедура заполнения данных отложенного обработчика обновления "Документы.ТранспортнаяНакладная.ПеренестиДанныеИзРеквизитовВНовыйДокумент".
хотя 100% был уверен, что у меня и документов таких нет.
А на нет, как говорится, суда нет.Открываем вторую обработку НовыеСведенияОбОбновлении.epf находим
фильтр поля найти работает и по подстроке
Нажимаем кнопку - открыть форму удаления обработчика.
и удаляем сбоящую процедуру.
После этого запускаем обновление ИБ.Не забываем про ключ командной строки ЗапуститьОбновлениеИнформационнойБазы
Код обработки открыт.
Проверена на конфигурации Управление торговлей, редакция 11.2 (11.2.2.106)
P.S. Появился вопрос про относительно старые конфигурации.
У них при ошибке в обработке обновления нет кнопки "Открыть внешнюю обработку", только "Завершить работу" и "Перезапустить", более того - окно открыто модально.
Для владельцев базовых версий почти патовая ситуация, т.к. перезапуск приведет к этому же окну.Лайфхак невеликий - но выход есть.
Нажимаете F1, или по ссылке открываете технологический журнал, там будет активна кнопка - "Справка".А из окна справки уже можно получить доступ к полному меню, в том числе и открытию файлов внешних обработок.
Параметры запуска приложения, предоставляемые библиотекой:
1. ВойтиВОбластьДанных. При работе в модели сервиса позволяет выполнить вход в указанную область данных информационной базы. Например, «ВойтиВОбластьДанных; 3».
2. ВыполнитьОтложенноеОбновлениеСейчас.
Для клиент-серверных баз. Позволяет выполнить отложенные обработчики сразу, до начала работы пользователей в программе. Необходим для случаев, когда требуется быстро выполнить все процедуры отложенного обновления. Например, при обновлении «через несколько версий», когда прямое обновление на новую версию программы недопустимо, и требуется несколько раз последовательно обновлять конфигурацию и выполнять запуски для обновления ИБ.3. ЗапуститьОбновлениеИнформационнойБазы.
Принудительно запускает обновление вспомогательных данных и выполняет обработчики обновления, имеющие версию «*» (звездочные). Требуется, например, при изменении в метаданных конфигурации без увеличения номера версии.4. ЧислоПотоковОбновления.
Для клиент-серверных баз. Позволяет изменить количество параллельных потоков, выполняющих обновление программы (этап регистрации данных для отложенного обновления). Для оптимального и наиболее быстрого обновления рекомендуется устанавливать количество потоков равное количество ядер процессора на сервере, в случае ошибок конфликта блокировок значение нужно уменьшить. По умолчанию – 8.
5. ОтключитьЛогикуНачалаРаботыСистемы.
Только для автоматического тестирования (требуется право Администрирование).
При использовании этого параметра запуска на рабочих базах следует самостоятельно обеспечивать целостность данных.
6. РежимОтладки.
Упрощает отладку кода. В частности:● все длительные операции выполняются сразу, без запуска фонового задания;
● при разработке расширений конфигурации, возможен запуск с установленными расширениями конфигурации, которые в данный момент открыты в конфигураторе (при условии, что версия конфигурации и версии расширений не менялись).
7. РазрешитьРаботуПользователей.
Разрешает работу пользователей в информационной базе. Сеанс, запущенный с этим ключом будет завершен после снятия блокировки работы пользователей.8. ЗавершитьРаботуПользователей.
Запрещает подключение к информационной базе пользователей. Завершает уже запущенные сеанса. После завершения всех сеансов предлагает завершить сеанс, запущенный с этим ключом. Для клиент-серверной базы, если установлены параметры администрирования кластера, то их необходимо передать, указав через точку с запятой имя администратора кластера и пароль администратора кластера. Например, для администратора кластера Администратор и пароля 1 строка запуска будет ЗавершитьРаботуПользователей;Администратор;1.После каждого обновления базы в ней должны отработать так называемые обработчики обновления.
Это специальные программы на языке 1С, которые написаны разработчиками конфигурации для того, чтобы произвести корректный перенос данных из старой в новую версию конфигурации.
Обычно выполнение обработчиков запускается в момент, когда пользователь с правами администратора запускает базу в первый раз после обновления.
При таком запуске может появиться диалог, который просит подтвердить пользователя, что новое обновление получено им легальным способом, и сразу после этого начинают выполняться необходимые манипуляции с данными базы.
А если мы применяем к базе сразу несколько обновлений, то желательно, чтобы соответствующие обработчики были выполнены после каждого из таких промежуточных обновлений. Если этого не сделать, то появляется риск того, что возникнет ошибка при попытке выполнения этих же обработчиков, но уже после всех выполненных промежуточных обновлений.
Обновлятор умеет запускать выполнение этих обработчиков в автоматическом режиме для всех типовых баз, используя стандартные механизмы библиотеки стандартных подсистем от 1С (БСП).
И это, во-первых, позволяет применять сразу несколько обновлений к базе без дополнительного риска появления ошибок при последующем выполнении обработчиков обновления. А, во-вторых, делает возможным начало работы пользователей сразу же после окончания обновления без ожидания выполнения обработчиков.
Пугаться проблем с обработчиками не стоит - это довольно распространенная ситуация (не важно каким способом вы обновляете базу), когда один из обработчиков не может выполниться корректно. Причиной этого может быть ошибка разработчика обновления конфигурации или проблемы в данных самой базы (вы забыли заполнить какое-нибудь важное поле в документе и при переносе данных в новую версию это поле стало обязательным).
Во всех этих случаях следует чётко следовать инструкции для того, чтобы всё-таки выполнить все обработчики, прежде чем продолжить обновление.
Как отключить их выполнение обновлятором
Если же вы предпочитаете сами видеть весь процесс выполнения обработчиков обновления и не хотите, чтобы эту работу за вас делал обновлятор - выполните следующее:
1. В ыделите базу в списке обновлятора и нажмите кнопку "Свойства базы":
2. Перейдите на закладку "Обновление", раздел "Обработчики" и поставьте галку "Не выполнять обработчики обновления":
Готово. Теперь обработчики обновления будут выполняться уже после запуска базы пользователем.
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Читайте также: