не могу поверить, не ужели в ABAP нельзя написать элементарный запрос на соединение 2-х таблиц стандартными способами?
вот так

SELECT a.* b.* FROM table1 a, table2 b WHERE a.id=b.id
???
Неужели только через JOIN?

А если 3 таблицы соеденять, так это вообще в ABAP будет вложенные JOIN?

Что касаемо Open SQL то - да.
Ну это только начало...

Ну а вообще, попробуй посмотреть в сторону Native SQL.
Может что-то там и понравится.

с теми ограничениями что там есть - навряд ли

Ну тогда остаётся только свыкаться с этой средой разработки. Хотя и на ABAP можно писать шедевры.

жаль...
придется свыкнуться с мыслью о недоступности простоты стандартного языка SQL-92

Вот, почитайте:
http://sapboard.ru/forum/viewtopic.php?t=17407

Спасибо, почитал... удручён...

Я то 5 лет под Oracle писал... теперь вы можете понять мое возмущение.

Почитай еще о том, как join в SAP'е работает на самом деле. Будет еще интереснее

и как он "на самом деле" работает?

а ракурс предварительно создавать не судьба ?

1. The first table is scanned.
2. The result is stored in a temporary results table.
3. The temporary results table is sorted by the join columns of the following join step.
4. The next table that still exists is scanned.
5. The existing temporary results table is joined with the new table.
6. The result is stored in a new temporary results table.
7. This temporary results table is sorted by the join columns of the following join step.
8. The old temporary results table is deleted.
9. If there are more tables, the procedure is repeated from step 4.

The last temporary results table is the results table that the user wants.

Это общее описание алгоритма join'а в СУБД.
SAP сам join'ы не делает.

А ограничения такие:

В СУБД, слава богу, JOIN'ы работают не так, как пишет SAP. Т.е. не только так .

Ну так. Однако SAP всегда использует sort merge join. О чем, собственно, и пишет в on-line help'е, который я цитировал. Что не есть хорошо, а очень даже наоборот.
Хотя тут я, возможно, неправ. Собственно это и была претензия к SAP join'ам. Если есть кому поправить/уточнить - буду рад.

Help читать все умеют. Да и разговор не про то.

UPD: про "не про то" я погорячился. В тему убогости open SQL как раз

К сожалению, не все.
Вот эта цитата
относится к SAP DB и представляет из себя абстрактное словесное описание того, как делается join. Никакого отношения к реализации алгоритма join'а, а тем более к SAP WebAS это не имеет.

Open SQL не диктует оптимизатору базы данных, какую стратегию использовать для join'ов. Запретить использовать hash join можно на уровне базиса в тр. DB17.

В хелпе об этом ни слова.

При чем здесь реализация алгоритма, если разговор о самом алгоритме?
Более того, это описание никак не может являться абстрактным, т.к. абсолютно не соответсвует действительности в 2 из 3 вариантов алгоритма.

Противоречия не наблюдаем?

Да, согласен, в хелпе по ABAP о JOIN'е ни слова, кроме общего алгоритма. Который, однако, более всего соответсвует sort merge join'у. Здесь же читаем - The join is performed in ABAP with a sort-merge-join logic.

Эти два факта позволили мне в свое время сделать вывод о явном указании оптимизатору СУБД использовать sort merge join.

Вот за DB17 спасибо. Щас гляну.

UPD: Глянул. Не понял каким образом можно запретить hash join. Там же, как я увидел, обработка сообщений DB'шных. Не более того.

UPD2: Глянул лучше. Да, таки можно. Однако хинт USE_MERGE никто не отменял. Эх, как бы планы выполнения СУБДшные глянуть...
Более того, в той системе, где я работаю HASH_JOIN_ENABLED стоит в FALSE. Что, опять таки, свидетельствует о моей возможной правоте.