Вопрос на засыпку - что делает этот код? (все переменные - типа CHAR).

А всего-то юноша не знал оператора SPLIT...

Да уж...
Предлагаю в этот топик писать подобные примеры. Я думаю начинающих это спасет от некоторых подобных ошибок.

Вы бы посмотрели какие я выдумывал конструкции, когда не знал операторов

at end of...
at new ...
и т.д.
Вобщем на ветвлениях if собаку съел. Благо это было более 4-х лет назад и никто не помнит

Не такие уж они и "хорошие" эти операторы.
Помню наткнулся на такую ситуацию с at new ... , которую отлавливал долгенько. Правда вот забыл в чем там дело было, но для себя решил польоваться ими поаккуратнее.

Там вроде проблемы возникают если к примеру предыдущее поле таблицы не содержит ( или почти) данных ...
Если не прав поправьте...

Там вроде проблемы возникают если к примеру предыдущее поле таблицы не содержит ( или почти) данных ...
Если не прав поправьте...

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

Не очень хорошая идея, так как эффект может быть совсем противоположный - начинающие, особенно взявшие на вооружение технологию "copypaste", будут копировать эти "не правильные" примеры себе в программы.

Ну уж вы, батенька, совсем плохого мнения о молодежи...

P.S. А мы им на каждый неправильный пример, три правильных писать будем.

нормальные операторы... просто хелп надо читать не по диагонали
P.S. На грабли c этими операторами тоже наступал, сгоряча списал все на 'баги проклятого САПа', сделал все по другому, а потом уже понял что это за операторы и как ими пользоваться

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

Показательно, кстати, что во многих случаях в саповских текстах не используется AT NEW, AT END, там, где, казалось бы, можно было их использовать.

А тот пример, который я вначале привел, это не просто случайное вкрапление.. судя по текстам, человек давно и осознанно таким образом строки делит... Copy-paste, кстати, он тоже очень хорошо освоил, использует его везде вместо подпрограмм - получается весьма "прогрессивно" Лень и халтура..

У меня такое подозрение что когда то этот оператор задумывался для строго определенной цели. Правда для какой именно - Вальдорф его знает

Я встречал талантов которые писали
1. отчет одним куском начиная с loop и..... пару тысяч строк... endloop.
2. тоже самое тока в ФМ
3. тоже самое тока в отдельном include
4. программа в несколько тысяч строк написана одними макросами(!)
5. перформы по 500 строк ....
6. программа начинается с CASE идет .... 500 строк... ENDCASE
и.т.д.....

Жуть...!

Пользуюсь иногда таким приемом, как создание вторичного индекса к внутренней таблице:

Раз уж всех не оставил равнодушными мой топик про at new ... и т.д., не могу оставаться в стороне.
Дело в том, что SAP сделал эти операторы единственно правильным методом. Вообще кто-нибудь может сказать хоть одно неудобство, кроме того что таблица должна иметь определенныю структуру.

Да и это ограничение, кстати бывает очень удобным. Конечно не знаю точно, но думаю это сделано затем чтобы:
1. Не раскладывать по полям внутреннюю таблицу, а сразу влоб взять с... и по... - отсюда скорость
2. Представляете синтаксис при многоуровневой группировке?... Это же надо было бы каждое поле каждый раз писать (примерно так: если изменилось поле .... и поле .... и поле ...., а вот поле .... не изменилось и поле .... тоже не изменилось - вот это уже проблема )