select в X++ и список значений в условии where

[Prophetic]

Здравия всем.

Хочу выбрать записи в X++ из таблицы СustInvoiceTrans с условием InventLocationId, заданном в виде строки 'СКЛАД1,СКЛАД2,СКЛАДN'
Список InventLocationId формируется из параметров запроса -- сделано для того, чтобы пользователь не выбирал InventDimId.
Код приведен ниже, но оператора IN, аналогичного T-SQL я не нашёл.
Что нужно написать в условии where?

// ... получено из параметров запроса:
str inventLocationId = 'СКЛАД1,СКЛАД2,СКЛАДN'

select custInvoiceTrans 
join InventDim
        where inventDim.inventDimId == CustInvoiceTrans.InventDimId
    join inventLocation
        where inventLocation.InventLocationId == inventDim.InventLocationId &&
              inventLocation.InventLocationId  == .......

Возможно, есть более элегантное решение проблемы?

[nix0root]

Используй queryBuildRange.value(....)

[Prophetic]

Цитата:

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

Используй queryBuildRange.value(....)

Так у меня список InventLocationId Это получается, нужно переводить список InventLocationId в список InventDimId? Хотелось бы более просто решить этот вопрос.

[lev]

Цитата:

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

Так у меня список InventLocationId Это получается, нужно переводить список InventLocationId в список InventDimId? Хотелось бы более просто решить этот вопрос.

не надо ничего переводить никуда

queryBuildRange.value(inventLocationId) и все

[oip]

Возможно, конечно. Использовать query.

[lev]

подробнее

qbdsCustInvoceTrans = query.addDataSource(tablenum(CustInvoiceTrans));
qbdsInventDim = qbdsCustInvoceTrans .addDataSource(tablenum(InventDim));
qbdsInventDim .relation(true);
qbdsInventDim.addRange(fieldNum(InventDim, InventLocationId)).value(inventLocationId);

[Prophetic]

Цитата:

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

подробнее

qbdsCustInvoceTrans = query.addDataSource(tablenum(CustInvoiceTrans));
qbdsInventDim = qbdsCustInvoceTrans .addDataSource(tablenum(InventDim));
qbdsInventDim .relation(true);
qbdsInventDim.addRange(fieldNum(InventDim, InventLocationId)).value(inventLocationId);

Да, это решит проблему, благодарю. Однако, вопрос в том, что я пытаюсь модифицировать класс CustTransStatistics, в котором уже всё завязано на простую таблицу. Просто очень не хочется ВСЁ переписывать.
Может быть есть ещё другой способ отфильтровать по складам?

[Gustav]

У меня вот здесь Можно ли в SELECT использовать критерия вида "10..20" было некоторое подобие IN для таких случаев недлинных списков. Во всяком случае, визуально в составе select'а выглядит вполне удовлетворительно. Может, подойдёт приемчик?

[nix0root]

Как вариант используйте прямой запрос к базе с IN-ми и LIKE-ми )

[Prophetic]

Цитата:

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

У меня вот здесь Можно ли в SELECT использовать критерия вида "10..20" было некоторое подобие IN для таких случаев недлинных списков. Во всяком случае, визуально в составе select'а выглядит вполне удовлетворительно. Может, подойдёт приемчик?

Приём интересный, но не сработал: "Использование контейнеров и полей с неограниченными строками (текстом) в выражении WHERE не допускается.". Ибо у меня значения критериев не руками прописываются, а получаются из формы в виде строки.

[S.Kuskov]

Цитата:

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

Как вариант используйте прямой запрос к базе с IN-ми и LIKE-ми )

Нет. Не нужно так поступать.

Цитата:

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

Приём интересный, но не сработал: "Использование контейнеров и полей с неограниченными строками (текстом) в выражении WHERE не допускается.". Ибо у меня значения критериев не руками прописываются, а получаются из формы в виде строки.

Просто используйте вместо типа str, какой-нибудь расширенный тип данных, ни или на крайний случай пишите "str 30", т.е еграничте длину типа

[Dron AKA andy]

Цитата:

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

У меня вот здесь Можно ли в SELECT использовать критерия вида "10..20" было некоторое подобие IN для таких случаев недлинных списков. Во всяком случае, визуально в составе select'а выглядит вполне удовлетворительно. Может, подойдёт приемчик?

Цитата:

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

Приём интересный, но не сработал: "Использование контейнеров и полей с неограниченными строками (текстом) в выражении WHERE не допускается.". Ибо у меня значения критериев не руками прописываются, а получаются из формы в виде строки.

Вообще-то сообщение компилятора вполне справедливо, т.к. в запросе через макрос подставляется использование контейнера. Так что такой вариант не подходит...

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

Цитата:

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

Однако, вопрос в том, что я пытаюсь модифицировать класс CustTransStatistics, в котором уже всё завязано на простую таблицу. Просто очень не хочется ВСЁ переписывать.
Может быть есть ещё другой способ отфильтровать по складам?

