По теме из базы знаний
- Новый сервис обновлений от 1С. Описание
- Многопоточное обновление 1С: Управление холдингом
- Обновление 1С лицензий с уровня ПРОФ до КОРП
- История одного проекта обновления 1С: переход с БСП 2 на БСП 3 в самописной конфигурации
- Вход пользователей при неудачном обновлении 1С: способ снятия блокировки при отсутствии административных прав
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Саму конфигурацию ты так обновить можешь, но именно конфигурацию. При обновлениях часто запускаются специальные обработки, которые меняют данные в базе под новую конфигурацию. Если бы все было так просто, то фирма 1с не описывала в методологии обновления последовательность этого самого обновления. Если изменения в базе не будут вноситься, то да, так можно обновить и все будет работать, но чтобы понять вносились ли в базу изменения тебе нужно потратить времени больше чем на сами обновления стандартными средствами, поэтому и не стоит этим заниматься, - овчинка выделки не стоит.
(2) Bienko,
Всем "противникам" обновления через несколько релизов советую посмотреть на файл конфигурации с франчайзингового диска - там создается точно такой же файл конфигурации cf, как и при выгрузке из конфигуратора...
Вообще понятие "кумулятивное обновление" никто не отменил пока...
Саму конфигурацию ты так обновить можешь, но именно конфигурацию.
- кто сказал? Если делать именнно обновление, а не загрузку или сравнение / объединение, то всё процедуры отработают обновится всё что нужно. Проблемы возможны только в случае, когда между текущей конфигурацией и конфигурацией в обновлении были "ключевые" релизы, в которых изменялись реквизиты объект, с последующим их удалением из конфигурации. Обвновляю созданным таким образом созданным файлом cf уже много лет - не налетел на неприятности ещё ни разу (речь про БП, там уже давно при изменении реквизитов их полностью не удаляют, а оставляют с префиксом Удалить, связано наверное с тем, что переход с 2.0 на 3.0 сделали простым обновлением).
Всем "противникам" обновления через несколько релизов советую посмотреть на файл конфигурации с франчайзингового диска - там создается точно такой же файл конфигурации cf, как и при выгрузке из конфигуратора...
Вообще понятие "кумулятивное обновление" никто не отменил пока...
(7) Alex_E, клиенты у меня на УПП тоже так обновились, а потом косяки вылезли (косяки они увидели только через неделю). Пришлось потом обработками исправлять. Так что... Береженого бог, как говориться, бережет... На счет файла конфигурации cf на франчазе диске вы уверены что он именно для обновления там? Он, скорее всего, используется для возврата конфигурации на поддержку, сравнений и т.д. В руководстве разработчика для платформы 8.3 есть раздел 30.2.3. Обновление конфигурации. Там он описан самой фирмой 1с. Так вот там нет понятия "кумулятивное обновление". Я не спорю, что зачастую такое обновление может пройти успешно, но бывает и иначе (я, по крайней мере, с этим сталкивался). Поэтому я и рекомендую людям обновляться "правильно", так как это предусмотрено самим разработчиком.
(8) Bienko, Я сказал про БП без проблем, на УПП подход разрабов другой - там реально есть ключевые релизы, после которых безвозвратно удаляются реквизиты
хотя вопрос в одном, если накатывать все обновления быстрее по времени, чем исправить выявленные косяки теми же обработками после кумулятивного обновления, то можно обновлять и так, время - деньги.
Ставится на поддержку cf-ником из конфигуратора точно так же как и из сетапа с франчевого диска - проверено не раз.
Про кумулятивное обноление - если установить в шаблоны сетап с диска (поставки или франя) то при поиске обновлений стандартно (без установить из файла) они там прекрасно видны (ну если галка стоит, Показывать конфигурации) и на них так же обновляется.
Все страшилки про невозможность, это именно старшилки - всё уже описано, перерасписано - все проблемы кумулятивно обновления связаны с переносом данных из одних объектов (реквизитов) в другие.
Позавчера у меня случилось страшное - диск из коробки базовой управления жкх не прочитался, а cf - ника не было. Полдня на установку из сетапа с сайта и обновления до последнего релиза. Потом поробвало - создал cf, установил из сетапа пустую базу, обновил на до последнего одномоментно - получил две совершенно идентичные базы, так что отметать эту возможность можно только для баз, где учет таки велся и какие то данные были в удаленных разработчиками реквизитах, и иногда даже в этом случае обновление не повлечёт никаких последствий, по крайней мере фатальных последствий не будет точно, если не быть полным идиотом, и делать архивные копии.
хотя вопрос в одном, если накатывать все обновления быстрее по времени, чем исправить выявленные косяки теми же обработками после кумулятивного обновления, то можно обновлять и так, время - деньги.
Ставится на поддержку cf-ником из конфигуратора точно так же как и из сетапа с франчевого диска - проверено не раз.
Про кумулятивное обноление - если установить в шаблоны сетап с диска (поставки или франя) то при поиске обновлений стандартно (без установить из файла) они там прекрасно видны (ну если галка стоит, Показывать конфигурации) и на них так же обновляется.
Все страшилки про невозможность, это именно старшилки - всё уже описано, перерасписано - все проблемы кумулятивно обновления связаны с переносом данных из одних объектов (реквизитов) в другие.
Позавчера у меня случилось страшное - диск из коробки базовой управления жкх не прочитался, а cf - ника не было. Полдня на установку из сетапа с сайта и обновления до последнего релиза. Потом поробвало - создал cf, установил из сетапа пустую базу, обновил на до последнего одномоментно - получил две совершенно идентичные базы, так что отметать эту возможность можно только для баз, где учет таки велся и какие то данные были в удаленных разработчиками реквизитах, и иногда даже в этом случае обновление не повлечёт никаких последствий, по крайней мере фатальных последствий не будет точно
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот