Подскажите с запросом в Х++

[3oppo]

Есть запрос :

Select payTrans where
. . . . .
&& payTrans.Emplid == nameEmplList

дело в том что
nameEmplList - это список через запятую ( 123,543,678,812,453 ) причём длинна этого списка не известна. Перебор по списку сотрудников. Вопрос как правильно это сделать в Х++ запросе?!

Делать вне запроса не хочется, будет долго.
Необходимо реализовать подобие функции Charindex() в SQL.

[Roman777]

Скорее это нужно делать через конструктор запросов в x++, а диапазон задать, добавив range по EmplId:

    QueryBuildRange             qr;
    ;
    ...
    
    qr.value(sysQuery::value(nameEmplList));

[George Nordic]

Сделать временную таблицу, заполнить её списком и заджойнить.

С Уважением,
Георгий

[Peter Savintsev]

Вот более полный вариант примера, приведенного Roman777

Query q;
QueryBuildDataSource qbds;
QueryBuildRange qbr;
QueryRun qr;
RPayTrans payTrans;

q = new Query();
qbds = q.addDataSource(tablenum(RPayTrans));
qbr = qbds.addRange(fieldnum(RPayTrans, EmplId));
qbr.value(nameEmplList);

qr = new QueryRun(q);
while (qr.next())
{
    payTrans = qr.get(tablenum(RPayTrans));
    ...
}

Обратите внимание, что в вашем случае надо использовать именно qbr.value(nameEmplList), а не qbr.value(SysQuery::value(nameEmplList)), поскольку во втором случае список значений возьмется в кавычки и будет неправильно интерпретирован.

[Peter Savintsev]

Кстати, если вы формируете список сотрудников (т.е. значение переменной nameEmplList) в цикле, то предыдущий пример можно сделать несколько иначе:

Query q;
QueryBuildDataSource qbds;
QueryBuildRange qbr;
QueryRun qr;
RPayTrans payTrans;
EmplTable emplTable;

q = new Query();
qbds = q.addDataSource(tablenum(RPayTrans));

while select emplTable
    where ...
{
    qbr = qbds.addRange(fieldnum(RPayTrans, EmplId));
    qbr.value(SysQuery::value(emplTable.EmplId));
}

qr = new QueryRun(q);
while (qr.next())
{
    payTrans = qr.get(tablenum(RPayTrans));
    ...
}

[dn]

Цитата:

Сообщение от George Nordic

Сделать временную таблицу, заполнить её списком и заджойнить.

С временной таблицей - спорный вариант, с подводными камнями.
Через query - лучше!

Хотя в случае query есть ограничение на длину строки, подставляемой в range.
Но это можно обойти при помощи нескольких range на одно и то же поле. В этом случае они будут объединяться по ИЛИ.

Можно ещё конечно извратиться с макросом для обычного select (см. макрос InventDimJoin). В макрос передается динамически сгенерированное условие where на основе списка значений nameEmplList. Но макросы как-то обычно не рекомендуется использовать.

[Gustav]

Цитата:

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

С временной таблицей - спорный вариант, с подводными камнями.

Например?

[dn]

Цитата:

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

Например?

Подводные камни с временными таблицами не раз обсуждались:
join постоянной и временной таблиц
утечка RecId
производительность ...

[Gustav]

Цитата:

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

Подводные камни с временными таблицами не раз обсуждались:
join постоянной и временной таблиц
утечка RecId
производительность ...

Спасибо.

[Dron AKA andy]

Цитата:

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

Можно ещё конечно извратиться с макросом для обычного select (см. макрос InventDimJoin). В макрос передается динамически сгенерированное условие where на основе списка значений nameEmplList. Но макросы как-то обычно не рекомендуется использовать.

Ну вот, опять!
Проверка на передачу пустого параметра в макрос

Ну не передаются в макрос динамически (т.е. программно) сгенерированные вещи! Макросы используются только на этапе компиляции.

[dn]

Цитата:

Сообщение от Dron AKA andy

Ну не передаются в макрос динамически (т.е. программно) сгенерированные вещи! Макросы используются только на этапе компиляции.

Действительно погорячился, давно уже макросами не баловался :-)

Тогда ещё остается только runbuf

[Hezl]

Цитата:

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

С временной таблицей - спорный вариант, с подводными камнями.
Через query - лучше!

Хотя в случае query есть ограничение на длину строки, подставляемой в range.
Но это можно обойти при помощи нескольких range на одно и то же поле. В этом случае они будут объединяться по ИЛИ.

Через query лучше, если условий немного. А если будет порядка 2000 ограничений, то queryRun.next() будет падать, причем громко. Так что решение от задачи зависит.

[Gustav]

Цитата:

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

Хотя в случае query есть ограничение на длину строки, подставляемой в range.

Коллеги, а, кстати, какое? 250 символов? (255?) Или по каким-то другим параметрам ограничено, например, количеством... "элементов" (условий) в этой строке? Что-то нигде в явном виде не нашёл такой цифры, хотя действительно строка далеко не безгранична и крутится вокруг 250...

[Hezl]

Зависит от размера EDT Range.

[Gustav]

Цитата:

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

Зависит от размера EDT Range.

Ух ты, здорово! Спасибо! Действительно стоит StringSize = 250. Попробовал ввести размер StringSize = 10 000 - AOT ругнулся сообщением "Значение вне диапазона. Приемлемые значения в диапазоне 1 & 1000"... Может быть, где-то можно и верхнюю границу диапазона подкрутить?

P.S. Кстати, влияет ли размер этого EDT Range еще на что-нибудь? Критично ли? Почему по дефолту стоит 250, а не сразу максимально 1000?