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

[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 описал. Хотя я ее предпочитаю даже не столько с точки зрения производительности, сколько с точки зрения наглядности...