Уважаемые специалисты, посоветуйте пожалуйста, как решить такую проблему: конфигурация обновляется с помощью "Загрузить конфигурацию из файла" - обновление из сервиса Иж-Ти-Си использует именно такой путь. Проблема в том, что "Загрузить конфигурацию из файла" несовместимо с хранилищем и приходится отключаться от него, а при повторном подключении к хранилищу загруженные изменения будут удалены. Нет ли какого-нибудь способа сделать так, чтобы и "Загрузить конфигурацию из файла" работала и от хранилища не надо было бы отказываться?

Захватить всё рекурсивно не пробовал?

(1) Извините в какой момент? Когда конфигурация подключена к хранилищу - пункт меню "Загрузить конфигурацию из файла" - недоступен и надо от хранилища отключиться. После отключения от хранилища - захват (включая рекурсивный) - недоступны. После обновления через "Загрузить конфигурацию из файла" - попытка подключения к хранилищу приводит к предупреждению "данная конфигурация будет заменена конфигурацией из хранилища".

(0) Две отдельные базы.

Одна - для разработки и установки обновления, подключенная к сервису Иж-Ти-Си, но НЕ подключенная к хранилищу.

Вторая - продуктив, подключенный к хранилищу.

Продуктив придется обновлять в два прохода - сначала через "Поддержка - Обновить конфигурацию" со всеми снятыми галочками в окне сравнения (чтобы обновилась конфигурация поставщика), а потом через "Сравнить, объединить с конфигурацией из файла" с файлом cf, полученным из разработочной базы. Естественно в продуктивной базе должны быть захвачены рекурсивно все объекты дерева метаданных, начиная с корня.

Таким образом получаем в хранилище продуктивной базы всю историю изменений.

Разработку и установку обновлений вести строго только в разработочной базе. В продуктив изменения должны попадать через сравнение/объединение.
Никакие другие базы и/или пользователи к данному хранилищу не должны быть подключены.

(3) Большое спасибо за идею! Не знаю взлетит или нет в наших условиях, но выглядит привлекательно.

(3) Вдогонку - я правильно понимаю, что на первом этапе надо давать типовую конфигурацию, а на втором уже со всеми изменениями?

(3) Верный вариант. Хранилище имеет ряд ограничений. Посмотрим что сделают с этим в EDT, но он пока сырой.

(6) Каким бы не было хранилище ограниченным, в групповой разработке без него очень тяжело.

(5) Да, первый этап выполняется что бы обновилась конфигурация поставщика, так как при сравнении объединение конфигурация поставщика не изменяться.
Руки бы поотрубал тем кто не обновляет конфигурацию поставщика, очень много гемора с этим когда берем на поддержку конфигурацию, доработанные кем то через хранилище без этого способа.

(8) я не понимаю тех, кто не обновляет конфигурацию поставщика - зачем они это делают? Это же в чистом виде стрельба в свою ногу.

(9) Некоторые считают, что это стрельба в чужую ногу )

(9) это лишние 20 минут ждать, а клиент вместо денег дал конфетку

(11) ну или обещал порекомендовать в блоге вместо денег, как это можно сейчас

(12) модно

Просто захватить все объекты в хранилище и загрузить конфу не предлагать?

А, ясно: пункт "загрузить конфу из файла" недоступен

Выпили конфу поставщика вообще из продуктива, держи ее только в препроде

(16) спасибо за идею, а как это сделать? И честно говоря не хотелось бы её удалять - иногда полезно видеть, что изменено по сравнению с типовой.

(17) "иногда полезно видеть, что изменено по сравнению с типовой" // Ну так для этого ее конечно же в препроде оставляешь, который и обновляешь каждый раз. В прод только cfu'шку уже передаешь.

"как это сделать?" // Захватить корень, далее Поддержка - Настройка поддержки - Снять с поддержки

(0) "обновление из сервиса Иж-Ти-Си использует именно такой путь".Почему? Их требование или такая практика у вас?

(20) Это их рекомендованный метод обновления. Попытка как-то сделать по второму варианту (через сравнение) приводила к какому-то факапу.

(21) а стандартный вариант через обновление конфигурации поставщика запрещен?

(10) Да так и есть. Некоторые держат копию базы клиента с конфигурацию поставщика только у себя, а реальную базу клиента оставляют со старой конфигурацией поставщика. И потом долго и нудно приходиться обьяснять клиенту, что необходимо выполнить анализ доработок в базе и первое обновление встает в нормальную такую сумму, на что мы получаем ответ заказчика - а вот предыдущие разработчики обновляли в 3 раза дешевле.

(22) этот вариант не подходит при обновлении базы через сервис Иж-Ти-Си.

(22) скорее всего всего у конфигурации в конфигурации в файле есть ряд доработок, которые нужно сохранить. (21) Так?
Если конфигурация файле типовая ничто не мешает использовать "Обновить из файла".

(24) Это показала практика или прямой запрет в инструкции от Иж-Ти-Си?
Извини за занудство, но мне пока не понятно, почему поставщик отказался от типовой стандартной схемы.Возможно, ответ на этот вопрос, натолкнёт на менее затратный и альтернативный способ обновления.

(25) Гадать и я могу. Пусть ответит ТС.

(27) ИЖ-ТИ-Си и выполняют обновление конфигурации, и передают уже готовую обновленную, нетиповую конфигурацию, а автор хочет загрузить ее в свое хранилище.

(28) в (14) уже предложили рабочий вариант

(29) это нерабочий вариант, см. (15)

(30) С точки зрения основной конфигурации что загрузить из файла, что сравнить-объединить с флагом "Взять из файла" не отличаются. Просто конфа поставщика останется необновленной, но зачем она в проде - только для удобства и чтоб не потерять типа. Но если собраться с силами и все-таки делать сначала на препроде, то проблем особых нет.

Как вариант создать хранилище по-новой, старое оставить для истории какое-то время - иногда перед массовыми обновлениями так делаем

(32) обновления выходят достаточно часто (КА2), поэтому каждый раз пересоздавать хранилище - не вариант.

(33) Ну тогда без второй базы ("препрод") не обойтись в любом случае