Установкак 102-ого релиза. Подводно-технические камни

[Denis E]

Несколько наших клиентов при установке 102-го релиза сталкиваются с тем, что компьютер "подвисает" на пересчёте операций. Решение для каждого из таких клиентов было найдено, но обобщить хотелось бы тут.
так как в новом релизе в журнале Товары и материалы - убрали документ Налоговый износ для ОС (старый). То при загрузке релиза пересчитываются все журналы документов. На больших базах - может занимать несколько большее время.
Поэтому, для более быстрой загрузки релиза рекомендуется делать это на локальном компьютере, с выключенным антивирусом и с большим запасом терпения и времени (варианты запустить загрузку релиза на ночь тоже годятся).
Спасибо пользователям Longina и bambino

[bambino]

Что-это подскажите.
Открыла "управление оперативными итогами" - стоит дата актуальности итогов "31,05,2006 ????" - исправляю дату, нажимаю ОК и раньше открывалоь окно с документами , проведенные/непроведенные, ну дальше чего я тут рассказываю Вы все знаете. Так воть окно это у меня пустое - ни проведенных ни непроведенных документов нету ччтоли??? Так должно быть? Или я опять все пропустила

[Longina]

В бухгалтерии оперативные итоги обычно не трогаем.
Т.к. они нас тоже не трогают.
В торговле надо открывать новый период.
У меня вообще дата актуальности итогов стоит 01.03.2003...
И ничего.

[bambino]

пасиб, успокоили

[Viens_C]

Обновления длилось более 30-и часов и успешно завершилось. То есть под конец работы запустили, на следующий день вечером еще не было готово. Где то ночью закончилось. Хорошо, я бухгалтершу предупредил про "Not responding", она не вырубила все это дело. Терпеливо ждала.

[Viens_C]

Как быть? Угробил все праздники. жду жду. и в результате ERROR.
Данное сообщение можно подтверждать до бесконечности, оно моментально появляется снова. "Task Manager" помог убить процэсс.
Повторяю и опять ERROR, опять "Task Manager" .

По атрибутам файлов понял - ждать 17 часов до глюка.
База весом 2.78Gb, WIN2003, PC двухпроцессорный intel xeon 2.80GHz 3Gb RAM
Свободно на С: 7.01Gb на Е: 15.9 Gb (База на Е )
На момент глюка база 4.83 Gb, то есть разбух NEW_STRU с 16.1MB на 2.06Gb.
Где копать ?

[Viens_C]

Теперь NEW_STRU удалил и запустил опять сохранение конфигурации. Через 17 часов посмотрю результат.

[Viens_C]

15 часов спустя вижу знакомый ERROR

[Denis E]

Как вариант: перед обновлением базы открыть конфигурацию, и удалить документ ВВОД НАЛОГОВЫХ ЛЬГОТ, а потом обновить конфигурацию.

[Viens_C]

Запустил "тестирование и исправление" базы. Были найдены и исправлены ошибки. Время не засекал, но результат смотрел через 3 часа. Удалил документ ВВОД НАЛОГОВЫХ ЛЬГОТ , сохранил изменения Ушло 1-3 мин (не засекал). Столько же ушло и на обновления релиза. ERROR не появлялся. Осталось выяснить где все таки гробится время. Проверю как пройдет, обновление битой базы без документа и исправной с документом. Там и про ERROR станит понятней.

Добавлено через 21 мин.

Попутно выяснил следующее:
Во время обновления конфигурации 1с, в каталоге NEW_STRU, создает дубликаты файлов 1SJOURN.DBF и 1SOPER.DBF.
Если сравнивать размеры данных файлов с размерами оригинальных, верней темпы роста, можно приблизительно спрогнозировать время "перекура".

Добавлено через 56 мин.

Взял, все туже, битую базу размером 2.78Gb, на которой знакомый ERROR. Удалил документ "ВВОД НАЛОГОВЫХ ЛЬГОТ". Сохранил. Обновил конфигурацию объединением (как и в прошлый раз), сохранил. На все ушло 5 мин. ERROR не появился, хоть база битая.
Значит предварительным удалением документа можно сэкономить кучу времени.
А про ERROR не все ясно. Куда он то пропал?

[Viens_C]

На исправной базе, не удаляя документ ВВОД НАЛОГОВЫХ ЛЬГОТ, 14 часов спустя опять получил тот-же ERROR.
---------------------------------------------------------------------------------------
И так, итоги. Как лечить - понятно. Но суть самой болезни ... ну и ладно, пациент жив, и хорошо.