Есть ли альтернатива SysQuery::countLoops(_queryRun)

[Beast-L]

Нужно посчитать количество результирующих строк при обработке запроса к таблице InventSum и другим подобным. При использовании SysQuery::countLoops тратиться много времени на перебор строк результата обычным циклом. Хотелось бы что нибудь побыстрее. Может как-то напрямую к БД (Oracle)?

[kashperuk]

А что конкретно ты хочешь посчитать?
В смысле, напиши словами, какой запрос ты хочешь получить?

Не могу придумать, что такого можно считать (кол-во строк) по InventSum

[glibs]

Цитата:

Сообщение от Beast-L

...
При использовании SysQuery::countLoops тратиться много времени на перебор строк результата обычным циклом.
...

Откудова у вас такая информация?

Походите дебагером по вот такому джобу. Вложенные циклы в каком месте вас смущают?

static void glibs()
{
Query query;
Counter counter;
;

query = new Query();
query.addDataSource(tablenum(InventSum));

counter = SysQuery::countTotal(new QueryRun(query));

info (strfmt("%1", counter));

}

[mazzy]

Цитата:

Сообщение от Beast-L

Нужно посчитать количество результирующих строк при обработке запроса к таблице InventSum и другим подобным. При использовании SysQuery::countLoops тратиться много времени на перебор строк результата обычным циклом. Хотелось бы что нибудь побыстрее. Может как-то напрямую к БД (Oracle)?

countLoops возвращает не "количество результирующих строк", а количество выполнений цикла по группировкам.
"количество результирующих строк" возвращает countTotal.

Сначала выполняется группировка, внутри групп выполняется count(recid) (для countTotal), а уже по группам идет цикл (чтобы подсчитать число выполнений цикла).

См. также FAQ: http://forum.mazzy.ru/index.php?showtopic=300

[Beast-L]

public client server static Integer countLoops(QueryRun _queryRun)
{
    container c = sysQuery::countPrim(_queryRun.pack(false));

    return conPeek(c,2);
}

private server static container countPrim(container _queryPack)
{
    ....

    while(countQueryRun.next())
    {
        common  = countQueryRun.get(countQuery.dataSourceNo(1).table());
        counter += common.recId;
        loops++;
    }

    return [counter,
            loops];
}

Как раз таки loops меня устраивает а не counter. Дело в том что мне нужно количество строк которые будут отображаться в гриде на форме. Я уже попробовал countTotal, 100% не то что мне нужно.

[mazzy]

Цитата:

Сообщение от Beast-L

Я уже попробовал countTotal, 100% не то что мне нужно.

Скорее всего вы ошибаетесь.
Но как пожелаете.

[Beast-L]

Во всяком случае напрямую rows = SysQuery::countTotal(_queryRun); мне не подходит.

[Beast-L]

Цитата:

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

А что конкретно ты хочешь посчитать?
В смысле, напиши словами, какой запрос ты хочешь получить?

Не могу придумать, что такого можно считать (кол-во строк) по InventSum

Ну например заказчик хочет в форме остатков (своей) видеть всё по серийным номерам с наложенными фильтрами например по цвету если строк в гриде будет 10 это и так наглядно видно а вот когда например 510 уже посчитать глазами не так то и просто. Или ДК в проданных хочет иметь возможность видеть количество строк в гриде что бы оценивать объёмы продаж

[kashperuk]

Show me the QUERY from the grid

[Beast-L]

SELECT * FROM InventSum WHERE ((((AvailPhysical > 0)))) JOIN * FROM InventTable WHERE InventSum.ItemId = InventTable.ItemId JOIN * FROM InventDim WHERE InventSum.InventDimId = InventDim.inventDimId JOIN * FROM InventLocation WHERE InventDim.InventLocationId = InventLocation.InventLocationId AND ((InventLocationType_UAI = Автомобили))

[glibs]

Цитата:

Сообщение от Beast-L

...
видеть количество строк в гриде что бы оценивать объёмы продаж
...

Это даже не женская логика...

Один уважаемый на данном форуме мой коллега анекдот рассказывал. Не могу найти в сети, но примерно так звучит.

Сынуля: Папа, я сегодня с девушкой на дискотеку иду. Мне деньги нужны.
Папа: А сколько тебе нужно?
— (Показывает большим и указательным пальцем руки размер пачки денег толщиной примерно с сантиметр) Вот столько.
— Ну, возьми в тумбочке.
— А в какой?
— Да в любой.

У вас примерно вот так же с объемом продаж получается .

[Beast-L]

Понимаю как это со стороны выглядит, но лично я объёмы продаж оценивать не собираюсь. Заказчик просит я делаю, а как он уже этим пользоваться будет это меня мало беспокоит. Кроме того не вижу проблем в оценке объёмов если все проданные единицы попадают в одну таблицу из которой данные берутся на форму на которой столько фильтров сколько хочет заказчик, а оценивать как раз таки ему. Заказчику по моему видней что ему нужно для оценки объёмов продаж.

[kashperuk]

Не знаю, поможет ли, но попробуй вот этот метод использовать (его добавить надо в класс SysQuery)

public client server static Integer dev_countTotal(Query _query)
{
    int                     k;
    Query                   countQuery = _query.newObject(_query.pack(FALSE));
    QueryRun                countQueryRun;
    QueryBuildDataSource    dataSource = countQuery.dataSourceNo(1);
    QueryBuildFieldList     theFieldList = dataSource.fields();
    Common                  record;
    int                     ret = 0;

    // Add contribution from dynalinks...
    countQuery = SysQuery::copyDynalinks(countQuery, _query);
    theFieldList.addField(fieldnum(Common, RecId), SelectionField::COUNT);

    for (k = 2; k <= countQuery.dataSourceCount();k++)
    {
        dataSource = countQuery.dataSourceNo(k);
        theFieldList = dataSource.fields();
        theFieldList.dynamic(false);
        theFieldList.clearFieldList();
        theFieldList.addField(fieldNum(Common,TableId));
    }

    countQueryRun = new QueryRun(countQuery);
    while (countQueryRun.next()) {
        record = countQueryRun.getNo(1);
        ret += record.RecId;
    }

    return ret;
}

[mazzy]

См. job из FAQ'а
Лучше внести правку в сам код, нежели создавать отдельный метод.
Там была ошибка, ее нужно поправить.

Цитата:

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

        theFieldList.addField(fieldNum(Common,TableId));

А вот с этим будьте предельно осторожны.
TableID - псевдополе, которое отсутствует на SQL.
Запрос может выродится как в "select * from", в "select from" или в "" в разных версиях.
В общем, если хочется сократить количество возвращаемых полей, то для получаения гарантированного результата в любых версиях и сервис-паках, в списке полей должно быть хотя бы одно ХРАНИМОЕ на SQL поле.

[kashperuk]

Цитата:

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

См. job из FAQ'а
TableID - псевдополе, которое отсутствует на SQL.
Запрос может выродится как в "select * from", так и в "select from" в разных версиях.

Код работает везде начиная с AX 3.0 SP3
На более ранних версиях не проверял.

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

[mazzy]

Цитата:

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

Сергей, а есть где-то задокументированные примеры такого поведения?

Нет. Задокументированных не видел.

Но мне задают кучу вопросов. Несколько раз источником багов в запросах было наличие псевдполей и отсутствие хранимых полей. В том числе TableID. Особенно в join'ах.

Может быть, я дую на воду.
Но каждый раз, если есть возможность, предупреждаю о возможных проблемах с псевдополями.

[Beast-L]

Спасибо, то что доктор прописал