Такая история...После обновления базы пошли всякие баги и отличия которых не должно по сути быть.
База была обновлена через конфигуратор с Управление торговлей, редакция 11 (11.5.12.251) до УТ 11 (11.5.19.63).
Как я замечал, но не придавал значения. В релизам есть разница докупустим 11.5.19 и 11.5.17, хотя они буквально в один день могут выйти. Скорее всего не то обновление накатил.
После экспериментов. А именно обновляя базу с 11.5.12.251 до ут проф 11.5.16.97. Багов не возникает.
При попытке сменить конфигурацию с 11.5.19.63 на 11.5.16.97. Баги не уходят.
Нужен оптимальное решение. В базе работает много людей, и решение с копией базы и загрузки правильного обновления для нас не очень подходит. Нужно исправить как то действующую базу. Конечно копия базы за 09.10.24 есть, но людям придется доки перезаполнять за неделю.
База была обновлена через конфигуратор с Управление торговлей, редакция 11 (11.5.12.251) до УТ 11 (11.5.19.63).
Как я замечал, но не придавал значения. В релизам есть разница докупустим 11.5.19 и 11.5.17, хотя они буквально в один день могут выйти. Скорее всего не то обновление накатил.
После экспериментов. А именно обновляя базу с 11.5.12.251 до ут проф 11.5.16.97. Багов не возникает.
При попытке сменить конфигурацию с 11.5.19.63 на 11.5.16.97. Баги не уходят.
Нужен оптимальное решение. В базе работает много людей, и решение с копией базы и загрузки правильного обновления для нас не очень подходит. Нужно исправить как то действующую базу. Конечно копия базы за 09.10.24 есть, но людям придется доки перезаполнять за неделю.
Прикрепленные файлы:
По теме из базы знаний
- Методика и инструменты полуавтоматического обновления конфигураций 7.7 до типовой версии с сохранением модификаций
- Баг или фича? Неожиданное поведение платформы
- История одного проекта обновления
- Некоторые моменты обновления типовых конфигураций (доработанных типовых конфигураций)
- Анализируем SQL сервер глазами 1С-ника
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) Ну хз. Обновление накатил через конфигуратор, выбрал файл обновления. Видимо не тот релиз выбрал для обновления этой конфы. Потому баги пошли. Тестил на копии базы которую я заранее делал, что если бы правильный резил накатил, то багов не было. Но теперь когда я пытаюсь неправильный на правильный поменять релиз конфы, то баги остаются
(4)
Ты. НЕ. Делал. Обновления.
Ты. Насильно. Заменил. Одну. Конфу. На. Другую.
Это не называется обновлением. При обновлении платформа не даст тебе воспользоваться неподходящим релизом.
(4)
Видимо не тот релиз выбрал для обновления этой конфы.
Еще раз. По буквам.
Ты. НЕ. Делал. Обновления.
Ты. Насильно. Заменил. Одну. Конфу. На. Другую.
Это не называется обновлением. При обновлении платформа не даст тебе воспользоваться неподходящим релизом.
(4)
Но теперь когда я пытаюсь неправильный на правильный поменять релиз конфы, то баги остаются
Правильно, потому что данные в обновляемых таблицах ты уже затер. Сами они ниоткуда не появятся теперь.
(1) То есть тебя не насторожило, что ты взял обнову натянул на боевую, без прогона на тестовой и теперь ты хочешь прогнать еще раз на боевой, что бы как вариант тупо ее положить, но прогон на тестовой не подходит. Оригинально. По сути, откатывай на старый релиз, бери копию и прогоняй на тестовой, а потом выяснив последовательность уже обновляй боевую
Пару лет тому назад словил глюк - долго обновлял копию (через Конфигуратор - Конфигурация-Поддержка-Обновить конфигурацию), дней несколько ушло на всё про всё. В рабочей решил просто загрузить через Сравнить/объединить.... Ну и конфигурация поставщика как и ожидалось (нет) не обновилась. Вроде пользователи работают, а все равно что-то не так ((( Пришлось накатывать обновление со снятыми галками, вроде все получилось, но больше я так не делал.
(7) У меня очень похожая ситуция. Имеется несколько баз с одинаковой конфигурацией. Для экономии времени обновления я обновил одну базу штатно, через Конфигуратор - Конфигурация-Поддержка-Обновить конфигурацию. А остальные базы загрузил на ее основе через Сравнить/объединить. В результате версия конфигурации в них обновилась, но при последующих обновлениях конфигуратор не видит доступных обновлений. Если задать файл обновления вручную, то он также не распознает его как следующее обновление. Пришлось при очередном обновлении еще раз первую конфигурацию обновить штатно и последовательно, а стальные обновить через Сравнить/объединить с обновленной первой конфигурацией.
(7)
Имеется ввиду - повторно выполнить старые обновления? В сравнении конфигураций при этом убрать все галочки?
(7)
Пришлось накатывать обновление со снятыми галками, вроде все получилось, но больше я так не делал.
Имеется ввиду - повторно выполнить старые обновления? В сравнении конфигураций при этом убрать все галочки?
(10)
Для экономии времени обновления
Получилось в итоге сэкономить?
А остальные базы загрузил на ее основе через Сравнить/объединить.
Пришлось при очередном обновлении еще раз первую конфигурацию обновить штатно и последовательно, а стальные обновить через Сравнить/объединить с обновленной первой конфигурацией.
... но продолжали жрать кактус.
(12) Берете cf типовой конфигурацию нужного релиза. Через поддержка - обновить указываете этот файл. В режиме объединения снимаете ВСЕ галки и обновляете. Таким образом у вас обновится конфигурация поставщика и дальнейшие обновления можно будет делать в штатном режиме.
П.С. к сожалению поздно увидел, что вам уже ответили, а удалить пост нельзя
П.С. к сожалению поздно увидел, что вам уже ответили, а удалить пост нельзя
1С не просто так пишет список релизов, с которых можно перейти (на вашем скрине во второй колонке).
Для 11.5.19.63 не заявлена возможность обновления с 11.5.12.251.
Обновляться натягиванием CF с перепрыгиваением через релизы - это всегда риск.
Рисковать сразу на рабочей базе без предварительного тестирования на копии - ну такое...
Для 11.5.19.63 не заявлена возможность обновления с 11.5.12.251.
Обновляться натягиванием CF с перепрыгиваением через релизы - это всегда риск.
Рисковать сразу на рабочей базе без предварительного тестирования на копии - ну такое...
(8) с версии 11.4.*. * –> 11.4.12.* (рекомендуемая сборка 11.4.12.109)
11.4.12.109 –> 11.4.14.* (рекомендуемая сборка 11.4.14.181)
11.4.14.181 –> 11.5.8.* (рекомендуемая сборка 11.5.8.443)
11.5.8.443 –> 11.5.12.* (рекомендуемая крайняя сборка 11.5.12.270)
11.5.12.270 –> 11.5.17.* (рекомендуемая крайняя сборка 11.5.17.*)
Вот список безопасных прыжковв варп
тоесть с 12 нужно было допрыгать до 17 и дальше уже можно и до 19
11.4.12.109 –> 11.4.14.* (рекомендуемая сборка 11.4.14.181)
11.4.14.181 –> 11.5.8.* (рекомендуемая сборка 11.5.8.443)
11.5.8.443 –> 11.5.12.* (рекомендуемая крайняя сборка 11.5.12.270)
11.5.12.270 –> 11.5.17.* (рекомендуемая крайняя сборка 11.5.17.*)
Вот список безопасных прыжков
тоесть с 12 нужно было допрыгать до 17 и дальше уже можно и до 19
(1) почему не рекомендуется переходить с версии ххх на версию ууу сразу в один "присест"?
Потому что при обновлении конфигурации достаточно часто меняется структура конфигурации и данные из регистра "СтарыйРегистр" - не попадают в "Новый регистр" /или там документ/справочник/реквизиты/табличные части.
Соответсвенно раз часть данных утерена - то возможна не корректная работа по данным вопросам.
Если же идти путем накатов по CFU - то там есть процедуры обработки - которые корректно обрабатывают переход из одного релиза в другой и переносят данные. в целом эти обработки занимают длительное вермя.
Но без них - получим кривые данные и баги.
Соответсвенно прямой переход возможен, если человек который делает накат - хорошо понимает какие данные он может потерять и что в этом случае делать.
PS. соответсвенно по этой же причине не рекомендуется делать даунгрейд.
PPS. а если вам хочется поэксперементировать - то тестовые базы и бекапы вам в помощь.
PPPS. опять же не всегда меняется так сильно структура конфигурации... и не редко такие накаты проходят безболезненно. что порождает в свою очередь мнимую уверенность, что так дделать можно.
Потому что при обновлении конфигурации достаточно часто меняется структура конфигурации и данные из регистра "СтарыйРегистр" - не попадают в "Новый регистр" /или там документ/справочник/реквизиты/табличные части.
Соответсвенно раз часть данных утерена - то возможна не корректная работа по данным вопросам.
Если же идти путем накатов по CFU - то там есть процедуры обработки - которые корректно обрабатывают переход из одного релиза в другой и переносят данные. в целом эти обработки занимают длительное вермя.
Но без них - получим кривые данные и баги.
Соответсвенно прямой переход возможен, если человек который делает накат - хорошо понимает какие данные он может потерять и что в этом случае делать.
PS. соответсвенно по этой же причине не рекомендуется делать даунгрейд.
PPS. а если вам хочется поэксперементировать - то тестовые базы и бекапы вам в помощь.
PPPS. опять же не всегда меняется так сильно структура конфигурации... и не редко такие накаты проходят безболезненно. что порождает в свою очередь мнимую уверенность, что так дделать можно.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот