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

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

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

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

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

Терпение терпение терпение ...
 

Обновления длилось более 30-и часов и успешно завершилось. То есть под конец работы запустили, на следующий день вечером еще не было готово. Где то ночью закончилось. Хорошо, я бухгалтершу предупредил про "[URL="http://forum.andi.lv/showpost.php?p=1761&postcount=8"]Not responding[/URL]", она не вырубила все это дело. Терпеливо ждала.

Как быть? Угробил все праздники. жду жду. и в результате 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.
Где копать ?

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

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

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

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

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

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

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

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

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