Коллеги, подскажите пожалуйста! Стоит Бухгалтерия предприятия, редакция 2.0 (2.0.37.12), в нужном каталоге стоят все обновления, вплоть до сегодняшнего. При попытке обновления, конфа говорит, что, мол, нет обновлений. БП маленько измененная, насколько не знаю. Куда ткнуть и что сделать, чтобы толкнуть это .. обновление? При попытке указания файла обновлений, выскакивает табличка в релизами что можно обновить и все, действий дальше нет. При обновлении через инет, видит версию 32.4!!
Разбираться досконально нет времени вот и спрашиваю!
(1) DoctorRoza, сталкивался с таким делом))) (Бух 2.0 проф) Бухгалтер: "Устанавливаю обновления - одинэска их не видит, ничего не работает, все поломалось!!!" Показывайте, говорю, обновления. Папка updsetup, все файлы присутствуют, "одинэска" не видит. Читаю реадми из этой папки - "Бухгалтерия предприятия (базовая)".
Так что проверьте, если у вес проф версия, не для базовой ли версии вы пытаетесь установить обновления? И наоборот, соответственно)))))
(1) DoctorRoza, Еще может быть проблема в том, что криво обновили последний раз. То есть, получается, что обновляли до 37.12. Обновилась конфигурация базы данных, а конфигурация поставщика по каким-то причинам не обновилась и осталась старой. Поможет обновление ЦФником последнего релиза.
Навскидку... сделайте пустую базу, дообновляйте ее до вашего текущего релиза (до релиза базы, в которой не получается обновление). Сделайте из нее cf файл и накатите на проблемную (конечно отслеживая, что менялось). Попробуйте теперь обновиться штатно. Перед всем эти создавайте копию базы!
Был подобный случай, но только с КА. Там клиента до меня обслуживал другой программист. Так он обновлял следующим образом: делал обновления у себя на копии их базы с учетом всех доработок, каким-то образом создавал файл обновления, ехал к клиенту и обновлял их базу. Вроде всё нормально база обновлялась, релиз свежий. Вышел новый релиз, этот человек куда-то свалил. Приехал я, начал обновлять стандартным обновлением от 1С, а он обновление не видит (хотя оно есть в нужной папке). Пришлосьбрать релиз конфы которая у них стоит, накатывать дописки и заливать его в их базу. После этого обновления начали вставать стандартно, без заморочек! Как оказалось так делают многие "нехорошие" люди, чтобы клиент обслуживался только у них!
Здесь может быть такая же история.
Спасибо! Да, получилось только после наката cf-ника того же релиза, что и текущая база. А потом заново накатил сверху конфигурацию с изменениями. Теперь все обновления видятся и предеться 5-6 обновлений накатывать до актуального релиза! Жесть!
По сабжу, было в БП. Обновлялся из предприятия (по кнопке обновить конфигурацию). Вот только на одном из релизов он откатывал конфигурацию поставщика на пару релизов назад и переставал обновляться. Пришлось по старинке из конфигуратора
Вкратце почему так делать НЕЛЬЗЯ: 1с-ники при выпуске новых релизов иногда создают новые объекты, который по своему смыслу заменяют другие похожие объекты. Старые объекты при этом удаляют.
Но процедура удаления СТАРЫХ ОБЪЕКТОВ состоит из нескольких шагов:
1. При выпуске одного релиза старому объекту (который подлежит удалению) добавляют ПРЕФИКС "Удалить" (например, УдалитьОценочныеОбязательства, УдалитьКорректировочныйСчетФактураВыданный, УдалитьКорректировочныйСчетФактураПолученный, и т.д. - обрати внимание в дереве конфигурации)
2. В обработку, которая выполняется при обновлении ОБНОВЛЯЕМОГО релиза добавляют код, который переносит пользовательские данные в новые объекты, которые были созданы взамен удаляемому.
3. При выпуске очередного релиза, объекты с префиксом "Удалить" уже удаляют.
PS: если обновление делать cf-ником, перепрыгивая через промежуточные релизы, то можно потерять данные тех объектов, которые были удалены, а точнее заменены на другие, из-за того, что шаг 2 будет пропущен.
В "восьмёрке" 1с-ники и сделали "защиту от дурака", чтобы система не давала обновить конфигурацию (а точнее испортить её) путём ограничений на перепрыгивание через релизы. Кстати в описании обновления, написано с каких релизов можно обновится до текущего.
Некоторые же особо "вумные", особенно "семёрашники" не читают соотв. литературу пытаются доказать свою истину. Один из экземпляров подобного типа людей отписался выше :)))
(15) ZeroDM, cwerj некоторые t,fyyst jktyb , которые отучились по ходу на каком-то курсе считаю себя j[ebntkmysvb СПЕЦами в 1С. Может тебе буху дать обновить с 4-мя субконто или хотя бы ЗУП?
(15) ZeroDM, признаюсь, читала с глазами полными слез... возможно, открою Вам секрет. Разработчики , которым не чужды страдания простых бухов и иже с ними (в отличие от ее святейшества 1С), которые слышат глас простых пользователей да еще и нагибаются к ним, чтоб расслышать получше, НО имеющие логотип 1С-совместимо, выкладывают обновления сразу в двух вариантах 1Cv8.cf и 1Сv8.cfu. Чтобы не быть голословной, предлагаю Вам пройтись по ссылкам, так... ради интереса. А потом, если будет желание скажите этим разработчикам (ВДГБ, Камин,Рарус и др.), что они дураки, и совсем не знают матчасти...
3. При выпуске очередного релиза, объекты с префиксом "Удалить" уже удаляют.
Как думаешь зачем 1С выпустила ту же версию 1.5, затем 1.6? Я отвечу тебе, как раз из-за "Удалить". Т.е. 1С не удаляет свои хвосты не в следующем релизе, не через релиз (мы же про БП говорим?) И чтобы избавиться от таких хвостов и принимается стратегическое решение. Т.е. да при обновлении с 1.5 на последний релиз 1.6 может быть такое. Но при обновлении с последнего релиза 1.5 на последний релиз 1.6 1С заботлива избавила нас от этой проблемы. Так что твои теоретические знание не подтверждает практика. Т.е. применительно к 1С БП таких проблем за свою долгую работу я в БП не встречал
PS: если обновление делать cf-ником, перепрыгивая через промежуточные релизы, то можно потерять данные тех объектов, которые были удалены, а точнее заменены на другие, из-за того, что шаг 2 будет пропущен.
В "восьмёрке" 1с-ники и сделали "защиту от дурака", чтобы система не давала обновить конфигурацию (а точнее испортить её) путём ограничений на перепрыгивание через релизы. Кстати в описании обновления, написано с каких релизов можно обновится до текущего.
Это вообще шедевр. Т.е. на лицо человек явно путает понятия, т.е. порядок обновления через CFU и через CF.
Т.е. все это применительно ТОЛЬКО к обновлению с помощью CFU файла. Для CF файла внутри одной редакции нет разницы обновлять с 2.0.10 до 2.0.42 последовательно, или сразу обновить с помощью CF файла до 2.0.42. 1С позаботилась в этом случае и процедура обновления содержит все промежуточные обновления и корректно обновит с любых релизов в пределах одной редакции.
Повторяю речь идет о БП, возможно в УПП или в УТ и по другому, но мы сейчас обсуждаем конкретно БП. И для этого конкретного случая твоя теория, или как ты назвал ее матчасть, не работает.
P.S. Вот только не надо тут выяснять чьё кунфу круче и придумывать, что а вдруг в следующем релизе они поступятся своими принципами ... Вот когда будет прецедент, тогда и поговорим. А пока что за 6 лет это "вдруг" еще не разу небыло
(16) Aleksey_3, слушай Алёша! Ты видимо не понял сути о которой я говорил...
1С позаботилась в этом случае и процедура обновления содержит все промежуточные обновления и корректно обновит с любых релизов в пределах одной редакции.
Я не говорю о том, что структура метаданных будет обновлена неправильно. Я говорю о пользовательских данных, которые МОГУТ быть потеряны, если прыгнуть через несколько релизов. И речь тут не идёт, от БП, УТ, УПП или ещё о чём-то конкретном... речь идёт о любой конфигурации написанной по специальной методики фирмы 1с.
Сейчас привожу конкретный пример...
1. Представим, что работаем мы на релизе 2.0.38. (не важно какой конфигурации)
Допустим в конфигурации есть регистр сведений, а у него реквизит ФизическоеЛицо. И данные реквизита заполнены пользователем данными.
Структура регистра для релиза 2.0.38 (вымышленный релиз)...
РС:
- ФизическоеЛицо.
2. Затем разработчик решил, что у регистра должен быть реквизит не физ.лицо, а Сотрудник (другой тип данных).
Если мы просто его переименовать и назначить тип "СправочникСсылка.Сотрудники" то все пользовательские данные после обновления будут потеряны. Поэтому в типовых конфигурациях, делают так: в этом регистре при разработке следующего релиза добавляется второй реквизит "Сотрудник", а реквизит "ФизическоеЛицо" переименовывают в "УдалитьФизическоеЛицо".
Структура регистра для релиза 2.0.39...
РС:
- УдалитьФизическоеЛицо
- Сотрудник
После обновления структуры метаданных на релиз 2.0.39, система запускается в пользовательском режиме и с помощью специально обработки обновления, данные из реквизита "УдалитьФизическоеЛицо" используются, чтобы определённым образом заполнить реквизит "Сотрудник"
3. Затем уже в след. релизе 2.0.40 (а может и поже, как захочет) реквизит "УдалитьФизическоеЛицо" удаляется из структуры регистра.
Структура регистра для релиза 2.0.40...
РС:
- Сотрудник
--------------------------------------------
Как видно из примера, если обновление делать 2.0.38->2.0.39->2.0.40, то данные о "физлицах", корректно преобразуются в "сотрудников".
Если прыгнуть 2.0.38->2.0.40, то реквизит "Сотрудник" будет пуст.
Ну а структура метаданных конфигурации, как ты правильно понял перенесётся корректно.
(17) ZeroDM, В теории все так, а на практике реквизит "УдалитьФизическоеЛицо" не удалится. Он останется, данные из него успешно перенесутся в реквизит "Сотрудник" как вы описали в п. 2. Самое плохое что может произойти - это "подвисание" неудаленных реквизитов.
(18) pahich, я написал упрощённый пример. На практике реквизит удаляется, но не сразу. Т.е. к примеру не на 2.0.40, а где-нибудь на 2.0.45, или 2.0.50. Разработчики могут ждать и до полугода.
(19) Еще раз за 6 лет я так ниразу недождался когда 1С "Удалит" эти реквизиты. Более того эти реквизиты были удалены только в новой редакции. Т.е. в редакции 1.6 были удалены реквизиты которые помечены были в 1.5. Но все "удаленные" реквизиты в 1.6 так и остались висеть до конца жизни. И все реквизиты помеченные 1С как Удалить в какой нибудь 2.0.3 останутся и в 2.0.20 и в 2.0.40.
Поэтому я и просил ненадо в теорию впадать. Потому что теория это одно, а практика работы с 1с БП показывает что никто их не собирается удалять
Поэтому я и просил ненадо в теорию впадать. Потому что теория это одно, а практика работы с 1с БП показывает что никто их не собирается удалять
Практика, основана на теории. Метод тыка, которым ты пользуешься для изучения теории, уже ушёл в старое бытие в 20 веке. Современное обучение основано на "курсах+практики", а не на "методе тыка + практике".
В 1с нигде не регламентировано, что она их не собирается удалять. И гарантии никакой нету, что в одном из следующих релизов они не будут удалены из конфигурации. Есть определённый порядок обновления, который они рекомендуют использовать, а следовательно лучше его и использовать.
Если так рассуждать, то бэкапы я полагаю ты тоже не делаешь, т.к. винчестеры сгорают не каждый день, а может быть за твоё небольшое время работы и не было случая когда база упала, поэтому подождём когда будет :))
(25) ZeroDM, объясни пожалуйста чтотбудет, если в файле cf будет отсутствовать какой то реквизит, который есть в конфе базы данных (ну то-есть он был удален)? Что пойдет не так в обновлении?
(25) Где рекомендации по обновлению через CF обновления?
Еще раз ты путаешь теплое с мягким. Рекомендации даются ТОЛЬКО для CFU файла. Исходя из этого по твоему в принципе нельзя обновлять через CF файл, только CFU?
Вопрос тут даже не в теории. Как раз исходя из того что я вижу (наличие модуля обновления с любого релиза в CF файле) в теории как раз всё должно быть хорошо, что и подтверждается практикой
О какой теории ты всё время говоришь? О теории обновления через CFU файл? Ну так там принцип такой, что ты физически не можешь выйти за рамки рекомендумого релиза, ибо CFU содержит только список того что изменилось между релизами не более.
(28) Aleksey_3, твоя позиция понятна, и моя тоже. Те кто (если)будут перечитывать всё это, сделают для себя вывод как быть учитывая все "ЗА" и "Против" каждого из подходов.
Посему не вижу смысла продолжать бесполезный спор, ибо придерживаюсь мудростей, очень применимых в данном случае:
Никогда не спорь с идиотом — он опустит тебя до своего уровня, а потом выиграет, т.к. имеет опыт.
Издавна известно, что умные в споре пытаются выяснить, в чем истина, а дураки - кто из них умнее!
(29) ZeroDM, А как по вашему обновлять конфигурации с кучей дописок. Они обычно крайне редко обновляются пока не приспичит совсем. И обновлять ее прямо на работающей базе вам врядли кто-то даст, ведь людям надо работать, а обновление может занять не один день. Скачиваете базу, накатываете на нее 5-10 обновлений дома или в офисе, потом снимаете cf-ник и быстренько обновляете с него клиенту. А как по-другому???
Не обновляйте конфигурацию через "сравнить, объединить с конфигурацией из файла", в этом случае не обновляется конфигурация поставщика. Лечится обычным обновлением, начиная со следующего релиза по отношению к конфигурации поставщика, но при обновлении снимаются все галочки, в этом случае конфигурация поставщика обновится, а основная конфигурация не будет затрагиваться.
(20) Ненадо быть так категоричным.
Назови мне хоть один релиз в котором были удалены эти реквизиты, т.е. назови мне хоть один релиз который нельзя перепрыгивать. Можешь начинать с версии 1.0
Можешь с 2.0 благо уже 2.0.42.
Ради прикола можешь открыть обработку обновления ИБ в Бухии
Первая версия БП 2.0 была 2.0.12.2
А вот часть кода из обработки
НачальныйРелизИБ = ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ);
ТекущаяВерсияИБ = Константы.НомерВерсииКонфигурации.Получить();
НоваяВерсияИБ = "2.0.12.2";
Если ((ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.12"
Или ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.11")
И ТекущаяВерсияИБ <> НоваяВерсияИБ И ТекущаяВерсияИБ <> "") Тогда
//тут код обработки я его удалил, ибо он не нужен
КонецЕсли;
ТекущаяВерсияИБ = Константы.НомерВерсииКонфигурации.Получить();
НоваяВерсияИБ = "2.0.13.5";
Если ((ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.13"
Или ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.12")
....
Показать
И так далее до последнего релиза, т.е. до последнего релиза
ТекущаяВерсияИБ = Константы.НомерВерсииКонфигурации.Получить();
НоваяВерсияИБ = Метаданные.Версия;
Если ((ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.42"
ИЛИ ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.41")
И ТекущаяВерсияИБ <> НоваяВерсияИБ И ТекущаяВерсияИБ <> "") Тогда
....
Показать
Так что позволь с твоим категорическим высказыванием что перепрыгивать нельзя не согласится
Я так и думал, что твоя теория - это "Одна Бабка Сказала". Т.е. рекомендаций и/или запрет на обновления именно CF файлов от 1С мы так и не услышим
А по поводу спора, ну так я сразу просил не начинать разборки, тебе захотелось права покачать, потом с умным видом выходишь из спора. Имеешь право. И тебе удачи в обновлениях
Вот потому и получается два варианта работы. Либо клиент работает на типовой конфигурации и обновление без проблем, либо вы имеете с клиента дополнительный доход, изменяя типовую конфигурацию плюс лишнюю головную боль при обновлении))))