Есть такой селект:

SELECT
TAB_1~f1
TAB_2~g1
TAB_2~g2
TAB_2~g3
TAB_3~s1
INTO (rf1, rg1, rg1, rg1, rs1)
FROM ZDTAB_1 AS TAB_1
JOIN ZDTAB_2 AS TAB_2
ON TAB_1~f1 = TAB_2~g4
LEFT JOIN ZDTAB_3 AS TAB_3
ON TAB_3~s2 = TAB_2~g3

WHERE TAB_1~f2 like '2008%' AND
TAB_3~s1 <> SPACE
.

ENDSELECT.

Ошибка:
No fields from the right-hand table of a LEFT OUTER JOIN may appear in
the WHERE condition: "TAB_3~s1".

Подскажите в чем проблема

Вы хотите воспользоваться внешним левым соединением с таблицей TAB_3. Это означает, что при соединении в этой таблице могут оказаться пустые записи, поэтому система запрещает использовать поля в условиях. Если хотите отфильтровать именно те записи, где будет не пусто (судя по условию), то соедините TAB_3 через INNER JOIN.

Я так и предполагал. Но INNER JOIN мне подходит так как:
Table 1 Table 2
|----|----|----|----| |----|----|----|----|----|
| A | B | C | D | | D | E | F | G | H |
|----|----|----|----| |----|----|----|----|----|
| a1 | b1 | c1 | 1 | | 1 | e1 | f1 | g1 | h1 |
| a2 | b2 | c2 | 1 | | 3 | e2 | f2 | g2 | h2 |
| a3 | b3 | c3 | 2 | | 4 | e3 | f3 | g3 | h3 |
| a4 | b4 | c4 | 3 | |----|----|----|----|----|
|----|----|----|----|

\ /
\ /
\ /
\ /
\/
Inner Join
|----|----|----|----|----|----|----|----|----|
| A | B | C | D | D | E | F | G | H |
|----|----|----|----|----|----|----|----|----|
| a1 | b1 | c1 | 1 | 1 | e1 | f1 | g1 | h1 |
| a2 | b2 | c2 | 1 | 1 | e1 | f1 | g1 | h1 |
| a4 | b4 | c4 | 3 | 3 | e2 | f2 | g2 | h2 |
|----|----|----|----|----|----|----|----|----|

Если оно не найдет строку в TAB_3, то не получится строки соединения TAB_1<->TAB_2? (по которой искалось TAB_3).
А мне надо TAB_1<->TAB_2 хоть и строка TAB_3 будет пуста.

А TAB_3 это к примеру документ, он есть но поле у него пустое, тогда мне эта строка не нужна.

воспользуйтесь OpenSQL, там такой запрос прокатит

А это ли не OpenSQL?
Может Native Вы имели в виду?

ненене, нужно просто вынести t3 <> space из запроса

Действительно, извиняюсь
понедельник ))

Ну так из сообщения же ясно видно, в чем проблема. Если вы присоединяете таблицу с помощью LEFT JOIN (т.е. у вас это ZDTAB_3), то никакие поля из нее не могут фигурировать в WHERE. Т.е. ваша конструкция синтактически неправильна. Это известная засада с LEFT JOIN, лечится примерно следующим:

1) оставляем LEFT JOIN, убираем WHERE, а потом удаляем ненужные записи в полученной таблице;
2) разбиваем на два отдельных SELECT;
3) иногда можно использовать subquery (посмотрите Help на SELECT WHERE), правда с этим надо осторожно.

В общем возможны варианты, в зависимости от того, какого результата вы хотите добиться.

P.S. Кстати, давать aliases (ZDTAB_1 AS TAB_1) совершенно не обязательно, если таблица используется в JOIN один раз. Я тоже это всегда делала по началу (ну в Help же написано! ), а потом доперло, что можно просто писать, например ZDTAB_1~F1. Так гораздо проще разбираться, что, куда и откуда. Чистое IMHO, конечно, работать будет и так и так.

Успехов!

С точки зрения оптимизации запроса(уменьшения его времени работы) первые два варианта не подходят. Все таблицы имеют >= 250 000 записей и выбрасывать какое-то условия, чревато увеличением времени отработки запроса. А по поводу 3-го пункта нужно посмотреть, но врятли я его буду применять.

Я конечно не гуру в оптимизации, но первые два варианта работают достаточно быстро, проверьте. Лично мне милее 1 вариант.
Jelena +1, subquery интересная вещь, почему раньше не использовал

subquery - зло

Ну это как посмотреть...
1.Если удаляемое условие идет по полю, не входящему в индекс, то время обработки запроса увеличится только за счет бОльшего количества выбираемых записей.
2.Если вообще убрать left join, то сократится нагрузка на оптимизатор и сервер БД, но придется делать отдельный запрос по zdtab_3 по данным внутренней таблицы.
Тут все зависит от количества записей в zdtab_3 - если их мало, то легче выбирать эти записи по одной в цикле и сохранять в сортированной таблице, если много - лучше использовать for all entries по всем записям внутренней таблицы.

Не нужно забывать, что R/3 - это 3-х звенная архитектура и не нужно всю работу по выборке и обработке данных перекладывать на сервер БД.

Наглядный пример выборки по 3-м большим таблицам - связка ANLA, ANLU и ANLZ:
выделение ANLU из связки по left join в отдельную выборку сократило время выполнения отчета на 30%

Ну, в таком случае наверное имеет место, пардон, ситуация "как не ложись - все равно отымеют". Кстати, раз уж таблицы Z, то может вообще надо бы их дизайн пересмотреть?

Особенно актуален пересмотр дизайна таблицы > 250к записей
Прошу прощения за офтоп - очень ветка понравилась ))
Jelena, спасибо за
[/quote]

А никто не знает, почему такое ограничение? В других реализациях SQL вроде бы такого нет.
Т.е. есть ли некий практически разумный смысл в этом ограничениии или просто так исторически сложилось?