1с обновить конфигурацию уриб
Две подчиненные используются как фронт на точках. ЕГАИС, маркировки нет.
Отключить узлы, пошагово обновить центр, пересоздать узлы(1) То есть те базы на точках вообще удалить, получается?
А если там рабочие места с привязанным оборудованием - ФР и банковские терминалы? Это всё не слетит?
(0) надо какой-то промежуточный вариант. По 2-3 обновления. А то сразу на 2 года дотекущей опасно.
(1) поддерживаю. Практика показала, что обновление РИБ на несколько релизов не работает от слова совсем.
(4) А не проще просто обновлять и делать обмен (один раз или несколько)? Почему именно пересоздать? На настройку рабочих мест может уйти больше времени и больше геморроя.
(6) заново настроить придется только обмен, с чего это вдруг все оборудование перенастраивать?
(7) В Центральной рознице в разделе "Подключаемое оборудование" нет того оборудования, которое есть на точках. И если я узлы создам заново - то ведь и оборудование надо будет заново подключать.
Периферии делаем обычными, обновляем, делаем опять переферийками. И все.
Сотни раз так уже делал.
(9) Тогда не совсем понимаю фразу из (1) "Пересоздать узлы".
Вот у меня есть Розница Центральная, в офисе. В ней сделан РИБ по магазину.
В магазине стоит Розница (файловая база) - узел от Розницы Центральной из офиса.
Фразу из (1) понимаю следующим образом: обновить Центральную Розницу, потом из неё создать заново узлы (базы для магазина) и эти новые базы поместить на компьютеры в магазине, а старые базы вообще убрать.
Узлы заново не надо никакие скидывать.
Поменять переферейку в простую и обратно, это 4 раза нажатия кнопки. Тема разжёвана давно и проще не бывает.
(13) единственное, при создании обратно переферийки, требуется указать ее префикс, как там, РР, или ТТ, как у вас было.
(13) То есть имеется в виду из узлов сделать обычные базы, все три базы обновить отдельно друг от друга, а потом обычные в магазинах сделать опять подчиненными?
Вообще, если есть желание на сохранение актуальности Розницы в типовой привязке к обновлениям, то нужно мониторить постоянно и отслеживать появление критических изменений.
И понятно, что даже если это не РИБ, но решили забить болт на получение в базах регулярных обновлений . - а иногда это весьма разумное поведение.
То все равно нужно каким-то образом состояние мониторить и четко понимать, когда и в каких объемах выполнить обновление.
Ну а дальше надо смотреть уже по конкретике самих баз. Были допилы или не были, как эти допилы дружат с обновлением, тем более, если это обновление в РИБ и т.п.
Опять может быть повторение, что специфика РИБ в частном каком-то случае и периферийка окажется без конфигурации поставщика. Понятно, что если этот РИБ возник с твоим прямым участием, то все эти вопросы интуитивно понятны и не нужны. НО если посмотреть со стороны и внезапно, то надо хоть минимальное обследование проводить.
Есть еще высокая вероятность, что база позволит при грамотном обновлении перепрыгнуть через несколько релизов, но без тестирования такое не предложить.
И даже без наличия конфигурации поставщика тоже, можно взять нужный готовый ЦФ или несколько промежуточных ЦФ и обновить базы на переферийках обновлением из ЦФ, а не передавая их в РИБ обменах.
Между прочим, подозреваю, что часто не очень представляют себе , как происходит передача изменений в РИБ и на что эта передача похожа, если это же самое делать вручную.
Ни объединения, ни сравнения, ни каких-то загадочных манипуляций - ничего этого нет - если вручную, то берешь CF от центральной базы и загрузкой из файла ставишь его в ПБ и только.
Выполнение обработок, которые идут для обновления релиза текущей базы - это уже при первом запуске по сравнению константы начинают запускаться процедуры из глобального модуля.
Если вдруг состояние этих констант из-за какой-то ошибки будет испорчено (допустим, из РИБ по ошибке их перетрут), то процедуры не выполнятся. Даже если кто-то будет упорно накатывать обновки туда-сюда-обратно.
Автоматическое обновление РИБ - это автономное решение для автоматического обновления узлов распределенной информационной базы!
На текущий момент представляет собой конфигурацию на обычных формах с использованием модальности без режима совместимости 8.3.9.
Конфигурация поставляется отдельным файлом, но код отдельных модулей может быть использован с минимальными доработками в типовых решениях!
Но в клиент-серверном режиме даже участие пользователя не требуется для обновления, чем данная разработка может выгодно выделиться!
Технические моменты
Для разработчиков, которые решат использовать модули отдельно от поставки, перечислю основные объекты, для переноса в типовую конфигурацию:
1. Модуль обычного приложения
2. Модуль регламентных заданий
3. Настройка обновления конфигурации
4. Макет файла обновления конфигурации
5. Заставка обновления конфигурации 8.3
6. Обновление конфигурации
Остальные объекты у вас уже должны присутствовать в конфигурации, если функционал отсутствует, то смело копируйте недостающее!
Инструкция
Предполагается, что вы уже работали с РИБ. Но если нет, то для вас есть курс молодого бойца или как быстро научиться создавать РИБ с нуля.
Опишу кратко, что нужно проделать для запуска системы:
Для начала у вас должны быть созданы пользователи с правами администратора в центральной базе и периферийной, когда вы создали начальный образ и зашли в узел.
Для файлового варианта:
Теперь изменяем конфигурацию центральной базы, выполняем обмен РИБ. Регламентное задание "Выполнение обмена" отрабатывает в обоих базах! В периферийной базе запускается помощник обновления. Пользователи выходят, и последний пользователь запускает обновление периферийной базы. Конфигурация автоматически обновляется. Успех!
Для клиент-серверного варианта:
Теперь в периферийной базе требуется настроить форму обновления конфигурации, пример:
Требования:
1. Имя и пароль администратора кластера серверов заполняем (если вы используете).
2. Имя и пароль администратора информационной базы заполняем (галочку "использовать пароль" ставим, чтобы пароль не менялся!)
3. Галочку "Обновлять конфигурацию по расписанию" ставить не требуется!
4. "Путь к файлу" требуется заполнить для 32-битного приложения, хотя уже появился и 64-битный клиент, потому что агент-сервера запускает сервер с 64-битами, но если у вас 32-битный сервер, то проблем не будет!
5. Галочка "Загружать изменения конфигурации" ставить не требуется!
6. Галочка "Обновлять конфигурацию базы данных" ставить требуется!
8. Параметр блокировки необязательный.
Если вы корректно настроили регламентное задание "Выполнение обмена" в обоих базах и настроили права доступа, то регламентное задание отработает автоматически и обновит конфигурацию периферийной базы автоматически! Без участия пользователя. Успех!
Будет дополнено тонкостями настройки или моментами, на которые нужно будет обратить особое внимание при первой настройке!
Автоматическое обновление РИБ - это автономное решение для автоматического обновления узлов распределенной информационной базы!
На текущий момент представляет собой конфигурацию на обычных формах с использованием модальности без режима совместимости 8.3.9.
Конфигурация поставляется отдельным файлом, но код отдельных модулей может быть использован с минимальными доработками в типовых решениях!
Но в клиент-серверном режиме даже участие пользователя не требуется для обновления, чем данная разработка может выгодно выделиться!
Технические моменты
Для разработчиков, которые решат использовать модули отдельно от поставки, перечислю основные объекты, для переноса в типовую конфигурацию:
1. Модуль обычного приложения
2. Модуль регламентных заданий
3. Настройка обновления конфигурации
4. Макет файла обновления конфигурации
5. Заставка обновления конфигурации 8.3
6. Обновление конфигурации
Остальные объекты у вас уже должны присутствовать в конфигурации, если функционал отсутствует, то смело копируйте недостающее!
Инструкция
Предполагается, что вы уже работали с РИБ. Но если нет, то для вас есть курс молодого бойца или как быстро научиться создавать РИБ с нуля.
Опишу кратко, что нужно проделать для запуска системы:
Для начала у вас должны быть созданы пользователи с правами администратора в центральной базе и периферийной, когда вы создали начальный образ и зашли в узел.
Для файлового варианта:
Теперь изменяем конфигурацию центральной базы, выполняем обмен РИБ. Регламентное задание "Выполнение обмена" отрабатывает в обоих базах! В периферийной базе запускается помощник обновления. Пользователи выходят, и последний пользователь запускает обновление периферийной базы. Конфигурация автоматически обновляется. Успех!
Для клиент-серверного варианта:
Теперь в периферийной базе требуется настроить форму обновления конфигурации, пример:
Требования:
1. Имя и пароль администратора кластера серверов заполняем (если вы используете).
2. Имя и пароль администратора информационной базы заполняем (галочку "использовать пароль" ставим, чтобы пароль не менялся!)
3. Галочку "Обновлять конфигурацию по расписанию" ставить не требуется!
4. "Путь к файлу" требуется заполнить для 32-битного приложения, хотя уже появился и 64-битный клиент, потому что агент-сервера запускает сервер с 64-битами, но если у вас 32-битный сервер, то проблем не будет!
5. Галочка "Загружать изменения конфигурации" ставить не требуется!
6. Галочка "Обновлять конфигурацию базы данных" ставить требуется!
8. Параметр блокировки необязательный.
Если вы корректно настроили регламентное задание "Выполнение обмена" в обоих базах и настроили права доступа, то регламентное задание отработает автоматически и обновит конфигурацию периферийной базы автоматически! Без участия пользователя. Успех!
Будет дополнено тонкостями настройки или моментами, на которые нужно будет обратить особое внимание при первой настройке!
В Интернете на тему обновления РИБ найдется множество полезной, но разрозненной информации. Четкий и простой алгоритм не приводится нигде. Как правило, специалисты рекомендуют использование дополнительных обработок, снятие и накатывание CF-ников и тому подобные способы. Однако обновить РИБ можно и при помощи штатных средств путем выполнения нескольких простых операций.
Взяв для примера определенный программный продукт, опишем последовательность действий. Пусть в наличии имеются технологическая платформа 1С 8.2.13.219 с конфигурацией «1С:Управление торговлей 10.3.14.4», где и развернуты РИБ.
Любое обновление предваряется завершением всех обменов – это предотвращает потерю данных.
Первый этап: создание архивных копий.
Второй этап: обновление центральной базы. Если в ней отсутствуют доработки (за исключением добавленной роли), она может считаться типовой и обновляться стандартным путем – последовательным обращением к «Конфигурации», «Поддержке», «ОбновлениюКонфигурации».
Четвертый этап: перенастройка на односторонний обмен (при наличии двустороннего обмена). Она осуществляется выбором параметров «ЦентральнаяБаза − ТолькоВыгрузка» и «УдаленнаяБаза − ТолькоЗагрузка».
Пятый этап: выгрузка пакета из обновленной центральной базы.
Седьмой этап: обновление удаленной базы. Оно реализуется нажатием клавиши F7 или последовательным переходом «Конфигурация» − «ОбновитьКонфигурациюБазыДанных», при этом обновление посредством «Поддержки» блокируется. Потом производится «ПринятиеИзменений» и осуществляется «ВыходВРежимПредприятия» (также выполняемый нажатием клавиши F5).
После прохождения всех этапов процедура обновления удаленной базы будет завершена. Заключительным штрихом станет повторный прием того же пакета в удаленную базу. Теперь он будет читаться без ошибок.
Читайте также: