Итоговые суммы

[DA_NEAL]

Тут в соответвии с одним обсуждением на Axforum решил сделать почти унивесальную итоговую формочку.

Для запуска сделайте следующее (пример для 32 таблички):

RecRef.OPEN(32);
RecRef.SETTABLE(Rec);

IF TOTALS.SetTotalonRecordRef(RecRef) THEN
TOTALS.RUNMODAL();

Есть ограничение на 25000 записей в наборе данных. Его можно поправить. Суммирует и флоуфилды.

Погоняйте кто-нибудь на реальных данных и скажите чего-нибудь. То что форма тормозит я и так знаю. Жду рекомендаций по оптимизации кода.

[rmv]

Имхо, бесполезная фича.
Вот если бы форма собирала суммы через запросы к sql сервру, да еще на кодовые поля count(distinct("Field Name")) засунуть (очень порой пользователей интересует скольким клиентам товар продали и от скольки поставщиков закупили, да еще из скольки стран везли , да по флоу полям полям в нужные таблицы лезла и правильный bucket выбирала - цены бы ей не было .
А еще (эх кто бы меня заткнул ) - поля бы ей передавать в разрезе которых отчет строить и в group by запроса их кинуть.

А так всеж-таки проще через calcsums работать. Неуниверсально, зато на порядки быстрее, имхо.

[DA_NEAL]

calcsums частное решение... надо и ключ установить и фильтры только диапазонами да и по полям только ключевым...

Можно и анализатор запроса в принципе написать (тока для одной таблички) но такой запрос работать будет по пол - дня .

[rmv]

Цитата:

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

calcsums частное решение... надо и ключ установить и фильтры только диапазонами да и по полям только ключевым...

Можно и анализатор запроса в принципе написать (тока для одной таблички) но такой запрос работать будет по пол - дня  .

<{POST_SNAPBACK}>

Ну почему же для одной таблички?
есть волшебные таблицы database, company, field.., хотя без последней наверно можно обойтись.
Насчет скорости я бы поспорил. На миллионе записей в 32 табличке прямой запрос в базу все ж таки быстрее будет, нежели цикл по записям

[DA_NEAL]

Я имел ввиду что можно написать интерпретатор SQL для navision, но при своей работе он все равно будет использовать операторы C/AL. Таким образом о скорости и речи быть не может.

[rmv]

Цитата:

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

Я имел ввиду что можно написать интерпретатор SQL для navision, но при своей работе он все равно будет использовать операторы C/AL. Таким образом о скорости и речи быть не может.

<{POST_SNAPBACK}>

DA_NEAL - вы ошибаетесь .
Попробуйте в QA набрать select [Country of Origin Code], count(distinct([Item No_])), sum(Quantity) from [Имя_Фирмы_Item Ledger Entry] group by [Country of Origin Code], написать аналогичный код в С/A и сравнить скорость.

PS. Речь идет о версии под SQL сервер .

[DA_NEAL]

да я не ошибаюсь, я говорю о том что если средствами языка C/AL эмулировать работу select'а написав интерпретатор то такой запрос будет работать медленно так как будет базироваться на циклах и временных таблицах Navision. Я вообще не говорю про Query Analizer и т.д. Понятно что прямой SQL запрос работает быстрее но из navision вы его не вызовите... Надеюсь я понятно сейчас выразился

[DA_NEAL]

кстати thx mazzy за респект... неужели хоть кому то пригодилось !

[rmv]

DA_NEAL - ну почему же не вызову? ADO еще никто не отменял.

[DA_NEAL]

ну понятно... но ты же понял что я имел ввиду