Ввод начислений (RPaySumEmpl) - помогите оптимизировать расчет итогов

[z_av]

Подскажите, как ускорить расчет итогов в форме
"Ввод начислений и удержаний" (RPaySumEmpl) ?

Суть проблемы: на форме для источника данных (таблица RPayTrans)
определены три display-метода: sumOnHand, sumNach, sumUder.
Эти методы выполняются неприемлемо медленно, особенно это
заметно, если таблица RPayTrans достаточно заполнена.

Пробовал следующее:
1) Объявлял на форме переменную-контейнер, где хранил кэш значений итогов таким образом, чтобы они вычислялись на сервере, только за один раз для каждой записи.
Удалось слегка уменьшить время реакции, но все равно не устраивает - слишком медленно.
2) Пробовал оптимизировать сами запросы, тк получается, что все тормоза - изза них.
В самом деле - журнал трассировки показывает, что ни в одном случае индексы не применяются :-(.
Создавал на таблице EmplTable индекс по полю PayMainEmplId_Ru, указывал
в запросе соответствующий index hint, не помогает - индексы все равно не используются.

Теперь вопросы:
1) Почему методы sumOnHand, sumNach, sumUder написаны так,
что запрос к данным выполняется на клиенте:
это баг, или так на самом деле быстрее?

2) Если мои попытки перенести расчет на сервер все-таки
правильные, тогда подскажите как заставить Систему все-таки
использовать индекс в этих запросах?

Спасибо.

[maxsmirnov]

мда..
самая непрофессионально сделанная форма из встречавшихся мне в аксапте...
одни названия контролов чего стоят...

а) переносите на клиент
б) кешируйте дисплей методы штатными средствами (у вас ах2.5 или вы о них не знаете? так, на всякий случай - ищите в хелпе по слову cacheaddmethod)

в) относительно самих запросов

не всегда можно заставить субд применять индекс в запросах типа select sum(amount) from rPayTrans, как в вашем случае.

современные планировщики запросов выбирают в таких случаях индексированный или последовательный поиск ориентируясь на собираемую ими статистику распределения значений в ключевых полях. т.е. грубо говоря, ваш планировщик запросов думает что записей с таким payPeriod в таблице много, и проще последовательно перебрать все строки, чем искать каждую по индексу.
и, м.б., он и не ошибается

вы используете функциональность "с учетом совместителей"?
если нет, то можно избавиться от джойна с emplTable, я думаю, это существенно убыстрит запрос.
никаких exist join-ов в реальности не существует, это лишь часть известного заговора майкрософта с производителями железа

а если используете - можно написать два разных запроса - быстрый, без галочки "с учетом совместителей", и медленный, с галочкой

[z_av]

Цитата:

вы используете функциональность "с учетом совместителей"?
если нет, то можно избавиться от джойна с emplTable, я думаю, это существенно убыстрит запрос.
...
а если используете - можно написать два разных запроса - быстрый, без галочки "с учетом совместителей", и медленный, с галочкой

Спасибо. Попробую действительно развести варианты запросов на "exist join" и без него.
Функциональность совместителей - используем. Вернее ее может использовать наш клиент, поэтому вырезать не будем.
Да, про exist join я знаю, трассировщик SQL ведь показывает что к чему ...
Если я Вас правильно понял, то про индексы в моем случае придется забыть ... ммм, печально, может есть шанс их включить?

Цитата:

а) переносите на клиент
б) кешируйте дисплей методы штатными средствами (у вас ах2.5 или вы о них не знаете? так, на всякий случай - ищите в хелпе по слову cacheaddmethod)

У нас 3.0, что такое кеширование дисплей методов - это мне известно, но если я вместо трех запросов все-таки буду выполнять один и к тому же на сервере, разве это не ускорит выполнение ?

[z_av]

Проблема решена -
Запросы по расчету итогов просто переписаны начисто.
При этом учет функциональности "совместители" поддерживается точно так же, как и в оригинальной версии. Зачем там нужен был exists join ? - загадка. И без него можно было обойтись.

Решение прилагаю. Проверялось на конфигурации ax 3.0 sp3, БД Oracle, в 2- и в 3- уровневых режимах.