Доброго дня!
Есть прядка 15 различных баз Бухгалтерии 2.0.
Все базы всегда одинакового релиза.
Все на одном сервере.
Платформа всегда свежая.

Все базы имеют одинаковую конфигурацию и она содержит изменения.

Вопрос возник в следующем: соединю все 15-ть баз с одним хранилищем, обновлю одну базу (с сохранением своих изменений) и каждый релиз отправлю в хранилище. Что бы потом, во всех оставшихся 14-ти базах подтянуть из хранилища конфигурации (уже не сравнивая) прокатит ли ? Кто нить так делал ?

обновлять через CF - прямой путь к получению бизнес смазки :)

обновлять надо штатно и потом объединять с точно таким-же релизом содержащим доработки..

зы
на инфостарте поищи всякие обновляторы - их там вагон

(1) если я вас правильно понял, то по вашему алгоритм такой:
1. Обновить одну базу и выгрузить cf
2. В остальных 14-ти база в качестве файла обнавления выбрать этот самый cf ?

В этом случае загрузится и обновленная конфигурация поставщика и рабочая с моими изменениями, так ?

Но если я загружаю из хранилища чем я рискую ?
Номер версии должен изменится
Обработки ИБ после обновления должны запустится
Конфигурация поставщика не обновится, ну пусть. У меня будет одна база из 15 для обновлений, там всегда будет свежая версия конфигурации поставщика.

Просто не могу понять источник возможных проблем ?

(2)
0. остановить регламенты
1. обновить одну базу с учетом всех доработок и выгрузить cf
2. обновить все базы штатно
3. объединить все базы с СF
4. запустить все базы с параметром запуска /ЗапуститьОбновлениеИнформационнойБазы

(4) Поясни зачем пункт - обновить все базы штатно?
Что он такого волшебного делает?

(5) нет возможности перепрыгивания важные релизы

(6) я могу на каждый релиз сделать свой cf и по очереди его на катывать, разве нет ? В это случае останется первых два пункта из (4), это легче

4 пункт из (4) должен запускаться автоматом при смене номера релиза

(8) должен в теории, на практике бывает так:

объединяем "кускам", при этом при накатывании куска где поменялся релиз произойдет обновление а следующие "куски" этого-же релиза пройдут без обновления...

(4) объедиять базы с cf глупо, могут быть глюки. Надо "Загрузить измененную конфигурацию", то есть полностью заменить старый cf на новый.

И по идее, через хранилище все будет то же самое, за исключением того, что не обновится конфигурация поставщика.

кстати Всё еще обновляетесь вручную? Время бесценно, используйте обновлятор.

(12) один из комментов по ссылке

Можно ещё сказать так - если у вас обновление базы в режиме предприятия возможно, то пакетное обновление для вашей конфигурации работает и обновлятор также легко будет обновлять вашу базу.

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

p.s. т.е придется делать на каждый релиз свою версию cf, а это уже противоречит (4)(10)

(13) толку от обновлятора в таком случае 0

(6) Это понятно.
Но в данном случае я так понял что обновлять их надо на один релиз за один раз все.

(11) Обновляешь все базы на один релиз, или сразу на пачку?

(0) Прокатит. Делаем.

Очень сильно экономит время. На копии одной из баз обновили, проверили, закинули в хранилище. В рабочих базах - "получить конфигурацию из хранилища"

(11) Конфигурация поставщика обновляется.

(15) именно так, перепрыгивать ни чего не надо, это точно вызовет проблемы

(18)В общем если на один релиз - то либо через хранилище, либо просто после обновления одной базы выгрузить цф и обновить им остальные.

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

Алгоритм обновления получится следующий:
1. Пока обновления не закончились. Берем 1 базу, накатываем релиз и в хранилище. Конец цикла :)
2. Далее, берем по очереди каждую базу подключенную к хранилищу и по очереди загружаем нужную версию из хранилища.

Звучит заманчиво, быстро и удобно :)

Какую-то пугалку из темы сделали.

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

Если страшно прыгать на большое число релизов сразу, то все равно придется прерывать этот прыжок. Накатил релиз на первую базу и затем раздал его все. Накатил еще один на первую - опять раздал. А как будешь раздавать - разницы нету

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

резюме - все нужно делать вовремя

вот аналогичный опыт нашел http://forum.infostart.ru/forum26/topic99680/

Устанет подключать 15 баз к хранилищу, если они еще из разных шаблонов были сделаны, и обновлялись по разному "сравнение объединение" или загрузкой цф, могут не совпасть идентификаторы типовых метаданных и такие объекты перезатрутся, можно потерять данные.

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

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

уже было про поставку?

(26) ерунда. если базы нужно обновлять от хранилища, то отключать их от этого хранилища незачем

(25) при подключению к хранилищу идет полное замещение конфигурацией из хранилища. Поясните, о чем вы ?

(28) да, но на не пофиг, главное что бы на одной поставка свежая была, на ней свои релизы и делать

(28) поставка нужна для всех баз, только если они не подключены к хранилищу, в противном случае, зачем она нужна 14 из 15 баз ?

и вообще, 14 из 15 мно снять с поддержки, что должно ускорить работу сравнений и прочего, а при отключении от хранилища просто заменить на такой же cf но с поставкой, все

и вообще, 14 из 15 можно снять с поддержки

(30) Вот я про это и говорю, замещение идет конфой сделанной на основе одной из баз, и не факт что данная конфа верно вольется в остальные, у нас были похожие проблемы с метаданными вида Справочник* и УдалитьСправочник*

