Ошибка "3" (варианты "0", "2", "8"...) и невозможность открытия пунктов меню в сессии

[a-v-mikhailov]

Коллеги,

В процессе программного создания строк в журнале ГК (Главная книга \ Журналы \ Распределение затрат, функционал подрядчика), после примерно 1700-ой строки в транзакции срабатывает некое исключение, которое выводит указанный в скрине 01 инфолог.

В инфолог невозможно провалиться; более того, после указанной ошибки в сессии клиента аксапты невозможно открыть ни один пункт меню - сразу возникают ошибки вида как на скрине 02. А при вызове "Сервис \ Параметры" - ошибка вида как на скрине 03 и падениа АОСа.

После открытия новой сессии клиента все ок.

Что это может быть? Логи сервера \ клиента молчат

Аксапта 4.0 SP2 ядро 4.0.2501.116, база MSSQL 2008 SP3

Спасибо,

[Krash]

В классе Info в начале метода add поставить точку останова?

[McArrow]

В стандартной аксапте такого элемента меню нет. Стало быть, это ваша доработка. В ней, видимо, имеется кривой код, который бросает эти исключения. Надо отлаживать код, чтобы локализовать проблему.

по поводу 25 ошибки писали ранее, весьма мистическая штука. Посмотрите поиск по форуму

[Perc]

У нас тоже есть на дакс4 функционал журналов распределения. АНД если не ошибаюсь. Мы явных глюков в коде не нашли.. мож плохо искали конечно). Но окно с такими сообщениями мы видели далеко не только в этом функционале, а много где. Где обрабатываются большое число данных с большим объемом выделяемой памяти под временные таблицы и прочие объекты. Функционал журналов распределения удобный конечно для своих целей, но при больших объемах выборок, довольно ресурсоемкий по памяти и времени. Выборку на 10-15 тыщ строк за разумное время было сделать почти не реально.
Поэтому явную ошибку вы вряд ли найдете. Где то в аксаптовском ядре утечки. Повысить порог падений нам помогает увеличения всяких памятей, перезагрузки клиентов и аоса каждую ночь в обязательном порядке.

[Player1]

Цитата:

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

...перезагрузки клиентов и аоса каждую ночь в обязательном порядке.

Это не шутка?
По ссылке из предыдущего сообщения чаще всего встречается подозрение на memo-поля, напрашивается первостепенная работа по их поиску. Сможете найти таблицы с полями типа memo?

[Perc]

Цитата:

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

Это не шутка?
По ссылке из предыдущего сообщения чаще всего встречается подозрение на memo-поля, напрашивается первостепенная работа по их поиску. Сможете найти таблицы с полями типа memo?

Не-е, не шутка. Конечно. все разница, в период не особой активности базы может неделями стоять без перезапуска, но в моменты массовых атак, к концу месяца начинает себя плохо чувствовать. Может клиентов начать сама выкидывать, а может и аос остановиться.
Нуда. в аксапте есть мемостроки. Таблицы найти поиском сможем. И что с ними делать? В таблицах относящихся к функционалу из темы мемополей нет.

[a-v-mikhailov]

Пока коллеги АНД диагностировали проблему в том, что в алгоритме создания строк журанла распределения использовался код исполняемый на клиенте и на сервере (класс LedgerJournalEngine_CostAlloc – исполнялся на клиенте, а метод определения филиала в филиальном учете xUserGroupDimension:: findUserDimension(), который вызывался при создании каждой строки – исполнялся на сервере). При отнесении выполнения LedgerJournalEngine_CostAlloc на сервер проблема пропала. Проблема вызывалась только при большом количестве строк. Очевидно она как то родом из взаимодействия клиент-сервер

[Perc]

Цитата:

Сообщение от a-v-mikhailov

При отнесении выполнения LedgerJournalEngine_CostAlloc на сервер проблема пропала. Проблема вызывалась только при большом количестве строк. Очевидно она как то родом из взаимодействия клиент-сервер

А может просто после отнесения выполнения на сервер у кода для исполнения ресурсов больше стало? И сами говорите проблема не исчезла, а лишь отодвинулась..