Сбой обмена БП — УНФ 3.0
Зависает синхронизация данных на этапе анализа полученных данных.
Разобраться сложно, нашел наводку на решение на Мисте:
Зависает синхронизация данных на этапе анализа полученных данных.
Изучая проблему понял что тема не новая. На разных форумах периодически возникает вопрос по этой проблеме.
Пробовал разное, но в конечном итоге понял что без технологического журнала (ТЖ) не обойтись.Здесь на мисте уже была такая тема, к сожалению в архиве.
Зависает синхронизация данных через универсальный формат обмена
Там у автора была такая же проблема, которую он решил с помощью ТЖИз постав автора:
«включил технологический журнал, нашел лог обмена:Там идет код из модуля обмена, а потом обрыв:
Сеанс отсутствует или удален. Сеанс завершен администратором.»
«В общем все поправил, в одном из документов была номенклатура с группой, группой, которой являлась сама это группа, то есть циклическая ссылка. И при удаление повторяющихся элементов она перебирала сама себя пока фоновое задание обмена само аварийно не завершалось.» Конец цитаты.В чем собственно вопрос. Возможно у нас тоже в этом причина. Но сформировать файл настроек logcfg для меня пока сложновато, даже через обработку ИТС.
Тех.журнал тема для меня совсем новая. Немного изучил ее.
В общем кто может помочь в этом вопросе — сформировать файл настроек logcfg , который хотя-бы выявил такие объекты данных с неверными документами и номенклатурой.
Заранее благодарен.
Клиент тонкий, отладить нельзя. Пробовал запустить в режиме отладки, чтобы найти ошибку, но в таком режиме все равно запускается фоновое задание.
Тогда очистил изменения в УНФ, обмен прошел:
Будем надеяться, сбойный объект больше не зарегистрируется. Ну или надо выгружать в локальную копию и там искать в отладчике, на чем падает.
Или написать универсальный анализатор зацикливаний групп. Или вычленять виды объектов по одному, чтобы найти хотя бы вид объекта, на котором падает обмен.
Среда: УНФ 3.0.6.171 Объем: 0.5 час
«Клиент тонкий, отладить нельзя.»
можно.
не исключено. Но сложно.