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

[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?