Есть конфигурация которая обновлялась не через поддержку, а с помощью сравнения/объединения, соответственно сейчас версия конфигурации поставщика отстает от версии рабочей конфигурации. Вопрос: как выровнять версии рабочей конф и конф поставщика. Есть пару идей, но не известны последствия, может подскажете... Первая: через поддержку выбрать обновление с файлом поставки релиз которого соответствует рабочей конфигурации и при объединении снять слева все галочки. В результате должна обновится конфигурации поставщика, а рабочая останется без изменений. Вторая: сохранить рабочую конфигурацию в файл, затем через поддержку обновить конфигурацию с помощью файла поставки релиз которого соответствует рабочей конфигурации, при чем при обновлении установив слева все галки, и потом не обновляя конфигурации БД сделать сравнения/объединение с ранее выгруженным сфником рабочей базы. Подскажите как правильней это сделать?
У нас здесь своя атмосфера...
Группа: Основатель
Сообщений: 13955
Из: Киев
Спасибо сказали: 4520 раз
Рейтинг: 3642.8
Цитата
Первая: через поддержку выбрать обновление с файлом поставки релиз которого соответствует рабочей конфигурации и при объединении снять слева все галочки.
И разве после этого что-то произойдёт?
Цитата
Вторая: сохранить рабочую конфигурацию в файл, затем через поддержку обновить конфигурацию с помощью файла поставки релиз которого соответствует рабочей конфигурации, при чем при обновлении установив слева все галки, и потом не обновляя конфигурации БД сделать сравнения/объединение с ранее выгруженным сфником рабочей базы.
Ну это можно только опытным путём проверить. Если реструктуризации никакой после этого не будет, то наверное всё будет нормально.
И посмотрите вот статейку: [необходимо зарегистрироваться для просмотра ссылки]
А смысл действий этих? Если вы хотите обновляться через поддержку, а не сравнить/объединить, то могу подсказать способ, которым сам догонял так Бух 8.1.
После того как мы снимем все галки слева рабочая конфигурация останется без изменений, а конфигурация поставщика обновится до соответствующего релиза.
Цитата(Vofka @ 23.05.11, 10:45)
Ну это можно только опытным путём проверить. Если реструктуризации никакой после этого не будет, то наверное всё будет нормально.
а вот здесь я боюсь что разъедутся идентификаторы объектов что в будущем усложнит обновление.
Цитата(Ziam @ 23.05.11, 10:50)
А смысл действий этих? Если вы хотите обновляться через поддержку, а не сравнить/объединить, то могу подсказать способ, которым сам догонял так Бух 8.1.
именно так я и хочу обновится (через поддержку). Буду очень признателен если поделитесь своим опытом обновления.
Мне ваш 2-й вариант чего-то кажется более правильным. Мы делали так. Обновляли через поддержку с доступным релизом. Слева галочку оставляли только на против пункта Номер релиза (или как он там зовется, не помню дословно). Таким образом "выровняли" номера релизов конфигурации поставщика и нашей. А в последнем обновлении уже накатывали новый релиз, на нашу конфу с изменениями. З.Ы. Изменений было дофига, но у нас был их перечень.
А после этого уже делали сами файлы поставок с базы "для разработки" (назовем ее так) и накатывали их на "рабочую" базу. Этим добились что наша измененная конфа опустилась в поставку. Теперь "рабочая" база с красным замочком и НЕ типовая. А все новые релизы накатываем сначала на базу "для разработки", потом формируем поставку, потом накатываем поставку на "рабочую". Все через поддержку. Только приходится ручками тыкать нужный файлик. И иногда cfu не хотят подхватываться. С чем это связано - пока загадка.
Мне ваш 2-й вариант чего-то кажется более правильным. Мы делали так. Обновляли через поддержку с доступным релизом. Слева галочку оставляли только на против пункта Номер релиза (или как он там зовется, не помню дословно). Таким образом "выровняли" номера релизов конфигурации поставщика и нашей. А в последнем обновлении уже накатывали новый релиз, на нашу конфу с изменениями. З.Ы. Изменений было дофига, но у нас был их перечень.
А после этого уже делали сами файлы поставок с базы "для разработки" (назовем ее так) и накатывали их на "рабочую" базу. Этим добились что наша измененная конфа опустилась в поставку. Теперь "рабочая" база с красным замочком и НЕ типовая. А все новые релизы накатываем сначала на базу "для разработки", потом формируем поставку, потом накатываем поставку на "рабочую". Все через поддержку. Только приходится ручками тыкать нужный файлик. И иногда cfu не хотят подхватываться. С чем это связано - пока загадка.
Судя по описанию вы обновлялись по первому варианту, с тем лишь уточнением что поставили галочки напротив версии релиза, но это можно было сделать и вручную в свойствах конфигурации. Чую что второй вариант неправильный, но не могу объяснить для себя почему, вот и написал с надеждой что кто то разъяснит. [необходимо зарегистрироваться для просмотра ссылки] здесь автор тоже использует второй метод .
Судя по описанию вы обновлялись по первому варианту, с тем лишь уточнением что поставили галочки напротив версии релиза, но это можно было сделать и вручную в свойствах конфигурации. Чую что второй вариант неправильный, но не могу объяснить для себя почему, вот и написал с надеждой что кто то разъяснит. [необходимо зарегистрироваться для просмотра ссылки] здесь автор тоже использует второй метод .
Ну второй вариант никто не мешает на копии проверить. А по поводу вручную в свойствах не совсем верно. В свойствах вы поменяете, но это изменение не повлияет на конфу поставщика. А новые релизы сравниваются именно с ней. Мой вариант заставляет изменить номер релиза, как в нашей конфе, так и в поставщика.
Ну второй вариант никто не мешает на копии проверить. А по поводу вручную в свойствах не совсем верно. В свойствах вы поменяете, но это изменение не повлияет на конфу поставщика. А новые релизы сравниваются именно с ней. А мой вариант заставляет изменить номер релиза, как в нашей конфе, так и в поставщика.
Для того чтобы растопить лед непонимания введу условные версии программных продуктов: допустим у вас конфигурация поставщика версии 1.1, версия вашей рабочей конфигурации 1.6. Для того чтобы выровнять редакции мы берем: конфигурацию поставки 1.6, через поддержку запускаем обновление (при условии кончено же что предусмотрено обновление с 1.1 на 1.6), перед нами появляется окно сравнения и объединения, слева снимаем все галочки, этими действиями мы подтверждаем что наша конфигурация поставщика версии 1.1 перепишется новой конфигурацией поставщика версии 1.6 (перепишутся все объекты метаданных). В результате версии наших конфигураций выровняются. Если в моих рассуждениях есть какая то неправильность укажите пожалуйста на нее.
... слева снимаем все галочки, этими действиями мы подтверждаем что наша конфигурация поставщика версии 1.1 перепишется новой конфигурацией поставщика версии 1.6 (перепишутся все объекты метаданных)...
Думаю не отметив ничего, вы ничего не получите, ибо нечему будет перезаписываться. Можете попробовать на копии. Мне кажется, что ничего не произойдет. Я не знаю как происходит принятие изменений, но при сравнении я заметил, что конфигурация из обновления поочередно сравнивается с нашей конфой и конфой поставщика. Именно в такой последовательности. Потом выскакивает окно с результатами сравнения. Думаю принятие изменений происходит в такой же последовательности. Не выбрав ничего, вы не запускаете механизм непосредственно объединения. Можете проверить. Аська моя в профиле. Могу порыть в архивах инструкцию с картинками. Может вам так более будет понятен процесс, который я предлагаю.
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!
Обновление конфигурации поставщика 
23.05.11, 9:33
