можно-ли средствами абап реализовать отбор последовательности 100 записей начиная с некоторой (для нее задан первичный ключ)

например, чтото вроде такого:

select TOP 100 MATNR from MARA
where MARA~MATNR >= 'некий_начальный_номер'.

таблица уже упорядочена по MATNR, т.к. это первичный ключ - т.е. использовать >= вполне допустимо
а вот как TOP n записей реализовать?

Или можно попробовать:
http://help.sap.com/saphelp_47x200/help ... ameset.htm

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

data: C1 TYPE CURSOR,
N TYPE I,
WA LIKE MARA,
ZAP LIKE MARA OCCURS 0 WITH HEADER LINE.

I = 100.

OPEN CURSOR C1 FOR SELECT * from MARA WHERE .......
DO N TIMES.
FETCH NEXT CURSOR C1 INTO WA.
IF SY-SUBRC NE 0.
EXIT.
ELSE.
APPEND WA TO ZAP.
ENDIF.
ENDDO.

По-моему, всё немного попроще.

Так и есть
tables: mara.
DATA: T_MARA TYPE TABLE OF MARA,
MAX_ROWS TYPE I VALUE 100.
SELECT * INTO TABLE T_MARA FROM MARA UP TO MAX_ROWS ROWS
WHERE MATNR >= 'некий_начальный_номер' ORDER BY MATNR.

спасибо всем ... про UP TO я и не догадался (всётаки синтаксис абап-sql'я довольно своеобразный)

наверно поняли уже - что пытаюст проскакать по всем материалам, но чтобы программа не подвисала надолго
в таблице около 100000 записей, и полный select выполняется очень долго, и юзер ессно не видит на экране результатов ... поэтому последующий loop (с выводом progressbar'а) появляется очень не скоро ... хочется чтобы скакало по таблице "кусками", т.е. считало первые 1000 записей, обработало, на экране пробежал progressbar, потом следующие 1000, снова progressbar, и т.д.

А вот это не лучшее решение, потому что увеличение числа запросов к БД ведёт к снижению производительности.

дык в противном случае юзеры волнуются ... думают что зависло, начинают звонить

да и вообще - неудобно (не видно, что в данный момент происходит)

Если на сто тысяч записей простой запрос заставляет волноваться юзеров, то у вас проблема с базисом. Или с юзерами . А если запрос сложный, то лучше разбить его на несколько и выводить "часики" после того, как отработает каждый из них.

а почему так не устраивает:

или слишком долго открывается курсор?

Согласен с предыдущим высказыванием
Почему не делать:
- select cnt(*) into nReccount
- select where
...
progress-bar через n строк с процентом выполнения относительно nReccount
...
endselect
и юзерам понравится НО тормоза с точки зрения производит-сти

А вообще быстрее будет через select во внутреннюю табличку с последующим лупом и теми-же часиками...

выборки из реляционной БД 100 000 записей для диалоговых программ - безумие!!
что-то у вас с постановкой не так.

Что касается проблем сбазисом, то, господа, выборка конечно происходит быстро, только вот результат надо передать по сети, отобразить в gui. Если для отображения используется alv, уверяю вас, что время обработки gui будет существенно выше времени обработки запроса (в данном простейшем случае при примитивной выборке из mara)

Однозначно так. Только "часики" в этом случае будут уже ни к чему .

Ну да 100000 в диалоге просмотреть это надо очень быть усидчивым человеком... А по поводу часиков, лучше вообще стараться не выводить лишний раз, они диалоговый процесс блокируют-с и производительность нескоко падает из-за этой красивости... Можете попробовать в том же:

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

Если у них такой отчет не слетает по max_wprun_time, то пущай любуются Навряд ли юзеров будут интересовать все записи. Ну а вообще, нужно приучать их большие отчеты запускать в фоне.