Помогите разобраться со следующей проблемой. Обновляю типовую конфигурацию ЗУП
с 3.1.28.84 на 3.1.29.38
После обновления в конфигураторе захожу в толстом клиенте в предприятие, запускается обновление. доходит до 71 % и все. спустя 10 часов вылетает с сообщением "недостаточно свободного места".
Может быть, максимальный размер лога/бд на сервере указан и в него уперлись? Чаще всего по логу бывает.
Ну и посмотреть, а что в журнале регистрации 1С пишет подробнее по этому поводу.
Коллеги, а как мне определить какие именно процедуры запускаются при обновлении? Как мне запустить их в "ручную", чтобы определить какая именно процедура не срабатывает? Чтобы уже дальше локализовать проблему.
(5) Не нужно вам это.
Лучше поделитесь информацией, что запускаете:
— версия платформы
— сервер или файл
— память
— свободное место (на системном диске и где лежит БД)
(7) Сервер 1С установлен 64-разрядный?
Службы - агент сервера 1С - исполняемый файл - C:\Program Files\1cv8\ ... то 64, тогда все ок.
Если C:\Program Files (x86) то 32 битный, переустановить на 64.
(11) Можете еще ее открыть и приложить скрин?
И еще вопрос - пробовали с тонкого клиента провести обновление? Чем обусловлен выбор толстого клиента при клиент-серверной работе ПО?
(25) >Как правило в толстом ошибке более понятны.
"Сомнительно но окэй".
Настройки кластера 1С по умолчанию? Если нет, то сделать таковыми, если да то дальше. Сервер выяснили что 64 разрядный, если клиент толстый и 32 битный то вполне возможно что он выбирает 4гб памяти и падает, проверьте в процессе так это или нет. Если да, то ставьте лучше тонкий 64 и пробуйте.
(11)А клиент? Платформа 1С на клиенте.
Были такие проблемы. Как раз с ЗУПом. Только через конфигуратор обновлял, а не в режиме Предприятия, доработки были.
Подключался 32-х разрядным клиентом к 64-х разрядному серверу. Приходилось всё-всё-всё на локале закрывать, кроме конфигуратора и надеяться. Два раза из трех обновление проходило, один раз падало.
Установил на рабочую станцию 64-х разрядного клиента и проблема ушла.
(16) Не понял, как через конфигуратор? После обновления через конфигуратор вы входите монопольно в предприятие, подтверждаете легальность обновления, дальше запускаются обработки по обновлению. Или нет?
(18)
(18)Да, все верно. После обновления - в монопольном режиме в режиме Предприятие.
Только падало у нас еще до того как добирались до Предприятия. Падал конфигуратор.
Либо на этапе сравнения/объединения, либо на этапе сохранения конфигурации.
После перехода на 64-разрядный клиент проблема ушла.
В обработке Результаты обновления программы можно посмотреть, что выполнилось уже, что нет, что в процессе. Сервер MS SQL или Postgree у Вас? Повторюсь, размер файла базы или лога не ограничен ли там? Или tempdb забил весь диск/ ограничен, если речь про ms sql идет.
В обработке Результаты обновления программы можно посмотреть, что выполнилось уже, что нет, что в процессе. Сервер MS SQL или Postgree у Вас? Повторюсь, размер файла базы или лога не ограничен ли там? Или tempdb забил весь диск/ ограничен, если речь про ms sql идет.
(19)гм. интересно, а что это даст? база же работает в обычном режиме. Регламентные задания выполняются. Сейчас обновляю на тесте. То есть выключаю регламентные задания и запускаю обновление? Попробую.
А провалиться в текст ошибки не дает? в какой процедуре падает то? На ветке 3.1.27 база обновилась быстро, нормально все. Может в цикл попало и до окончаний памяти тарабанит. Был такой случай когда-то.
Попробуйте применить вот это расширение в конфигураторе. Отключить безопасный режим.
Обновление должно будет пройти, но обратите внимание, что не будет выполняться обработчик ЗарплатаКадрыВнутренний.ЗаполнитьРегистрацииВОрганеСтатистики
И, соответственно, будет пустой регистр РегистрацииВОрганеСтатистики. С этим вам нужно будет отдельно разобраться после, возможно происходит какое-то зацикливание.