Join временной таблицы в запросе

[yahenz]

Всем привет!

Пересмотрел несколько похожих тем, но к сожалению, из-за нехватки опыта, понимания так и не пришло.
Задача такова: На форме (не важно какой, у формы 1 источник данных) нужно организовать фильтр по полю ItemId. Т.к. область значений может быть достаточна велика, то я решил использовать временную таблицу, заполнить ее нужными значениями (ItemId) и сдлеать join к постоянной таблице, являющейся источником данных на форме.

Я пытаюсь в executeQuery() сформировать запрос и присвоить его datasource формы.

Вот примерный код:

public void executeQuery()
{
    Query                           query;
    QueryBuildDataSource            qbdsRetailPriceBuffer, qbdsTmpTable;

    TmpTable tmpTable = TmpTable::InitOnServer();
    ;

    query = new Query();
    qbdsRetailPriceBuffer = query.addDataSource(tablenum(RetailPriceBuffer));

    if(InventLocationFilter.valueStr() && CustomSectionFilter.valueStr())
    {
        tmpTable.data(GetCustomSectionFilterResult(InventLocationFilter.valueStr(), CustomSectionFilter.valueStr()));
        qbdsTmpTable = qbdsRetailPriceBuffer.addDataSource(tablenum(TmpTable));
        qbdsTmpTable.addLink(fieldnum(RetailPriceBuffer, ItemId), fieldnum(TmpTable, ItemId));
        qbdsTmpTable.joinMode(JoinMode::ExistsJoin);
        qbdsTmpTable.fetchMode(false);
    }  

    this.query(query);
    super();
}

В методе TmpTable::InitOnServer() возвращается курсор временной таблицы созданной на сервере:

public static server TmpTable InitOnServer()
{
    TmpTable tmpTable;
    select firstonly tmpTable;
    return tmpTable;
}

В методе GetCustomSectionFilterResult(), заполняется и возвращается табл. переменная временной таблицы:

public static server TmpTable GetCustomSectionFilterResult(InventLocationId _inventLocationId, CustomSectionId _customSectionId)
{
    TmpTable    tmpTable = TmpTable::InitOnServer();
    ;

    //Заполнение tmpTable...

    return tmpTable;
}

Когда выполняется super(), выдает: "Временные таблицы должны быть вложенными (inner), когда вы объединяете их оператором join с постоянными таблицами".
Что же я делаю не так?

Помогите пожалуйста, если кто сталкивался.

С уважением, Евгений.

[Raven Melancholic]

Но мой взгляд, объединение постоянной таблицы с временной не самая удачная идея.
Я бы сделал так:
таблицу бы сделал не временной а нормальной.

• Одно из полей использовал бы в качестве какого-либо идентификатора сессии (непосредственно номера сессии или Guid)
• В форме бы сделал соединение основной таблицы с этой псевдовременной.
• Вызывал заполнение этой таблицы и устанавливал бы фильтр по полю-сессии.
• Ну и при закрытии очищал бы эту псевдовременную таблицу.

В свое время так пришлось делать в российских запросах по ГК (те, что похожи на стандартные 1С-овские типа ОСВ), так как счетов было порядка 1000 и в ранж запихнуть условия не получалось.

[lev]

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

попробую предположить решение вашей проблемы...
необходимо добавить курсор временной таблицы в QueryRun вашей формы, а именно написать в методе ExecuteQuery до супера (по идее все равно где именно) следующий код:

this.queryRun().setCursor(myTmpTable);

[S.Kuskov]

sumitax: Temporary Table and Join Query issue

[Pustik]

Цитата:

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

Когда выполняется super(), выдает: "Временные таблицы должны быть вложенными (inner), когда вы объединяете их оператором join с постоянными таблицами".
Что же я делаю не так?

Помогите пожалуйста, если кто сталкивался.

С уважением, Евгений.

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

[yahenz]

Цитата:

Сообщение от Raven Melancholic

Но мой взгляд, объединение постоянной таблицы с временной не самая удачная идея.
Я бы сделал так:
таблицу бы сделал не временной а нормальной.

