Всем привет!

Частенько бывает, что нет возможности обновить 1С с компьютера разработчика, который собственно и дорабатывал конфигурацию. Как правило это минорные обновления с новыми объектами конфигурации БУХ. Используем следующую схему: Разработчик сохраняет обновление со своего компьютера (Серверная БД), а после другой разработчик подключается через РДП на сервер открывает конфигуратор и обновляет БД. Проходит эта схема плохо. В половине случаев 1С намертво виснит. После этого 1ый разработчик может зайти со своего компьютера и безпроблемно накатить это обновление.

Тыкните носом, что курнуть по решениям этой проблемы. Может вы встречались с такой проблемой, как исправляли?

8.3.8.1652
Сиквел

Как-то через гланды обновляетесь

(0) почистить кэш у программера, нарастить ОЗУ его компу до 4 гиг (можно больше). Проверить через конфигуратор наличие активных пользователей (попросить выйти) и остановить регламенты (это для надёжности). Не обновлять конфигурацию динамически (если уже, то надо искать информацию как побороть последствия такого счастья)

(1) Ну да, но бывает необходимость, есть аналог?

(2) Спасибо! Вроде все делаем, только регламентные не отрубаем, приму к сведению!

(3) так, стандартно, должно быть примерно так: Разработчик сохранил CF, подключился к нужной БД и залил обновления. Без беготни по RDP с разными юзерами и т.д.

(5) В нашем случае, проще будет обязать разработчика делать дело до конца. В корректировку 0-поста скажу то, что база то одна и та же, но подключение действительно происходит с разных мест и под разными пользователями, как верно сказал Fedor-1971

".. а после другой разработчик подключается через РДП на сервер открывает конфигуратор и обновляет БД." - не "обновляю", а "загружаю".
И после загрузки конфигурации, не обновляя конфигурацию БД, выхожу из конфигуратора; очишаю кэш; захожу в конфигуратор и обновляю конфигурацию БД.
Не спрашивайте, я не знаю зачем такие танцы с бубном я устраивал на предыдущей платформе. Наверное потому что, если в одном сеансе сразу обновить конфигурацию и принять изменения в БД, то работа конфигуратора завершалась аварийно с непредсказуемым вариантом.

А насчет остановки регламентов - активно плюсую. И добавлю: не только останавливать, но и перепроверять что фоновые задания завершили свою работу.

Рекомендую скрипт по обновлению из cf
https://gist.github.com/a-sitnikov/85a870b2375fd253e7657e8ba45f5552

(9) Выдрал из типовой?

(10) В типовой скрипты на жс?

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

(11) А на чем же еще?

(11)Открой модуль обработки обновления конфигурации и удивляйся.

(12) Обновляться рабочую базу из хранилища?

(15) по уму - из поставки надо.

(15) Должно быть два хранилища. )

(17) Это минимум )))

(17) а точно хватит? может больше 2 боевых, 2 резервных, 2 в облаке?

(19) Мне кажется ты не понял зачем и два то нужно.
Это типо веток в гите

(20) Мне кажется, что тебе не кажется )

(20) я вообще не понял принципа работы с 2мя хранилищами, если честно. они не коррелируют друг с другом и при обновлении одной конфы из 2х хранилищ будут возникать коллизии. в чем прикол? а если предполагается, что 2е хранилище используется лишь для переноса изменений в боевую базу - то не понятно, почкму тебя не устраивает файл поставки. разъясни, может просто я недалекий и всю жизнь делал не правильно