Кастомный скрипт стал завершаться ошибкой

[Lankey]

Добрый день
Проблемка: есть очень простой кастомный скрипт. Он удялет markUpTrans 1ой закупки. Их там около 100 записей.Мы его уже использовали раньше. Все работало ок и выполнялся за минуту Но вдруг появились очень странные проблемы.
Причем, не важно, какой номер закупки задать

1) Первый запуск очень долго исполняется минут 20 и будто повисает, но кпонка запустить становится доступна. Статус не меняется (остается Approved, а не failed или Run completed). Логи видно. что будто обрываются.

2) Перезапускаю его же(раз кнопка test run доступна).
Заканчивается со странной ошибкой:
Unable to start trance: A trace with the same name is already running or hasn't been cleaned up/ Please use a difference trace name
При этом статус скрипта меняется на Failed

Когда копирую логи в word то вижу, что там более 300 страниц.
Есть подозрение, что переполняется лог при первом прогоне, так и не закончив скрипт. И какая-то ошибка некорректно прерывает исполнение


Бывало ли у вас такое? Как решили?

[Lankey]

Такое ощущение, что custom script на бэкгроунде открывает traceParcer и он переполняется, выдает ошибку(что пользователь не видит) и скрипт фреймворк кастом скриптов ее некорректно обрабатывает.

[fed]

Цитата:

Сообщение от Lankey

Такое ощущение, что custom script на бэкгроунде открывает traceParcer и он переполняется, выдает ошибку(что пользователь не видит) и скрипт фреймворк кастом скриптов ее некорректно обрабатывает.

Правильно. Custom script открывает сессию трассировки, но трассирует там не все операции, а только SQL запросы (которые он собственно и показывает при завершении сесии). При этом у меня ощущение что логирует он это дело не в файл, а в область памяти. По крайней мере я несколько раз убивал текущий AOS запустив там длинный скрипт (в LCS было видно как память заполнялась и переполнялась).Может быть Микрософт как-то в последних версиях ограничил размер используемой для трассировки памяти, но корректно обрабатывать ее переполнение он так и не научился. Могу также предположить что у вас там в скрипте вызовы skipDataMethod, skipEvents, skip* не стоят и после того как у вас кто-то перекрыл метод delete на markupTrans (или чего-то подобное), у вас один sql запрос на удаление заменился на кучу мелких одиночных запросов, которые трассировку и переполняют.

[Lankey]

Спасибо, что подтвердили предположение!
Да, вызовы skip не стоят, но это нормально , тк иначе будет data inconsistency
Ненормально, что это приводит к таким последствиям, будто я все данные во всех таблицах базы в одной транзакции удаляю ... гррр
Мало того, что диалога не привинтишь в эти уродливые кастомные скрипты(чтобы управлять выбркой в данном слуачае и удалять блоками, например), так они еще и элементарно толком не работают