Вызов обновления менеджера конфигурации не из конфигуратора 1с
Параметры запуска приложения, предоставляемые библиотекой:
1. ВойтиВОбластьДанных. При работе в модели сервиса позволяет выполнить вход в указанную область данных информационной базы. Например, «ВойтиВОбластьДанных; 3».
2. ВыполнитьОтложенноеОбновлениеСейчас.
Для клиент-серверных баз. Позволяет выполнить отложенные обработчики сразу, до начала работы пользователей в программе. Необходим для случаев, когда требуется быстро выполнить все процедуры отложенного обновления. Например, при обновлении «через несколько версий», когда прямое обновление на новую версию программы недопустимо, и требуется несколько раз последовательно обновлять конфигурацию и выполнять запуски для обновления ИБ.
3. ЗапуститьОбновлениеИнформационнойБазы.
Принудительно запускает обновление вспомогательных данных и выполняет обработчики обновления, имеющие версию «*» (звездочные). Требуется, например, при изменении в метаданных конфигурации без увеличения номера версии.
4. ЧислоПотоковОбновления.
Для клиент-серверных баз. Позволяет изменить количество параллельных потоков, выполняющих обновление программы (этап регистрации данных для отложенного обновления). Для оптимального и наиболее быстрого обновления рекомендуется устанавливать количество потоков равное количество ядер процессора на сервере, в случае ошибок конфликта блокировок значение нужно уменьшить. По умолчанию – 8.
5. ОтключитьЛогикуНачалаРаботыСистемы.
Только для автоматического тестирования (требуется право Администрирование).
При использовании этого параметра запуска на рабочих базах следует самостоятельно обеспечивать целостность данных.
6. РежимОтладки.
Упрощает отладку кода. В частности:
● все длительные операции выполняются сразу, без запуска фонового задания;
● при разработке расширений конфигурации, возможен запуск с установленными расширениями конфигурации, которые в данный момент открыты в конфигураторе (при условии, что версия конфигурации и версии расширений не менялись).
7. РазрешитьРаботуПользователей.
Разрешает работу пользователей в информационной базе. Сеанс, запущенный с этим ключом будет завершен после снятия блокировки работы пользователей.
8. ЗавершитьРаботуПользователей.
Запрещает подключение к информационной базе пользователей. Завершает уже запущенные сеанса. После завершения всех сеансов предлагает завершить сеанс, запущенный с этим ключом. Для клиент-серверной базы, если установлены параметры администрирования кластера, то их необходимо передать, указав через точку с запятой имя администратора кластера и пароль администратора кластера. Например, для администратора кластера Администратор и пароля 1 строка запуска будет ЗавершитьРаботуПользователей;Администратор;1.
Вы создали первоначальный образ РИБ, пробуете его развернуть, но получаете следующую ошибку «В главном узле не обновлен справочник Идентификаторы объектов метаданных» Причина возникновения этого окна в том, что произошел сбой обновления!
Сделать это можно из командной строки с использованием ключа /C
«C:Program Files (x86)1cv88.3.6.2299in1cv8.exe» enterprise /F e:1cWorksДомСумок /N Администратор /P Boss21 /C»ЗапуститьОбновлениеИнформационнойБазы«
Либо через Конфигуратор, меню Сервис>Параметры, вкладка Запуск 1С Предприятия
Нажать кнопку OK и запустить отладку. При старте запустится Обновление версии программы.
Теперь осталось повторить создание первоначального образа РИБ на главном узле и развернуть его!
Если нужно еще раз запустить процедуры обновления
Если нужно изменить параметры запуска базы. Например из за добавленного объекта в конфигурацию которая вызывает ошибку «не найден идентификатор». Либо просто обновление не запускается и не база не переходит на новую версию после обновления. Может помочь запустить базу с дополнительными параметрами.
Заходим в конфигуратор → сервис → параметры. Закладка «Запуск 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. А Вы задумывались над тем, что установка расширений тоже может приводить к подобным проблемам? :)
Сразу оговорюсь — весь опыт основан на обновлении конфигурации Управление производственным предприятием (УПП), а это обычные формы и отсутствие расширений (так как режим совместимости «Версия 8.2.13»).
Насколько я замечаю по форумам и другим ресурсам по 1с, периодически появляются люди, которым необходимо в короткий срок обновиться через множество версий конфигураций. Причем обычно такие авралы по обновлениям происходят при смене законодательства, то есть, обычно в новый год. И невозможность сделать это за один прием их очень печалит. Надеюсь данная статья позволит избежать таким людям некоторых опрометчивых шагов.
1. Цепочка обновлений.
При обновлении стандартных конфигураций 1с нельзя обновлять с любой версии. По требованиям 1с есть версии с которых можно обновить до нужной. То есть существуют таблицы типа этой.
По этой таблице видно что на версию 1.3.126.2 можно обновляться только с версий 1.3.125.1 и 1.3.126.1. Поэтому для корректного обновления необходимо либо «накатывать» все подряд промежуточные конфигурации либо выстраивать цепочку только необходимых промежуточных конфигураций (насколько помню, на сайте выкладывалась обработка по построению такой цепочки). Причины данного в следующем:
— Одна из основных причин невозможности обновления с пропуском промежуточных конфигураций такова — на сайте 1с (то есть официальном месте раздачи обновлений типовых конфигураций) в большинстве случаев в дистрибутиве обновления лежат файлы с расширением cfu (надеюсь читатель понимает разницу между файлами cf и cfu). А файл cfu содержит только объекты которые были измены. И в обновлении, к примеру, для версии 1.3.124.2 будут только объекты измененные по сравнению с версией 1.3.123.1. Поэтому, в этом случае, пропуск промежуточных конфигураций означает потерю изменений.
Наверняка у некоторых разработчиков мелькнула мысль — на какой-нибудь тестовой базе накатить все обновления, получить конечную конфигурацию, из этой конфигурации создать файл cf и уже им обновить рабочую базу данных (либо тупо найти файл cf нужного релиза). Теоретически возможно, на практике сталкиваемся с следующим пунктом.
— Следующая причина. Это обработчики обновления. Проблемы при пропуске всей цепочки обновления (накатывании сразу финального файла cf) обычно возникают в этом месте. То есть при выполнении обновления конфигурации, при ПЕРВОМ ЗАПУСКЕ В ПОЛЬЗОВАТЕЛЬСКОМ РЕЖИМЕ выполняются обработчики обновления. Это обычные процедуры и функции которые выполняют изменение данных в базе. И если вдруг обработчик обновления обращается к несуществующему объекту или реквизиту, то получаем ошибку. В данном случае несуществующий объект или реквизит — это то что было переименовано или удалено.
Обработчики обновления на примере конфигурации УПП (Управление производственным предприятием).
Кратко суть в следующем — есть список процедур и функций которые вызываются при первом запуске базы данных в пользовательском режиме после обновления конфигурации (так как эти процедуры могут изменить любые данные, то этот запуск должен выполняться под пользователем с полными правами).
*Также обработчики обновления запускаются при первом запуске в пользовательском режиме после создания базы данных.
а). Запуск обработчиков обновления.
В модуле обычного приложения и в модуле управляемого приложения есть Процедура ПриНачалеРаботыСистемы() в которой есть вызов процедуры ОбновлениеИнформационнойБазыКлиент.ВыполнитьОбновлениеИнформационнойБазы(). Если конфигурация изменилась, то начинаются процедуры формирования списка обработчиков обновления, а затем выполнения полученных обработчиков из списка. Изменение конфигурации, в общем случае, определяется как различие значений версий "новой" и "старой" конфигураций. Значение "старой" (это значение до обновления) версии конфигурации хранится в базе данных.
б). Данные по версиям конфигурации и библиотек/подсистем.
В УПП данные по версиям (значения до обновления) хранятся в самой базе данных в регистре сведений ВерсииПодсистем.
Новые значения версий получают следующим образом — для самой конфигурации это значение Метаданные.Версия (по сути это реквизит "Версия" в свойствах конфигурации), для библиотек и подсистем данные получаются из функций. Для библиотеки УПП пример приведен ниже.
При успешном обновлении новые значения версий записываются в регистр сведений.
в). Списки обработчиков обновлений.
Получаются из функций (в УПП стандартно называются ОбработчикиОбновления, и, скорее всего, это стандартное наименование в типовых конфигурациях).
Для некоторых подсистем список обработчиков зависит от того, главный это узел обмена или подчиненный.
В УПП структура обработчиков имеет 9 полей. В подавляющем большинстве случаев используется 2 — "Версия" и "Процедура". Иногда используются поля "Опциональный" и "Приоритет" (в частности в подсистеме ЕГАИС). Поэтому при необходимости надо смотреть логику формирования списка обработчиков для конкретных случаев.
Если Обработчик.Версия=«*», то данная процедура будет занесена в первоначальный список при любом обновлении. Если в этом параметре версия указана, то в первоначальный список данная процедура будет занесена при обновлении на данную версию (либо эта версия промежуточная при обновлении). В дальнейшем из списка процедуры могут быть исключены (в частности в зависимости от параметра "Опциональный").
В параметре Обработчик.Процедура указаны либо процедуры из общего модуля ("БиблиотекаОбновленияИнформационнойБазы.ВыполнитьОбновлениеИнформационнойБазы" — это процедура ВыполнитьОбновлениеИнформационнойБазы() из общего модуля БиблиотекаОбновленияИнформационнойБазы) либо процедура из модуля менеджера объекта ("Справочники.СпособыРаспределенияЗатратНаВыпуск.ЗаполнитьСпособыРаспределенияПоУмолчанию" — Процедура ЗаполнитьСпособыРаспределенияПоУмолчанию() из модуля менеджера справочника СпособыРаспределенияЗатратНаВыпуск).
г). Цепочка вызовов процедур и функций при формировании списка обработчиков обновления.
Так как подсистем может быть несколько (что видно по регистру ВерсииПодсистем), то для каждой подсистемы формируется свой список обработчиков обновлений. Основной путь для конфигурации УПП показан ниже. Для других конфигураций этот путь может быть совсем иным.
//основные моменты формирования и выполнения обработчиков обновления для конфигурации УПП
И в модуле обычного приложения и в модуле управляемого приложения
НеобходимоВыполнитьОбновление(ВерсияМетаданных, ВерсияДанных) //проверка на необходимость выполнения обработчиков обновления
//ряд процедур подготовки выполнения (процедуры проверки полных прав пользователя, попытка установить монопольный режим и т.п.
БиблиотекаОбновленияИнформационнойБазыПереопределяемый.ОбработчикиОбновления(); //список обработчиков выполнения
//Код данной процедуры можно увидеть в предыдущем подпункте. В коде видно что для каждой библиотеки идет вызов своей ветки обработчиков.
//добавление еще одного блока обработчиков обновления из СтандартныеПодсистемыСервер.ВыполнитьОбновлениеИнформационнойБазы
ОбновлениеИнформационнойБазыПереопределяемый.ПослеОбновления() //в УПП выход на пустую процедуру
д). Подсистемы БСП.
Плотно не изучал данный вопрос. Поверхностно просматривая одну из конфигураций БСП видел там процедуры ПередОбновлениемИнформационнойБазы и ПослеОбновленияИнформационнойБазы. Вроде бы эти процедуры были без содержания, но, насколько я понял, такие процедуры присутствуют чуть ли не у каждой подсистемы. Так что учитывайте присутствие подсистем БСП в своей конфигурации.
Переименования и удаления объектов и реквизитов, как правило, происходит в момент создания чего-то нового. Что-то создается, а потом на основе практики часть функционала переделывается. Так было, например, при создании системы ЕГАИС.
Либо над конфигурацией работает несколько групп разработчиков у которых отвратительное взаимодействие. И получается что-то вроде истории про справочник ПакетЭДПрисоединенныеФайлы в конфигурации УПП (обратите внимание на последние две строки на картинке).
Но, насколько я вижу по конфигурации УПП, разработчики также поняли что при удалении объектов могут возникнуть проблемы (в частности возможность потери пользовательских данных — набили данные в регистр сведений, а он в следующем релизе «исчез»). Поэтому у объектов просто в названии приписывают спереди слово "Удалить".
2. Обновление платформы.
Также следует учесть следующий момент. Иногда обновление конфигурации требует одновременно обновить платформу. Например
То есть в данном случае потенциально намечается переход с платформы 8.2.19.130 на 8.3.12. А при переходе с платформы на платформу в разделе «Список изменений и порядок обновления» начинаем изучать пункты «Переход с предыдущей версии на версию …». Потому как там есть много интересного. Например при обновлении платформы до версии 8.3.8 есть в частности:
Обновление платформы может резко осложниться если у вас серверная 1с и на одной платформе функционирует несколько баз данных, при этом ряд баз за прошлые периоды (то есть не обновляются). Вопросы которые желательно решить до обновления платформы: 1)поддерживают ли базы данных за прошлые периоды новую платформу; 2)если у этих баз "своя" защита данных, поддерживает ли эта защита данных новую платформу. Если по одному из пунктов не поддерживает, то возможные варианты решения: 1)если нужно быстро и временно решить проблему — при возможности (небольшая база, мало пользователей, нечасто используется) базу перевести в файловый режим на расшаренный сетевой ресурс; 2)создать новый сервер 1с под новую платформу на отдельном физическом сервере; 3)создать сервер 1с новой платформы на том же физическом сервере где расположен сервер 1с старой платформы (статья есть на этом сайте).
3. Конфигурация как объединение нескольких типовых конфигураций либо типовая конфигурация с значительными доработками.
Все резко усложняется если ваша конфигурация состоит из нескольких типовых конфигураций. Может возникнуть ситуация что одна типовая конфигурация требует новой версии платформы, а другая типовая конфигурация не поддерживает эту новую версию платформы. Либо есть типовая конфигурация с большими доработками. И эти доработки не поддерживают новую платформу. В обоих случаях придется рассматривать возможность переписывать конфигурацию под требования новой версии технологической платформы.
Но перед тем как переписывать конфигурацию под новую версию платформы рассмотрите следующий момент. Нередко конфигурации используют свою защиту. Если у вас такая конфигурация, со своей защитой, выясните поддерживает ли эта защита новую платформу (может быть беда если конфигурация снята с поддержки).
4. Наличие обменов.
Ничего не могу сказать об обменах основанных на КД. Имел практику с обменами РИБ и древним нестандартным обменом.
Все следующее это мои размышления не подкрепленные практикой (то есть, если примените и вдруг что-то не сработает — сам дурак). Потенциально подчиненными узлами можно пропустить некоторые обновления конфигурации. Во-первых, главный узел формирует файл с изменениями конфигурации для подчиненных узлов от последнего факта передачи изменения конфигурации каждому подчиненному узлу. То есть все изменения конфигурации в главном узле придут по обмену в подчиненный узел (упрощенно. Начальный момент — у главного и подчиненного узла единая конфигурация. После этого главный узел обновил конфигурацию (без разницы сколько раз). После этого главный узел будет формировать файл обмена со ВСЕМИ изменениями конфигурации до того момента как получит от подчиненного узла подтверждение о принятии изменений конфигурации). Во-вторых, если ВСЕ обработчики обновления изменяют данные которые также «ходят» по обмену, то, в принципе, пропуск передачи этого обновления в подчиненный узел не критичен. Пример — обработчик изменения модифицирует справочник Банки. Если справочник Банки «ходит» по обмену, то в головном узле изменения будут выполнены, а затем эти измененные элементы справочника «придут» в подчиненный узел. Если справочник Банки не «ходит» по обмену, то в головном узле изменения будут выполнены, а в подчиненном узле пропуск обновления конфигурации может привести к описанным ранее проблемам (изменение имени, удаление объекта или реквизита).
Если обмен не РИБ, но при этом обмене используется передача объектов целиком (довольно редкий случай, насколько я понимаю все таки наиболее часто используются обмены РИБ и обмены основанные на КД). При таких обменах элементы для обмена получают с помощью ПолучитьОбъект() и, как правило, в виде записи XML помещают в файл обмена. Такие обмены подразумевают что структура элементов которые обмениваются идентична (даже изменение порядка реквизитов в структуре объекта либо останавливает обмен либо делает обмен не полным). То есть сами конфигурации могут сильно отличаться. Во всем, кроме объектов которые стоят на обмене. При наличии таких обменов просто надо контролировать идентичность структуры обмениваемых объектов.
5. Обновление сразу нескольких релизов на рабочую базу.
Если ваша конфигурация не типовая либо типовая с доработками. Сильно не рекомендую накатывать оптом несколько версий релизов сразу на рабочую базу. Даже при наличии тестирования конфигурации перед обновлением рабочей базы случаются ошибки. Если есть время и возможность, накатили версию — смотрим рабочий день, два. Затем следующее обновление. Потому что чем больше изменений в конфигурации, тем тяжелее найти причины возникающих ошибок.
6. Дополнения.
Как вносить обновления в саму конфигурацию это отдельная и большая тема. Про это написано немало. Так что просто укажу грабли которые больно били мне голове и лайфхаки на которые я хотел бы обратить внимание.
6.1. Обновление за один раз.
Если в конфигурации сделано множество изменений и дополнений, то внести обновления за раз может и не получиться. А держать открытым окно сравнения и объединения день и больше это чревато (как говорится — кто не терял свою работу за день, то не поймет). Поэтому за первый проход объединял объекты которые не были затронуты изменениями. Плюс "легкие" изменения. Если же надо смотреть логику кода — оставлял на следующие шаги. Сохранил изменения, сохранил измененную конфигурацию — разбираюсь с сложными объектами (например когда в модуле формы добавлено больше 10 новых процедур и функций плюс изменено больше 10 процедур и функций). При этом у меня были открыты три конфигуратора — 1)конфигуратор с окном сравнения новой и старой типовыми конфигурациями; 2)конфигуратор с окном сравнения старой рабочей конфигурации и старой типовой конфигурации; 3)конфигурация разработки. В 1 конфигураторе видна логика работы типовой конфигурации, во 2 конфигураторе видна логика нашей конфигурации. В принципе окна сравнения можно открыть в одном конфигураторе, но иногда требуется открыть кучу дополнительных окон (общие модули, формы и проч.) и тогда становится сложно разбираться какое окно к какой конфигурации относится.
6.2. Несоответствия цветов на окне сравнения/объединения конфигураций.
Почему это так я не знаю. Может это баг платформы и в какой-то новой платформе его пофиксили, может это последствия неграмотного обновления в прошлом. Но у меня не один раз возникало следующее.
Обновление УПП с 1.3.124.1 на 1.3.124.2 (измененных объектов очень мало).
А вот окно обновления конфигурации. По дефолту общий модуль ИнтеграцияЕГАИССлужебныйКлиент не становится на обновление, хотя он в нашей конфигурации не изменялся. Можно заметить отличающийся квадратик в левой части, но у меня различающихся объектов порядка 10000, поэтому все просматривать весьма утомительно.
Плюс маленькая засада для юных падованов — дважды измененные объекты никак не выделяются на общей картине (смотреть на ветку Документы). И если начинающий специалист по обновлениям не знает куда смотреть то он может упустить это.
6.3. Порядок объектов.
Не путать с порядком реквизитов объекта — порядок реквизитов может быть критичен в некоторых обменах данными.
Всегда делаю порядок всех видов объектов по алфавиту. Потому что если в новой типовой конфигурации вдруг изменили порядок ОДНОГО объекта, то окно сравнения и объединения покажет кучу строк с изменившимися объектами. По сути порядок объектов важен только для удобства — логике программы без разницы что выше справочник Вакансии или справочник Бюджеты. Но при сравнении это выделяется и никак отключить нельзя. А высматривать среди сотен строк "Порядок объекта изменен" действительно значимые изменения весьма некомфортно. Можно для упрощения в типовой конфигурации также выстроить все объекты по алфавиту и после этого сравнивать.
6.4. Изменения типовой процедуры измененного объекта (одна из граблей).
Желательно смотреть логику. Тут все становится понятно на примере.
Вот примерно так. Думаю в комментариях укажут и другие ключевые моменты обновлений типовых конфигураций (и типовых дописанных).
Пример информационного окна с ошибкой: "не найден идентификатор в справочнике "Идентификаторы объектов метаданных". Для разработчика: возможно требуется обновить вспомогательные данные, которые влияют на работу программы. Для выполнения обновления можно: - воспользоваться внешней обработкой "Инструменты разработчика: Обновление вспомогательных данных", - либо запустить программу с параметром командной строки 1С:Предприятия 8 "/С ЗапуститьОбновлениеИнформационнойБазы", - либо увеличить номер версии конфигурации, чтобы при очередном запуске выполнились процедуры обновления данных информационной базы."
Если проблема не в справочнике идентификаторов, используйте вторую обработку, полную версию обработки обновлений вспомогательных данных.
: Ошибки при выполнении функции ОбщегоНазначения.ИдентификаторыОбъектаМетаданных().
Для объекта метаданных "Справочник._ИМЦ_МедицинскиеОрганизации"
не найден идентификатор в справочнике "Идентификаторы объектов метаданных" и
регистре сведений "Идентификаторы объектов версий расширений".Для разработчика: возможно требуется обновить вспомогательные данные,
которые влияют на работу программы. Для выполнения обновления можно:
- воспользоваться внешней обработкой
"Инструменты разработчика: Обновление вспомогательных данных",
- либо запустить программу с параметром командной строки 1С:Предприятия 8
"/С ЗапуститьОбновлениеИнформационнойБазы",
- либо увеличить номер версии конфигурации, чтобы при очередном запуске
выполнились процедуры обновления данных информационной базы.При выполнении указанных действий, получаю такую же ошибку и получается замкнутый круг
Компания 1С не только активно занимается разработкой различного вспомогательного программного обеспечения, она следит за изменениями в законодательстве, исправляет и дорабатывает определенные функции. Все нововведения устанавливаются на платформу во время обновления конфигурации. Осуществить этот процесс можно одним из трех методов. Далее пойдет речь именно об этом.
Обновляем конфигурацию 1С
Перед началом работы с данными платформы рекомендуется выгрузить информационную базу, если вы ранее использовали ее. Для этого нужно, чтобы все пользователи завершили работу, а затем выполните следующие действия:
-
Запустите программу и перейдите в режим «Конфигуратор».
Теперь вы можете не бояться, что необходимая информация удалится во время обновления конфигурации. Вам в любой момент будет доступна повторная загрузка базы на платформу. Перейдем непосредственно к вариантам инсталляции новой сборки.
Способ 1: Официальный сайт 1С
На официальном сайте компании разработчика рассматриваемого ПО имеется множество разделов, где хранятся все данные о продукции и файлы для загрузок. В библиотеке присутствуют все созданные сборки, начиная с первой версии. Загрузить и установить их можно так:
- Перейдите на главную страницу портала информационно-технологического сопровождения.
- Справа вверху найдите кнопку «Войти» и нажмите на нее, если вход не был выполнен ранее.
Теперь вы можете запустить платформу и переходить к работе с ней, предварительно загрузив свою информационную базу, если это необходимо.
Способ 2: Конфигуратор 1С
Перед разбором способов мы использовали встроенный конфигуратор только для выгрузки информационных данных, однако в нем присутствует функция, позволяющая найти обновления через интернет. Все манипуляции, которые вам следует выполнить, если вы хотите задействовать данный метод, выглядят следующим образом:
-
Запустите платформу 1С и перейдите в режим «Конфигуратор».
Способ 3: Диск ИТС
Компания 1С активно распространяет свою продукцию на дисках. У них присутствует компонент «Информационно-технологическое сопровождение». Через данный инструмент осуществляется ведение отчетности, налогов и взносов, работа с кадрами и многое другое. Кроме всего, там оказывается техническая поддержка, позволяющая инсталлировать новую версию конфигурации. Выполните следующую инструкцию:
- Вставьте DVD в дисковод и откройте софт.
- Выберите пункт «Техническая поддержка» и в разделе «Обновление программ 1С» укажите подходящий пункт.
По окончании вы можете закрыть ИТС и перейти к работе в обновленной платформе.
Инсталляция новой конфигурации 1С – несложный процесс, однако вызывает вопросы у некоторых пользователей. Как видите, все действия осуществляются одним из трех доступных методов. Мы рекомендуем ознакомиться с каждым из них, а потом, исходя из своих возможностей и желаний, следовать приведенным руководствам.
Мы рады, что смогли помочь Вам в решении проблемы.
Отблагодарите автора, поделитесь статьей в социальных сетях.
Опишите, что у вас не получилось. Наши специалисты постараются ответить максимально быстро.
Читайте также: