Файл поставки. как оставить типовой конфигурацию поставщика? #489366

Чтоб не потерять правки в текущей конфе при обновлении на новый релиз, я, на копию с новым типовым релизом переношу все свои изменения, формирую из копии файл поставки и обновляюсь им. После обновления обнаружил что при сравнении с конфигурацией поставщика никаких правок не показывает, хотелось бы чтоб показывал какбуттно сравнение идет с типовой конфой. Конечно понятно что можно взять чистый от типовой *.cf и сравнить с ним, но это лишний гемор. Может просто я чего не так делал или настройки не так сделал?

никто не знает?

почему просто обновление не делаешь, зачем тебе эти файлы поставки создавать? Лишний геморрой.

а как оперативно обновить и перенести изменения в базу. Единственный вариант что я вижу, обновить рабочую базу, в конфу переносить доработки, и переодически сохранять, потом разом изменить конфигурацию базы данных. Мне этот способ не нравиться, не люблю сидеть в рабочей базе и её ковырять.

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

Нада почитать теорию по хранилищю, просто никогда не заморачивался, думал что это типо просто место куда можно напихать копии Мдшников

ну тогда сделай на копии, а потом "выгрузить конфигурацию в файл", а в рабочей - "Загрузить конфигурацию из файла".

Мля, после моих манипляций с файлом поставщика база теперь не хочет обновляться через поддержку, хотя номера релизов совпадают(у базы 2,5,24 у обновления 2,5,25) должно нормально обновляться, но ведет себя так как будто обновление идет на не поддерживаемый релиз. Чето я не то натворил. Как исправить теперь чтоб обновление нормально проходило через поддержку. И первый вопрос по прежднему открыт, как проводить обновление чтоб и изменения сохранились и текущий рез конфигурации менялся, и конфигурация поставщика была типовой, какую последовательность действий выполнять?

ответ на второй вопрос: делаешь хранилище, там у тебя будет конфигурация поставщика нормальная, а рабочие будешь формировать через файл поставки, там конфигурация поставщика будет твоя, как поставщика...

ответ на первый вопрос: обновляй базу, с которой делал файл поставки...

+ по сути, можно и без хранилища, но с ним удобнее... гораздо...

я уже почистил все следы обновления и файлы поставки снес :) Первоначально было так, сделал копию рабочей базы, её обновлял новыми типовыми релизами, вносил изменения из рабочей базы, формировал файл поставки, обновлял им рабочую базу и так 4 релиза подряд, поглядел все работает и посносил и конфу ту и поставки, так что теперь первоначального варианта базы на компах нету, есть тока текущая база обновленая поставками этими. Ктож знал что такие сложности всплывут.

О как, оказывается обновиться нельзя только если в папке C:Program Files (x86)1cv81 mplts1cHRMНужныйРелиз лежит именно обновление, а не пакет из которого можно установить новую чистую типовую конфу. Ща слил с диска ИТС пакет для установки типовой конфы 2,5,24, он стал доступен при обновлении моей рабочей базы, обнолюсь им, получаеться обнулю все свои изменения и применю схему для обновления из тогда наверно все пучком будет. И че такие сложности придумывать. Народ как вы поступаете когда нужно сразу несколько релизов обновить, ведь глупо делать как я щас делал, изза мелочных правок сидеть и 4 релиза подряд редактировать. Я не сильно еще вник в тему, но подозреваю что привязка жоская изза встроенных обработок запускаемых при первом запуске после обновления, которые по мере перехода от релиза к релизу удаляются из конфигурации. Допустим мне нужно поставить сразу 4 обновления, я беру последний релиз смотрю эти самые обработки смотрю каких нехватает из предидущих релизов копирую их оттуда и обновляю все разом, обработки при первом запуске должны друг за другом отработать и все должно быть пучком. Конечно всяка вопрос уже этото обсуждался, и я пойду в поиск но позже :)