А почему не сделать напрашивающееся решение в виде цикла в котором по очереди передаешь ОДНО значение?

Ну, разбиваешь строку на элементы в тот же массив, потом цикл по массиву и вызов метода, куда в качестве параметра передаешь значение очередного элемента массива.

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

[Prophetic]

Цитата:

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

А почему не сделать напрашивающееся решение в виде цикла в котором по очереди передаешь ОДНО значение?

Ну, разбиваешь строку на элементы в тот же массив, потом цикл по массиву и вызов метода, куда в качестве параметра передаешь значение очередного элемента массива.

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

Gustav предложил отличное решение, которое полностью решило мою проблему. Если писать "с нуля", то конечно же, Query гораздо правильнее. В этом случае мне просто не хотелось менять уже существующий код.

[S.Kuskov]

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

static void Job_SQL_IN(Args _args)
{
    #LOCALMACRO.sqlIn
    (
    ((%3 <= 1) && (%1 == %2[1])) ||
    ((%3 <= 2) && (%1 == %2[2])) ||
    ((%3 <= 3) && (%1 == %2[3])) ||
    ((%3 <= 4) && (%1 == %2[4])) ||
    ((%3 <= 5) && (%1 == %2[5])) ||
    ((%3 <= 6) && (%1 == %2[6])) ||
    ((%3 <= 7) && (%1 == %2[7])) ||
    ((%3 <= 8) && (%1 == %2[8])) ||
    ((%3 <= 9) && (%1 == %2[9])) ||
    ((%3 <= 10) && (%1 == %2[10]))
    )
    #ENDMACRO

    custInvoiceTrans custInvoiceTrans;
    InventDim InventDim;
    inventLocationId inventLocationId;
    container inventLocationCon;
    int n;
    inventLocationId inventLocationArr[10];
    ;

//    inventLocationId = ...; 
    inventLocationCon = str2con_RU(inventLocationId, ',');

    for (n = 1; n <= conlen(inventLocationCon); n++)
    {
        inventLocationArr[n] = conpeek(inventLocationCon, n);
    }
    n--;

    while select custInvoiceTrans where custInvoiceTrans.InvoiceDate == 01\04\2010
    join InventDim
        where inventDim.inventDimId == CustInvoiceTrans.InventDimId &&
              #sqlIn(inventDim.InventLocationId, inventLocationArr, n)
    {
       //...
    }
}

P.S.: А вообще всё это извращения какие-то. Везде где это возможно лучше используйте Query.

[Gustav]

В общем, компилятор обижается, когда параметром макроса выступает переменная конкретного "плохого" типа (контейнер или безразмерная строка). Если же переменную заменить на вызов функции, пусть даже и возвращающей "плохой" тип, то всё получается:

static void test_SQL_Imitation_3(Args _args)
{
    #macrolib.SQL_Imitation

    InventLocation  inventLocation;

    container c = ['СКЛАД1','СКЛАД2','СКЛАДN']; // не работает

    container c() // работает
    {
        return ['СКЛАД1','СКЛАД2','СКЛАДN'];
    }
    ;

    while select inventLocation
        //where #sqlIn( inventLocation.InventLocationId, c   ) // не работает
          where #sqlIn( inventLocation.InventLocationId, c() ) // работает
    {
        info (inventLocation.InventLocationId);
    }
}

[Prophetic]

Цитата:

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

Позволю себе немного модифицировать макрос SqlIn. Идея таже, но реализация не через контейнер, а через масив. Плюс ещё добавлена проверка выхода за границы масива.
P.S.: А вообще всё это извращения какие-то. Везде где это возможно лучше используйте Query.

Тоже неплохо, благодарю. Согласен, что извращения, но все же иногда надо.

[vallys]

Все-таки чтобы избежать в запросе что-то типа

PHP код:

... or InventLocationId = ' ' or InventLocationId = ' ' or InventLocationId = ' ' or ... 


желательно проверять значение с которым сравнивается поле, например так

    #LOCALMACRO.sqlIn
        (  (conpeek(%2, 1) && %1 == conpeek(%2, 1))
        || (conpeek(%2, 2) && %1 == conpeek(%2, 2))
        || (conpeek(%2, 3) && %1 == conpeek(%2, 3))
        || (conpeek(%2, 4) && %1 == conpeek(%2, 4))
        || (conpeek(%2, 5) && %1 == conpeek(%2, 5))
        || (conpeek(%2, 6) && %1 == conpeek(%2, 6))
        || (conpeek(%2, 7) && %1 == conpeek(%2, 7))
        || (conpeek(%2, 8) && %1 == conpeek(%2, 8))
        || (conpeek(%2, 9) && %1 == conpeek(%2, 9))
        || (conpeek(%2, 10) && %1 == conpeek(%2,10))
        )
    #ENDMACRO

P.S. К тому же для числовых полей без аналогичной проверки могут подхватиться нули...