Задача состоит в том что необходимо для персоны (из администрирования персонала ) собрать атрибуты штатной должности (OTYPE = 'S' ) .

Если Вы знаете альтернативу, прошу вас ею поделиться.

Персона - это объект типа 'P' в оргменеджменте. Хранится в табл. HRP1000. Соеденение между объектами хранится в таблице HRP1001. Вообще всё это есть в соответствующем курсе (hr350)

Можно использовать UP TO n ROWS.

Это понятно, самый простой пример, если надо отобрать людей по разделу персонала PA0001-WERKS = '1000' .

Можно пойти другим путём, найти все объекты типа "О" в инфотипе 1008-PERSA = '1000' , потом найти для этих объектов штатные должности , а потом и людей ...

Но не проще ли ,если отчет по людям и всей информации относительно людей, найти людей, а информацию о штат. долж. подтянуть ?

делал я SELECT SINGLE всё отработало очень быстро , используется индекс Pa0001~Z (это я уже лично создавал) и HRP1001~0 .

Только почему это надо делать одним запросом? Что мешает воспользоваться, например, конструкцией for all entries, предварительно выбрав тн для завода ???

ЗЫ: и не забудьте осле всех селектов проверить полномотия на табельный номер и структурные полномочия.

Вы хотите сказать что конструкция SELECT ... FROM X INNER JOIN Y
в корень не правильна ?
А более верным вариантом является FOR ALL enteries X ?

М.б. попробовать пойти от обратного воспользоваться ЛБД PNPCE(PNP) для отбора людей по ряду критериев (тот же раздел персонала). А уже затем считывать атрибуты штатной должности (RH_READ_INFTY или RH_OBJECT_READ, в зависимости от того, что Вам надо)?

Выяснилась такая ситуация :
Уже в пробном режиме заменил таблицу PA0001 на таблицу PA0000, а потом на PA0002, так вот с этими таблицами запрос выполнился буквально за 1сек и выборка составила 130 000 зап .
Эту ситуацию описал базису, базис отправил проблему консультанту , тот выполнил запрос с таблицей в SQL+ и у него тоже вышло время около 1 сек.
Выходит что на уровне SAPa происходит что-то очень странное ...

Может у кого-то была такая ситуация ???

Человек е хочет от от обратного, человек хочет всё одним запросом - и табельные номера, и штатную долхность, и орг.единицу (хотя непонятно зачем, если используется P0001-PLANS, то почему-бы не воспользоваться P0001-ORGEH?).

Запрос из самого первого поста просто не может выполняться при замене pa0001 на pa0000 или pa0002 - в этих таблицах как минимум отсутствует поле PLANS - тогда о каких запросах идёт речь?

Прошу прощение за не полное предоставление данных .
На данный момент было принято решение вообще отказаться от усломия Where , и упростить его до тестового варианта , чтобы понять почему с одной таблицей скорость выполнения 1 сек, а с PA0001 1000 записей = 60 сек.

Ну и в этом запросе меняли PA0001 на PA0000 PA0002.

Кстати, да, и такое может быть - попробуйте поискать в нотах для PA0001 - может найдётся похожая проблема.

Сравнили анализ выполнения запроса с таблицами PA0001 & PA0002 через ST05 видимыъ отличей не наблюдается кому интересно могу выслать архив с скриншотами !

Есть какой-то маленький затык , а я его не вижу ...

интересно - чем же дело закончилось? (люблю оптимизировать =D)