• Одно из полей использовал бы в качестве какого-либо идентификатора сессии (непосредственно номера сессии или Guid)
• В форме бы сделал соединение основной таблицы с этой псевдовременной.
• Вызывал заполнение этой таблицы и устанавливал бы фильтр по полю-сессии.
• Ну и при закрытии очищал бы эту псевдовременную таблицу.

В свое время так пришлось делать в российских запросах по ГК (те, что похожи на стандартные 1С-овские типа ОСВ), так как счетов было порядка 1000 и в ранж запихнуть условия не получалось.

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

Цитата:

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

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

попробую предположить решение вашей проблемы...
необходимо добавить курсор временной таблицы в QueryRun вашей формы, а именно написать в методе ExecuteQuery до супера (по идее все равно где именно) следующий код:

this.queryRun().setCursor(myTmpTable);

Ммм, фильтр сам по себе простой - отобразить на форме только те номенклатуры, которые подходят под условие. Но простым addRange(...).value(...), как я понимаю решить не получится, т.к. длинна критерия в value(...) ограничена 250 символами. А у меня список номенклатур отбора может быть очень большим. Поэтому и хочу просто "схлопнуть" datasource формы связав его по номенклатурам во временной таблице.

Цитата:

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

sumitax: Temporary Table and Join Query issue

Благодарю, буду разбираться.

Цитата:

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

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

Как окажусь на работе, попробую, спс.

[Wamr]

не надо джоинить постоянные и временные таблицы.

Цитата:

длинна критерия в value(...) ограничена 250 символами

сделайте еще один addRange по тому же полю и еще один.. и еще.. и т.д.

[yahenz]

Цитата:

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

не надо джоинить постоянные и временные таблицы.

сделайте еще один addRange по тому же полю и еще один.. и еще.. и т.д.

Я правильно понял, если у меня будет 5000 номенклатур, то это 5000 addRange'й? Или необходимо создавать следующий рендж, только когда в первом "закончилось место"?

[db]

ну думаю не будет большим свинством процитировать себя Выборка произвольных записей одним запросом

[klimova_m]

Проверено: если Range становится очень много (в моем случае их 833 набралось), то Ax ругается так "Трассировка стека: При выполнении операции привязки не удалось распределить пространство буфера."

[kornix]

Цитата:

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

Проверено: если Range становится очень много (в моем случае их 833 набралось), то Ax ругается так "Трассировка стека: При выполнении операции привязки не удалось распределить пространство буфера."

Range ограничен 250 символами. Возможно, имеет смысл попробовать накладывать ограничения как-то по-другому. Довольно странно выглядит запрос к таблице, в котором в условии WHERE безумное количество ограничений.

длина Range

[oip]

Цитата:

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

Range ограничен 250 символами.

Нет у range в X++ ограничения в 250 символов. Ограничение в 250 символов есть только у EDT Range, который стандартно используется на формах для указания критериев запросов. Но и его длину можно увеличить.

А вот больше скольких-то сотен условий по ИЛИ добавить не получится, есть ограничение на уровень вложенности WHERE.

Аксапта для ИЛИ построит что-то типа такого и в некоторый момент загнется:

((((((((((((((((((((((((((((((((((((((((((((((((ITEMID=?) OR (ITEMID=?)) OR (ITEMID=?)) OR (ITEMID=?)) OR (ITEMID=?))...

[fed]

Цитата:

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

Нет у range в X++ ограничения в 250 символов. Ограничение в 250 символов есть только у EDT Range, который стандартно используется на формах для указания критериев запросов. Но и его длину можно увеличить.

А вот больше скольких-то сотен условий по ИЛИ добавить не получится, есть ограничение на уровень вложенности WHERE.

Я бы еще добавил, что при большом количестве условий по OR в where, увеличивается вероятность того, что сиквельный оптимизатор переглючит и он уйдет в full scan (Точнее конечно же - в поиск по индексу, но только по условию dataareaId==key).
Я, поэтому, всегда пользуюсь техникой, которую участник db описал. Хотя я ее предпочитаю даже не столько с точки зрения производительности, сколько с точки зрения наглядности...