|
12.03.2008, 20:38 | #1 |
Участник
|
Пересчет данных по периодам
Здравствуйте уважаемые.
Ax30 SP1 (клиент и сервер SP3) С недавних пор перестала работать процедура - Пересчет данных по периодам. При этом после часа работы система закрывается и пишет, что сервер закрыл соединение с вашим компьютером. При этом процедура не отрабатывается. Может быть кто-нибудь сталкивался с данной проблемой? Что посоветуете? Заранее благодарен.
__________________
Александр |
|
13.03.2008, 09:49 | #2 |
NavAx
|
Записей в LedgerTrans много?
Работают ли при этом пользователи с системой (пока идет пересчет)? Мониторили ли память ОЗУ на AOS? |
|
13.03.2008, 16:19 | #3 |
Участник
|
Цитата:
из них по переносу начальных сальдо - больше 3 млн. Люди при пересчете не работают. В двухзвенке вылетает из-за плохой памяти. По трехзвенке работает. Память жрет, но ее на серевере много. До предела не доходила. И что делать?
__________________
Александр |
|
13.03.2008, 17:04 | #4 |
Участник
|
Как вариант, с помощью незначительных доработок добавить в пересчет условия по дате и/или бух. счету
|
|
13.03.2008, 17:12 | #5 |
Участник
|
Цитата:
Думаю, что "условия по дате и/или бух. счету" не тот вариант, который бы хотелось получить.
__________________
Александр |
|
20.03.2008, 11:26 | #6 |
Участник
|
Посмотрите лог АОСа, если трехзвенка (иначе просто, лог клиента ). Возможно там есть запись о MaxOpenCursors или что-то типа этого. Если есть то, как минимум два варианта: модификация кода или увеличение данного значение в утилите приложения (по умолчанию там 90)
|
|
13.03.2008, 18:13 | #7 |
Участник
|
Дело возможно в большом объеме LedgerBalancesDimTrans. При персчете содержимое этой таблицы формируется целиком в памяти в одной транзакции
|
|
14.03.2008, 09:23 | #8 |
Участник
|
Цитата:
Подскажите пожалуйста. Не думаю, что только у нас так много записей.
__________________
Александр |
|
14.03.2008, 10:14 | #9 |
Участник
|
Для меня самый простой выход - оптимизировать сам механизм пересчета, например пересчитывать только проводки в открытых периодах, или вручную задавать интервал дат при пересчете, т.е каким либо образом уменьшить порцию вычислений в одной транзакции.
|
|
14.03.2008, 10:59 | #10 |
Участник
|
Понятно. Спасибо.
__________________
Александр |
|
20.03.2008, 22:57 | #11 |
Lean Six Sigma
|
Цитата:
Для меня самый простой выход - оптимизировать сам механизм пересчета, например пересчитывать только проводки в открытых периодах, или вручную задавать интервал дат при пересчете, т.е каким либо образом уменьшить порцию вычислений в одной транзакции.
Мне ещё кажется неоптимальным механизм пересчёта, т.е. само вычисление значений внутри транзакции. Я бы предложил его переписать целиком - сначала подсчитывать суммарные значения, потом их класть в RecordInsertList и только потом уже открывать транзакцию, внутри которой чистить таблицы сумм и вставлять в них значения из RecordInsertList'ов. |
|
20.03.2008, 23:18 | #12 |
Участник
|
Цитата:
Сообщение от Ned
Мне ещё кажется неоптимальным механизм пересчёта, т.е. само вычисление значений внутри транзакции. Я бы предложил его переписать целиком - сначала подсчитывать суммарные значения, потом их класть в RecordInsertList и только потом уже открывать транзакцию, внутри которой чистить таблицы сумм и вставлять в них значения из RecordInsertList'ов.
Пока подсчитываешь, кто-то может добавить новую проводку. В результате итоги не будут соответствовать проводкам. |
|
21.03.2008, 00:17 | #13 |
Lean Six Sigma
|
Логично, согласен. Просто скорость работы стандартного механизма убивает.
|
|
21.03.2008, 07:50 | #14 |
Участник
|
это не ежедневно использующийся механизм.
это механизм "лечения" остатков. |
|