Добрый день. Помогите пожалуйста разобраться в проблеме. Поставили новую КА 2.0, до этого стояла КА 1.1. Требуется изменить конфигурацию под наши нужды. Делаю в копии изменения, сохраняю в CF. Потом стандартная процедура "Сравнить/ объединить" и вот на этом этапе база виснет с надписью в строке состояния "сравнение объектов 0 %", ждали сутки, результат тот же. Так же заметил что у новой базы КА 2.0 неприлично большой размер файла конфигурации (1.45 гб), возможно это теперь норма, но у КА 1.1 размер конфы был в разы меньше. Решил просто сравнить конфигурацию с конфигурацией поставщика: эффект тот же (зависание на 0%). Подскажите куда копать. База на SQL, ресурсов сервера хватает.

(0)[База на SQL, ресурсов сервера хватает.]
ни каких особеностей в ERP 2.X при сравнении нет, либо нет прав, либо кривая настройка

Только что столкнулись с аналогичной проблемой.
Причем КА 2.0 ставилась изначально 3 месяца назад и за прошедший месяц пару раз успешно обновляли конфигурацию.

А вот с версией 2.4.11.63 такая засада. И непонятно, что делать.

Проверьте место на диске С:.

400Гб свободно.

В общем, через полдня веселых экспериментов выяснилось, что обновление 2.4.10.94 -> 2.4.11.63 успешно проходит, а вариант 2.4.11.55 -> 2.4.11.63 стабильно приводит к зависанию на Сохранении объектов с 0% прогресса.

А платформа 8.1?

Нет, конечно.

8.3.15.1565

1. поставьте 64 бит на клиенте, где стартуете обновление. На сервере наверное 64 и так уже стоит.

2. Можете сделать все обновление и доработки локально, а не на сервере и загрузить конфигурацию в базу из файла. Но на локальном способе однозначно без 64 бит клиента ничего не получится.

з.ы. Забывайте уже о том, что с базами можно что-то конфигурить на клиентах в 32-бит. Их не выкидывают по идеологическим причинам, но на практике 32 бит часто не применимо.

64-бит стоит везде.

И вы упускаете тот факт, что обновление 2.4.10.94 -> 2.4.11.63 успешно проходит, а вот вариант 2.4.11.55 -> 2.4.11.63 дает ошибку.

(9) сколько памяти на клиенте?

(9) Я думаю, что этот факт, что с 2.4.10.94 проходит - это означает, что 2.4.11.55 разко доросла в размерах по сравнению с 2.4.10.94

И если не добавлять оперативы, то и все последующие обновления будут происходить с такой же попаболью.

з.ы. Не правильно, дядя Федеор, бутерброд ешь - колбасой вниз держать нужно.

Вы сами обновление именно 2.4.11.55 -> 2.4.11.63 проводили или просто теоретизируете?

(12) я фигней не страдаю.
Есть полный дистриб? Ставлю с него готовую ЦФ. Затем вношу необходимые модификации с результат заливаю на рабочую базу через "загрузить из файла"

(13) страдаешь, последствия могут сказаться через пару релизов

(14) отчего последствия возникнут?

Все-таки интересно услышать о том, сколько памяти у них там на клиенте.

У меня на повседневном компе всего 8 оперативы. И приходится убирать перед запуском конфигуратора для работы с КА 2 с этого компа все сеансы браузеров и прочих даже скайпов, чтоб не влетать на неадекватные реакции платформы на нехватку памяти.

(15) от убитой конфигурации поставщика и  NULL в данных

(17) но ведь твоя команда не занимается разработкой непосредственно на продуктиве - как наличие или отсутствие конфигурации поставщика в продуктиве может вам мешать?

Все изменения проходят через хранилище, оттуда берется готовый окончательный образ вообще всей конфигурации (и даже расширений если они есть) и заливается в продуктив. Конфа поставщика в этом случае лежит там баластом. Ну заменится на получаемый из хранилища, ее использование в этом процессе блокировано.
Получить из хранилища - это не объединение, а замещение всех метаданных.

Та же самая херня с ERP. На 2.4.10.89 Поставил 2.4.11.56. При обновлении с 2.4.11.56 на 2.4.11.65 зависает на сравнении объектов. Поставил на 2.4.10.89 2.4.11.43, при обновлении с 2.4.11.43 на 2.4.11.65 так же виснет, и при обновлении с 2.4.11.43 на 2.4.11.63 тоже виснет. Платформа 64, оперативки 256 гигов, 4 ссд по 500. И даже в файловом варианте базы тоже самое.

Мы тоже столкнулись с проблемой при обновлении ERP с 2.4.11.63 до версии 2.4.11.67. В данный момент платформа 8.3.15.1489. Пробую на тестовом сделать апдейт до 8.3.15.1830 - отпишу по результату.

(19) (20) только почему-то не указываете с чем сравниваете, т.е. с чего обновляетесь : с полных CF или CFU ?
И еще не указываете разрешены изменения с сохранением поддержки или нет.
256 гигов - это оператива сервера, правильно? Или все-таки оператива клиента, т.е. конфигуратор стартуете непосредственно на сервере, где и установлено 256 гиг?

Обновляемся CFU. Изменения с сохранением поддержки. Конфигуратор запускается на локальной машине.

(22) нам раньше в похожей ситуации помогало обновляться не с CFU, а с CF - и поскольку вероятность наступить на эти грабли имеется, то на практике почти никогда с CFU не обновляемся уже много лет.

хотя понятно, что взять CF это тоже не гарантия, что проблем точно не будет.
Просто готовый CF позволяет не строить сравнение внутри конфигурации Поставщика с образом, который выстраивается из добавления CFU к конфигурации поставщика (на это же куча памяти будет нужно)

Обновили платформу на сервере до версии 8.3.15.1830 без выгрузки баз. Обновление конфигурации ERP до версии 2.4.11.67 прошло успешно.

Техподдержка 1С рекомендовала обновить платформу.
Выкроили на это время и вуаля - на платформе 8.3.16.1148 проблема исчезла.

(21) Сравнивал и с CF и c CFU результат одинаков) Запускал и на серваке и на клиенте, на обоих оперативки до дуры. Проблема была в организации потоков походу внутри платформы, новая версия решила проблему. Могли бы сами протестить, а то пишут не ниже 8.3.12...))

(27) Можно было просто полный дистр загрузить и сравнить с выгруженой своей конфой, так прокатило))