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

Красава! Я в свое время запарился после таких дятлов базы править....ставять их обратно на поддержку...

Автор, ты что натворил? Неужели ты думаешь что в фирме 1С сидят люди глупее тебя?

(1) Нет, ну данные вроде на вид не пострадали. Бэкап, естественно я тоже сделал.
(2) На поддержку, после этой операции она стоит.

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

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


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

(4) она то стоит, только сравни версии релизов....в поддержке и по факту!

(1)+1 "вроде на вид не пострадали" )

v8: Оцените такой способ прыжков через релизы.

(4)[ну данные вроде на вид не пострадали.]
положим ты не заменил в счёт-фактурах перечисление, поскольку не запустил промежуточную обработку, вылезет это 19 января, когда книги покупок не будет

(7) Сравнивать будет уже другой специалист. Сравнивать и плеваться....

(0) А что, обновить через поддержку на последний cf не осилил?

(10) Ошибочно так думать, обработки все запускаются

(0) никому не говори! А зокащек на кнопочку "!" нажмет увидит правильный релиз последний

(12) +1 Но данные все равно могут теряться

(0) Не понял, а зачем было снимать с поддержки, если у тебя был файл с полной конфигурацией (cf)?

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

А так - есть вероятность, что shuhard в (1) прав - "наебнулась у Заказчика часть данных".

Какашками уже закидали?

Ну хорошо, поднимать последовательно так
33, 34, 35, 36, 37, 38, 39, 40, 41
или 33.1 33.2 33.3 33.4 33.5 ...... ?

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

пля... ну кто? КТО вам всем таким "умным" сказал, что можно так запросто взять и загрузить конфу?
PS да еще взял и с поддержки снял... молодец, да и только

Удаление объектов в 1С происходит так:
1) Нужно удалить счет в плане счетов - изменения законодательства. Счет переименовывается в СчетТакойТоУдалить, обработка обновления перемещает данные с этого счета на тот, на который теперь надо
2) В следующем релизе счета в объектах уже нет.

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

(13) одинес имеет обыкновение удалять процедуры обработки старых релизов

+20 в режиме предприятия "сервис" - обновить конфу и идешь пить чай

(19) В чем проблема то ? В служебных обработках после такого обновления? Так они выполнились при запуске Предприятия, начиная с 33 по 41 релиз.

(24) читай (21)

автор - идиот

порисуем?
http://risovach.ru/comix/146292.html

(22) оно это стало делать специально, т.к. идиотов много

Короче, Автор! Восстанавливай бэкап (пока клиент не наработал кучу данных). Последовательно накатывай релизы - или отдай деньги и не позорь людей.

(0) Интересно если не знал что получится, почему не делал наверняка как надо?

(30) Интересно было попробовать.

(20) Я всегда так делаю, чтобы на подержку поставить

"болван" уже говорили?

зря ты так...

(31) А попробуй палец глубоко в нос засунуть..... Интересно же....

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

(0) делай, бери деньги и беги :) а другие потом на этом заработают :)

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

(35) Это я уже пробовал, это мне уже не интересно :)
А вот загрузить конфигурацию, я не пробовал.

(24) Дезоксирибонуклииновая кислота
я думаю в ней

(39) Чего не пробовал?
(0) а как же ваше Приехал, снял, загрузил?

(0) релиз не подготовить что ли было заранее?

(41) Ну так, теперь попробовал.
Только не понятно, одно между 32 и 41
90 промежуточных релизов, сколько же это времени нужно чтобы их последовательно обновлять или обновлять можно все таки пропуская какие то ?

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

говорили уже про обработки запускающиеся после обновления?

(43) Можно было за 3 обновления пройтись нормально. 35-38-41.

По какому приципу выбирать, какие релизы пропускать ?

(47) а самому подумать?

или 1Сики только деньги брать должны уметь?

(47) читать РИДМИ у релизов до просветления. внезапно чтоли?

(47) Ты извини (ничего личного), но я бы убила.... Был у меня такой случай - ЗУП поднимала....

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

Зачем  снимать  с поддержки  , кто мешает через поддержку    обновить  и выбрать  вместо cfu  свой  cf .

(48)Ну хотелось бы, чтобы было хотя бы так32.1-33.9-34.9-35.9-36.9-37.9-38.9-39.9-40.9-41.6
А потом, что Вы на меня накинулись тут все. Клиент все равно хотел на халяву, то есть он ничего не платил. Типа бонус.

(47) См. удаленные объекты и модуль обновления ИБ. Надо чтобы за это количество релизов физически не удалялись объекты, требуемые обработкам обновления на более поздние релизы и чтобы не удалались нужные процедуры обновления в модуле. Как правило, 2-3 релиза можно смело перескочить без проверки. Больше - только с проверкой.

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

(43) Где ты там увидел 90 релизов? 8-)
(46) Это фантастика, обоснуй!
Мыши плакали и кололись, но все равно продолжали жрать кактус ))))

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

(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) Известное дело, генеральный в курсе каждой строчки кода. Без его подписи ничего нельзя делать.

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