вопрос по Query

[Владимир Максимов]

Цитата:

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

В общем случае подцепить к имеющемуся query ещё один CustTable с типом связи exists join и наложить уже на него условие "КлиентАБВ". Затем сделав один раз queryRun.next() посмотреть вернулось ли что-нибудь.

К сожалению, это ничего не гарантирует. Если исходный запрос относительно сложен и имеет несколько таблиц-источников с "не линейной" схемой объединения, то подключение еще одного источника по Exists Join может привести к тому, что запросу "снесет крышу". Результат может оказаться парадоксальным.

В принципе, общая идея, заключающаяся в том, что нужно наложить еще один Range по этому полю - правильная. Проблема только в том, что этот Range должен подкючаться по "И", а если уже есть Range по этому же полю, скажем, настроенный пользователем, то подключение произойдет по "ИЛИ"

Именно для данного конкретного случая можно сделать "хитрый трюк". Дело в том, что определение того факта, что Range добавляется по уже существующему полю выполняется по Id поля. При этом, как правило, используется FieldId. Однако Axapta может идентифицировать поле как по FieldId, так и по ExtendedFieldId. Т.е. идентифицировать поле, как первый элемент массива.

Естесственно, что FieldId и ExtendedFieldId - это разные значения. Как следствие, построитель запросов интепретирует их как разные Range и выполняет объединение по "И".

Получается, примерно следующее

static void Job_Test(QueryRun   queryRun)
{
    Query                   queryFind;
    QueryRun                queryRunFind;
    QueryBuildDataSource    qbds;
    QueryBuildRange         qbr;
    ;
    
    queryFind = new Query(queryRun.query().pack());
    qbds = queryFind.dataSourceTable(tablenum(CustTable));
    
    // Вот этот трюк
    qbr = qbds.findRange(fieldnum(CustTable, accountNum));
    if (qbr)
    {
        // Если Range уже есть, то создаю новый Range по ExdendendFieldId
        qbr = qbds.addRange(fieldId2ext(fieldnum(CustTable, accountNum),1));
    }
    qbr.value('КлиентАБВ');
    
    
    queryRunFind = new QueryRun(queryFind);
    if (queryRunFind.next())
    {
        info("Есть такая запись");
    }
    
}

Естесственно, этот трюк работает только для полей, которые массивами не являются. Для полей-массивов можно сделать подобное только для первого элемента массива.

[S.Kuskov]

Цитата:

Сообщение от Владимир Максимов

Именно для данного конкретного случая можно сделать "хитрый трюк".

Да про данный "трюк" я в курсе. Но сдаётся мне что это поведение запросто могут "исправить" в какой-нибудь следующей версии системы.

Если выбирать из предложенных вариантов, то мне больше нравится мой про использование http://www.axaptapedia.com/Expressions_in_query_ranges

P.S.: propeller, вот уж действительно "простейшая задача"

[dn]

Цитата:

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

В общем случае подцепить к имеющемуся query ещё один CustTable с типом связи exists join и наложить уже на него условие "КлиентАБВ". Затем, сделав один раз queryRun.next(), посмотреть вернулось ли что-нибудь.

Цитата:

Сообщение от Владимир Максимов

К сожалению, это ничего не гарантирует. Если исходный запрос относительно сложен и имеет несколько таблиц-источников с "не линейной" схемой объединения, то подключение еще одного источника по Exists Join может привести к тому, что запросу "снесет крышу". Результат может оказаться парадоксальным.

А если использовать не ExistsJoin, а InnerJoin?

boolean findSuperCust(Query _srcQuery, CustAccount _custAccount = "КлиентАБВ")
{
    Query                   q;
    QueryRun                qr;
    QueryBuildDataSource    qbds,qbds2;
    ;
    q               = new Query(_srcQuery);
    qbds            = q.dataSourceTable(tablenum(custTable));
    qbds2           = qbds.addDataSource(tablenum(custTable));
    qbds2.fields().addField(fieldNum(custTable, AccountNum));
    qbds2.fetchMode(JoinMode::INNERJOIN);
    qbds2.relations(true);
    qbds2.addRange(fieldNum(custTable, AccountNum)).value(_custAccount);    
    qr = new QueryRun(q);
    return qr.next();  
}

[AndyD]

Цитата:

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

    qbds2.fetchMode(JoinMode::INNERJOIN);

Вы, наверное, с JoinMode() перепутали?
Но FetchMode() тоже надо будет настраивать, если есть другие датасорсы, подключенные к CustTable.

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

[dn]

Цитата:

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

Вы, наверное, с JoinMode() перепутали?
Но FetchMode() тоже надо будет настраивать, если есть другие датасорсы, подключенные к CustTable.

Спасибо, за поправку.
qbds2.joinMode(JoinMode::innerJoin);
qbds2.fetchMode(QueryFetchMode::One2One);

Цитата:

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

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

Возможно. Но на практике, когда не проходил ExistJoin, вариант с InnerJoin проходил. Хотя согласен, что в общем случае это видимо не всегда будет работать.

[mazzy]

Цитата:

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

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

может-может.
только в случае нескольких вложенных таблиц Аксапта возвращает записи ПОСЛЕДОВАТЕЛЬНО.

я уже ссылку давал

Цитата:

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

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

прикладываю и картинку

[dn]

Цитата:

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

прикладываю и картинку

Эта картинка относится к варианту связи источников данных OuterJoin (судя по информации по приведенной ссылке). А как это соотносится с Exists и Inner Join'ами?

[mazzy]

Цитата:

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

А как это соотносится с Exists и Inner Join'ами?

хорошо соотносится.
проверьте.

[S.Kuskov]

Цитата:

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

Но FetchMode() тоже надо будет настраивать, если есть другие датасорсы, подключенные к CustTable.

Про FetchMode хорошо написал Иван Кашперук Связывание источников данных в запросах

Цитата:

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

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

Соглашусь с тем что замена "exists join" на "inner join" во многих случаях поможет, но не всегда.
Проблема с "exists join" связана с тем, что если такой exists будет вставлен между двумя таблицами уже соеденёнными при помощи "inner join", то результирующий запрос получится не всегда ожиданным.

Например, такой гипотетический код:

select Table1
exists join Table3 where Table3.id == Table1.id
inner join Table2 where Table2.id == Table1.id

будет преобразован примерно вот в такой запрос:

table1 where exists (select Table3 join table2)

Если обойтись без Exists join и всегда использовать Inner join, то тогда проблема может появится уже по другой причине. Может быть превышено максимальное число приджойненных таблиц.

[dn]

Цитата:

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

хорошо соотносится.
проверьте.

Такое поведение как раз задается fetchmode 1:n

[S.Kuskov]

Цитата:

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

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

Ну это легко проверить простым дополнительным запросом.

Цитата:

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

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

Ух ты. Такое поведение нужно исправлять. Например так. На форме SysQueryForm, в методе init() датасурса Range

void init()
{

    super();

    selectRangeRecords = this.query().dataSourceNo(1).addRange(fieldnum(TmpSysQuery, RangeStatus));
    selectRangeRecords.value('!' + enum2str(RangeStatus::Hidden));

    selectRangeRecords.status(RangeStatus::Locked); // <<--
}

Цитата:

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

А если использовать не ExistsJoin, а InnerJoin?

О! Здравая идея. А для оптимизации тогда ещё можно задать addSelectionField со значением SelectionField:atabase по какому-нибудь полю индекса