Приехал в фирму, в которой стоит БП 2.0.32, ну чтобы не обновлять последовательно, снял конфу с поддержки и сделал "Конфигурация\Загрузить конфигурацию" 2.0.41.6.cf. Собственно, всегда интересовал вопрос насколько этот способ обновления правильный ?

хаааароший бонус однако. Долго помнить будет )

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

(0) круто. Готовь вазелин.

На самом деле "прыгать" через несколько можно, но не так.

(58) + сто тыщ мильенов....

PS Теперь клиент долго будет бонусы стороной обходить.....

PSS Да не накинулись, а УЧАТ уму-разуму.

(53) Да вы фантаст!

(59) Да их во внешнюю обработку можно все свалить, главное чтобы данные остались. Впрочем, можно вообще за 1 шаг, но надо не ставить галочки на удаляемых объектах, потом выполнить обработку обновления, и после этого только удалить физически удаленные 1С объекты.

(57) Это я образно. Считай 32.2 32.3 32.4 32.5 32.6 и т.д. Дофига.

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

а вобще, когда работал во франче, люто ненавидел различных дятлов, которые лезут обновлять базы

(57) см (55) как-то так я и релизов через 15 прыгал. Только нужен предварительный анализ

(61) Хотел поделиться с миром. Вдруг это одному мне пришло такое в голову (загружать cf), а нет. Очень Жаль.

(62) отнюдь, это вы просто недостаточно опытны)

(67)+1 да хоть через 100500, главное знать, куда прыгаешь

(62) см. и (52) =) все реально, сам так делаю на типовых, никакой фантастики

(69) к (66)

ну если база пустая) то

(67) над не загружать cf а через поддержку - выбор файла и т.д. так вы обновите и конфу поставщика) вашим же способом она осталась старой

(73) по кнопке загрузить конфу из файла сменятся все 3 конфы. конфа поставщика не меняется при сравнении-объединении

(67) Любой опыт - это ОПЫТ.

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

Со следующим обновлением будут проблемы.

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

(77) Не будет проблем. Проверено.

(76) > в старой конфе мог бы быть реквизит
В данном случае его нет.

зачем было с поддержки снимать только?

(78) Спасибо, за поддержку. В следующей раз я буду последователен.

(78) вот именно, что для конкретных. Если не было конкретных структурных изменений и какой нибудь хитрой обработки обновления базы. Впрочем все это проверяется глазками.

(83) Это проверяется двумя вещами:
1. Сравнение конфигураций
2. Проверка обработки "Обновление информационной базы"

(81) Когда она была на поддержке cf не хотел загружаться.

(63) подскажу...
объекты иногда переиминовывают

(84) я в курсе. Мне обычно хватает просмотра кода обработки глазками. Там сразу видно на каком релизе может быть кирдык и его нельзя просто так перепрыгивать.

(87) Правильно понимаю, что ты не поддерживаешь категоричное отрицание данного способа? )

(79) Будет - проверено, он даже не определит актуальное обновление правильно.

(85) надо было через обновление делать

(78) Это верно только если до этого обновления нормально делали, и то не всегда. А вдруг у некоторых объектов метаданных идентификаторы в исходной конфигурации отличались от идентификаторов таких же объектов в конфигурации 1С? Тогда эти данные просто сотрутся.

(86) Дык внутренний идентификатор-то остается. И, как правило, 1С более 1 раза не переименовывает. Скорее уж вылезет ошибка из-за очередной перетасовки процедур и функций по общим модулям.

(88) категоричное нет. Я же сказал, что для конкретного случая катит. Как и мой способ описанный в (52). Тоже нужен анализ обработки обновления.

ааа, так он даже не объеденить сравнить сделал а загрузить, но это воообще жестко, наверное еще даже и копию не сделал.

До сотки дотянем?

Иначе бы не писало 1С, о том, что такой-то релиз относится к такому-то.

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

единственное для чего нужны промежуточные релизы, это если в одном из них реквизит пометят на удаление. а в другом удалят

(32) еще один...

99

100

101

(93) Чукча писатель? Не заметил упоминания бэкапа? )
(95) 1С пишет всякое. В данном случае они гарантируют обновление, а остальное на усмотрение программиста.

Фееричная ветка. Внезапно пятница приключилась. Автору - зачет.

(54) "Клиент все равно хотел на халяву"
(85) "Когда она была на поддержке cf не хотел загружаться."

Жги дальше :о)

(103) Зато бесплатно :) Будет потом знать, что одинэсники забесплатно только вредить могут :)

(102) В (0) не заметил.

(54) "Клиент все равно хотел на халяву"  


НУ тогда все верно ...надо же таких клиентов иногда наказывать... я и сам так делаю...=)

(0)
http://users.v8.1c.ru/project.jsp?id=Accounting20_82

Анализируй это.

(107) Анализируй то. Попробуй сравнить 32-ой и 41-й релиз. Много ли удаленных объектов найдешь.

(108) Для появления косяков достаточно чтобы при параллельном существовании редакций 1.6 и 2.0 1С добавила какой-то объект как в 1.6, так и в 2.0 не через сравнение и объединение. Они будут иметь разный идентификатор. Далее, в зависимости от того, как переходили на 2.0 возможен вариант, когда у объекта останется идентификатор из 1.6. Тогда при загрузке конфигурации 2.0 его данные просто удалятся.

Был бы разговор о УППрыще - я бы давно уже автору сказал где и что он потерял перепрыгивая. Эй, у кого БП, - скажите автору куда смотреть :)