(35) если уж удалось изначально подключиться к хранилищу, то лучше от него уже не отключаться, без явной нужды.

(31)(32) я про то, чтобы все "продуктовые" базы были на неизменяемой поставке, которая делается из хранилища (в котором уже оригинальная бухия + изменения)

(35) печально. Надеюсь это связанно с ошибкой уровня: очередной глюк платформы, а не архитектурой хранилища. Если так, то что ж поделят, это же 1с, такое где угодно может случится.

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

(37) у каждого своя методика кончено. Но я за эффективность и рентабельность. Взвесив все за и против обоих вариантов можно судить какую стратегию выбрать. Пока плюсов в том что бы все оставлять на варианте как вы пишите я не нашел. Поясните ? А плюсы хранилища без поставки на 14 из 15 это скорость и быстрый возврат к поставке при необходимости.

(38)Мы просто подключали к хранилищу базу не являющуюся прямым потомком этого хранилища,в 1с говорили что это норма и идентификаторы метаданных снятых с поддержки конф могут отличатся

мы же когда берем поставку обновления - там же нарочно сделано именно в формате Обновление "cfu" а не "cf" - для чего?

(41) и вы им поверили?!

(39) да, но этого и не будет, перед подключением каждой базы к хранилищу ее необходимо подготовить

(42) что бы cf меньше воровали и экономить килобайты

(45) три раза ха

(43)Выбора не было у нас)Позже я выяснил что ранее при обновлениях были ручные сопоставления справочников Спр* и УдалитьСпр* поэтому были глюки.

(20) Можно и так, хотя мне кажется быстрее и удобнее через цф.
Обновил - выгрузил.
У тебя цф для каждого релиза.
Потом тупо скриптом обновляешь указывая конкретный релиз и все.

(42) Для экономии, чтобы полностью не выгружать, а только изменения.

(49) не верю

(50) А для чего тогда по вашему?

(48) кстати, а это вариант )

(48) так вообще мега быстро должно получатся, за ночь все и обновил

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

(48) но вот как на практике будет, вы побывали ?

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

(54) вы про предопределенные элементы ?

(57) не только. вообще про отличия между действиями "сравнить/объединить" "обновление из файла поставки" и "загрузить из файла"

(56) тогда и обновлятор подойдет, но только в режиме полного замещения конфигурации, тогда даже скрипт писать не надо

(59) полное замещение подойдет примерно в тех же условиях, когда без глюков подойдет общее для всех хранилище.

(59) базы в оригинале были созданы копией одной поставки или в разное время из разных поставок?

(58) если речь идет о предопределенных элементах, то смысл вижу. Если о идентификаторах объектов метаданных, то не вижу. Ведь в этом случае получается, что идентификаторы меняются, а это принесет полный хаос в механизм сравнения, зачем 1с на это идти ?

(61) в разно, из разных

(63) тогда безопасней сделать файл поставки. хотя вероятность глюков неизвестна, но она ненулевая - это точно.

(63) но можно в любой момент вернуться на арихвную копию... протести, попробуй. Самое жуткое, когда глюк не заметят в первое же время и разные базы успеют нашлепать разное и вероятно достаточно большое количество данных, а потом начнется вой, что у кого-то что-то пропало.

(64) можно сделать вывод, сравнивать только по именам метаданных :) Возможно типовой механизм обновления из cfu тоже сравнивает по именам, мы просто не знаем, иначе ... чудес может быть много! А если я удалю реквизит и добавлю такой же снова, как обновление по идентификаторам обработает ? Это крах

(1) Это ж не загрузка конфигурации, а сравнение и объединение, проблем не будет.

Могу личный опыт рассказать. Я несколько лет обновляю две базы ЗУП 2.5. Обе базы соответственно имеют идентичную конфигурацию. Сняты с поддержки - небольшие доработки.
1. Получаю полный cf-ник типовой нужного релиза.
2. Вношу в него наши изменения.
3. На одной базе захватываю в хранилище полностью конфу, сравнением-объединением накатываю новый cf-ник.
4. Сохраняю, обновляю, помещаю в хранилище.
5. Во второй базе делаю обновление из хранилища.
6. RPOFIT!

Если баз будет не две, а 15 никакой принципиальной разницы не вижу.

Иногда пропускаю 1-2 релиза.
Ни разу не было никаких проблем.
Мне кажется вся тема поиск каких-то гипотетических сферических проблем в вакууме.

(68) пропусти вместо 2 релизов пару десятков и даже на двух базах огребешь проблемы с обновлением. Но только проблема же не в хранилище. О чем выше большинство и рассуждает.

(68) как поступить, когда это не один-два релиза, а много-много релизов нужно накатить на несколько (больше, чем одну) базу?

(68) спасибо, и на счет "Мне кажется вся тема поиск каких-то гипотетических сферических проблем в вакууме." пожалуй вы правы. Но когда нет опыта, можно и подстраховаться :)

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

(69) это да, но это уже вопрос внимательности и квалификации

(70) поддерживаю вопрос, пожалуй это последнее что осталось выяснить

(70) Мое мнение, что это исключительный случай - раз уж базы так запустили, что нужно накатывать много-много релизов, то я бы лучше потратил побольше времени и разобрался бы с каждой базой индивидуально, а потом уже подключил их все к хранилищу.

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

это почти то же самое

(73)(74)(75) я про то, что если мы обновляем базы 1 раз в месяц, у нас за месяц могут быть два релиза