вопрос по Query

[mazzy]

ок. убедили.

вариант S.Kuskov: приджойнить exist join тоже не подойдет. поскольку в запросе уже может быть join. http://msdn.microsoft.com/en-us/libr...36(AX.10).aspx

тогда остается только перебор записей в случае, если критерий на accountNum установлен?

[S.Kuskov]

Цитата:

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

тогда остается только перебор записей в случае, если критерий на accountNum установлен?

А чем не подходит такой вариант?

    boolean findSuperCust(Query _srcQuery, CustAccount _custAccount = "КлиентАБВ")
    {
        Query q = new Query(_srcQuery); // создаем копию
        QueryBuildDataSource qbds = q.dataSourceTable(tablenum(custTable));
        QueryBuildRange qbr;
        QueryRun qr;
        Range SuperCustRange = strfmt("(%1.%2 == %3)", qbds.name(), fieldStr(custTable, AccountNum));

        // устанавливаем новый критерий или меняем существующий
        qbr = SysQuery::findOrCreateRange(qbds ,fieldnum(custTable, DataAreaId));
        if (qbr.value())
            qbr.value(strfmt("(%1 && %2)", SuperCustRange, qbr.value()));
        else
            qbr.value(SuperCustRange);

        // выполняем запрос
        qr = new QueryRun(q);
        return qr.next();
    }

Я вижу один недостаток - ограничение на длину строки в Range.

[AndyD]

Цитата:

Сообщение от S.Kuskov

            qbr.value(strfmt("(%1 && %2)", SuperCustRange, qbr.value()));

Хм.
А что, уже стало возможно использовать совместно расширенный синтаксис фильтров и обычный?

[S.Kuskov]

Цитата:

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

Хм.
А что, уже стало возможно использовать совместно расширенный синтаксис фильтров и обычный?

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

Я тут ещё один чисто теоретический способ придумал .
Как понятно из обсуждения, основной проблемой является сложность присоединения, в случае уже имеющегося условия, нового контрольного условия по "И". Вот я и подумал раз уж это так проблемно, то пусть оно себе присоединяется по "ИЛИ". В результате исходный запрос изменится и это изменение можно будет анализировать. В случае если количество строк возвращаемое запросом (можно посчитать при помощи SysQuery::countTotal) станется прежним, это будет означать (конечно с определёнными ограничениями), что новое условие по ИЛИ никак не повлияло на выборку, а следовательно исходный запрос содержал в себе контрольное условие. Что и требовалость орпределить

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

[mazzy]

Цитата:

Сообщение от S.Kuskov

а следовательно исходный запрос содержал в себе контрольное условие.

или не содержал И искомого значения в базе вообще нет.
не, не пойдет

[AndyD]

Цитата:

Сообщение от S.Kuskov

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

Можно на поле TableId добавлять рэйнж.
Пользователи его просто не видят в интерфейсе

Кстати, никто не обращал внимание, что критерии со статусом Hidden - не такие уж и невидимые?
Достаточно в форме расширенного фильтра вызвать расширенный фильтр (в 2009-й через комбинацию клавишь) и нажать Ok

[mazzy]

Цитата:

Сообщение от S.Kuskov

Я вижу один недостаток - ограничение на длину строки в Range.

угу.

[Alexius]

Можно попробовать добавить явный критерий по RecId искомой записи клиента, если он не используется в запросе (обычно не используется ).
Если используется, то через расширенный фильтр по аналогии с кодом клиента описанной выше у S.Kuskov.
Или напрямую распарсить критерии по RecId и либо найти в них искомый и оставить только его либо выдать облом