(109) Достаточно всякого разного. В данном случае такой метод подходит. Подчеркиваю, именно в этом случае при этих условиях.

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

(31) Так ты на кошках пробуй!

+(113) Если не любишь.

(111) Что, 1С ничего не добавляла одновременно в 1.6 и 2.0? Или знаете, что базу начали вести сразу в 2.0? Откуда такая уверенность при полном незнании внутренностей конкретной БД? Я, кстати, назвал лишь 1 из возможных причин расхождения идентификаторов, есть и другие. Уверены, что их в данной БД тоже нет?

(43) Написано же какие можно пропускать.

(54) А к че, типа если бонус то и работать не надо? Ты же договаривался.

Да пофиг уже. Хотели быстро и бесплатно. Я каприз исполнил. Кстати, запустилась нормально, сервисные обработки отработали, ни на что не ругалось. Я подозреваю, что и 99 % данных как минимум совпадут с предыдущей версией базы. Больше постараюсь так не делать, хотя до этого я всегда обновлял базы через cfu.

(115) Последний релиз 1.6:
1.6.31.1, выпущен 19.04.2011
Примерно в то же время выпущен релиз 2.0.22.1 (20.04.2011)
У автора 2.0.32 (24.01.2012)
Где там ваше расхождение, вызванное одновременным изменением идентификаторов?

(115) > есть и другие. Уверены, что их в данной БД тоже нет?
Вы сначала назовите своими именами эти "другие" причины, а потом спросим у автора.

+(118) "сервисные обработки отработали" а че им не отработать? Молча пропустили косяки, за не имением объекта.

(119) Расхождение у 1С, пока она параллельно выпускала 1.6 и 2.0. При переходе на 2.0 оно могло остаться, в зависимости от того, как переходили на 2.0.

(120) Их слишком много, чтобы перечислять, и они слишком специфичны, чтобы компактно их описать в общем виде.

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

v8: Обновление БП с 28.3 на 37.13

+(123) я прыгал без снятия с поддержки, все ок

(122) База типовая, никто не добавлял туда реквизитов.

(121) Молча они ничего не пропускают, не надо щеголять своей неграмотностью.

(122) Так "могли" или "остались"? Вы начинаете хаять метод, не узнав полных условий.

(123) Во, так вот все франчи оказываются так делают !!!
Пора мне открывать свой франч :)

(125) Да может и взлетит, просто это как повезет.

(125) Это лишь уменьшает вероятность косяков, но не исключает их.

(126) Для того, чтобы хаять достаточно чтобы просто могли. Применять такой метод можно ТОЛЬКО если 100% знаешь, что таких расхождений НЕТ.

(129) 100%-й уверенности в результате нет и при типовом обновлении. Вы мимо кассы, извините.

подождем результатов... годового отчета.... появления ветки "HELP!!!!!! ПАНИКА!!!!! СПАСИТЕ!!!БАЗА!!....

День прошел, претензий пока не было. Неделя пройдет, посмотрим. В принципе бэкап есть , КД тоже. База очень маленькая по объему содержащихся данных. Так что... На будущее буду стараться поднимать не сильно прыгая через cfu.

(130) При типовом обновлении 1 косяк случается на порядок реже косяков при загрузке даже на относительно новой типовой базе. Когда база старая - вероятность косяков при простой загрузке позрастает на порядки.

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

при обновлении реквизиты не удаляются, а остаются в базе данные полюбому не потеряются

(131) Пилите Шура, пилите. Они золотые.

(133) Вы же так не обновляли. Откуда данные о порядках косяков? )

32 не такая уж и древняя обновляй последовательно

т.е

(136) да это теоретик. Он тут такое отжигает. Прикинь у него руководитель проекта и его помощники - пишут алгоритмы. И это было не в пятницу сказано.

+(139) это я про товарища из (133).

(136) С чего вы это взяли? ;) Пытался делать такое с копией ради интереса - и вылезали косяки на некоторых базах. Причем баз для экспериментов было много, некоторые пережили целых 3 смены редакции.

То, что надо обновлять только последовательно - фуфел. Можно прыгнуть через несколько релизов, при этом не снимая с поддержки. Для этого надо:
- поставить полную инсталляцию текущего релиза
- через поддержку обновить
- PROFIT!!!

(139) У вас просто зашоренный взгляд на вещи ;)

(0) Автор у тебя ник правильный, 1cv8 написанный через ж.пу, и делаешь ты всё через ж.пу.

А, ну да:

(144) Привет, Д'Артаньян )

(142) Забыл дописать 4 и 5 пункты.
-Получить детскими грабельками по Фаберже.
-Успеть написать заявление по собственному, пока не уволили за проф. непригодность.

(54) >>Клиент все равно хотел на халяву, то есть он ничего не платил. Типа бонус.

Молодец. В (0) -- достойная месть

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

(0) благодаря данному поступку у всех присутствующих есть работа. это же хорошо. спасибо за службу.

(147) у тебя есть предметные возражения? если да, давай разберем.

(144) Все через ж.пу делаешь ты, а я люблю экспериментировать.

(147) Не надо на всех проецировать свой печальный опыт )

Про перенос данных во время обновления наверно уже сказали

Вкатить ущерб по самое небалуйся

(0)
Кстати интересно - а генеральный в курсе был ?

(155) Известное дело, генеральный в курсе каждой строчки кода. Без его подписи ничего нельзя делать.

Как страшно жить....