Доброе время суток.
В связи с появлением обновлений бухгалтерии, возник вопрос о целесообразности обновления на 8.2.19.80 или 8.2.19.83. (Сейчас стоит 8.2.16.368).
В виду того, что помимо бухгалтерии используются другие, причем кардинально переработанные конфигурации, возникают логичные опасение о том - "а заработает ли оно?" :)
Попробовали проигнорировать предупреждение о том, что нужен новый релиз и получили разрушенную конфигурацию на тестовой базе.
Есть вариант использования обновленной бухгалтерии, например на 8.2.18.109 или все-таки придется поднимать релиз платформы ?

P.S.
О том, какие проблемы несет в себе новый релиз - читал.

Безопасно дома под одеялом только...

Смысла держать старые платформы вобще нет, так что вперёд, бэкапы - сила

В то время как 1С готовит к выпуску 8.3.5 вы рассуждаете а стоит ли переходить с одной устаревшей платформы на другую?

(2) +1

все уже на 8.3 =)

(0) перешли неделю назад, работает пока

>В то время как 1С готовит к выпуску 8.3.5

пусть сначала косяки в 8.3.4 исправят, по полгода не чешутся

(5) в 8.3.5 и исправят

(0) Работать, работает. Но с кэшем реальные проблемы. Иногда показывает что конфигурация поставщика не обновлена. Чистим кэш, и конфигурация поставщика обновлена.

Восьмерка еще сырая

(0) Переходи нормально все.

(1),(2) Устаревшая...да я бы с удовольствием остался на 8.1. Вот это была платформа - никаких нареканий + динамическое обновление работало нормально. :) Весь геморой начался с 8.2.

А то что 8.2.16.368 старье...ну да, зато сейчас на нем все крутится. Да и бэкапы 200 гиговых баз восстанавливать после сбоев - вообще не вариант.

(9) Да ладно, прямо все ? )

(10) ну смысл сидеть на 8.2.19.80? Она же глючная. В 8.2.19.83 хоть что-то поправили.

(10)
Про 8.2.19.83 не могу ничего сказать, но на 8.2.19.80 сейчас крутится база у одного клиента. Несколько месяцев, нареканий нет.
Сейчас сам хочу перевести их на 8.2.19.83, т.к. требуется обновить их доработанную УТ до последнего релиза. И придется, видимо, рискнуть. Переведу, а там посмотрим.
Бакапы сделаем естественно.

На домашнеи компе, кстати, заметил замедленную загрузку базы на 8.2.19.83 по сравнению с 8.2.19.80.  Но не уверен на 100%, может просто показалось.

(8) Это вопрос, утверждение, как это понимать?

(13) Утверждение. Нормальные люди сидят на 7.7 и не перезодят на глючную 8.

*переходят

(12) тоже показалось, что на 8.2.19.8х сравнение баз в конфигураторе медленнее стало выполняться и что работа с бух.регистрами замедлилась.

ТиИ

(0) Переходи. 8.2.16 это прошлый век. Я её вообще не заметил, как-то внезапно на 8.2.18 сел.

(14) Интересная позиция:)Так может быть еще и каменными топорами рубить будем.

Попробуем перейти в тестовом режиме, подняв отдельный сервер...там посмотрим :)

(10) Прям все. За два месяца никаких нареканий. Толстый, тонкий через web сервер, тонкий напрямую.

а, 8.2.16, а я прочитал 8.2.19.80 на 83. Извиняюсь, не заметил. Подумал, из-за чего сыр-бор?

Добрый день. Возникла необходимость перейти на 8.2.19.83.
В итоге перешли месяц назад. Пока полет нормальный.

(14) Да ладно, у нас клиент на 6.0 работает. Как они отчетность делают, лучше не спрашивайте.
(20)В 8.3 же есть режимы совместимости, так что (теоретически) можно попробовать их.

в 8.2.19.83 из важного исправили
20021606  Запрос, использующий временную таблицу
Проблема:
При выполнении запроса, использующего временную таблицу, заполняемую из таблицы значений, происходит ошибка
Невосстановимая ошибка Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm: по причине: Ошибка SDBL: Соединение с базой данных не удерживается. Отпустить контекст соединения невозможно.
и аварийное завершение работы программы.
Дата публикации:
2013-12-18
в 8.2.19.80 она наверное есть