SELECT ... ENDSELECT

nikolay1880

Сразу хочу оговориться, что вопрос скорее конструктивного-познавательность типа, чем практического, т.к. данную конструкцию запросов не использую, но часто встречаю в старых программах. Я кроме минусов данной конструкции ни чего не вижу положительного, отладка внутри select...endselect часто валится в дамп, время обращения к серверу увеличивается по сравнению с обычным select"ом + не оптимальные условия внутри конструкции, могут привести к еще большей задержке. Хотелось бы узнать какое либо преимущество данной конструкции перед обычным select"ом. Или это все таки атавизм который SAP продолжает поддерживать?
Спасибо.

ArmAnn

Ну например:
1. Вытащить только одну запись по не очень четко заданному условию, например бухгалтерский документ с максимальной датой проводки:

Code:

select * from bkpf up to 1 rows
  where ....
  order by budat descending.
endselect.

Понятно что это можно сделать без использования select...endselect, но так достаточно просто и наглядно

2. Обработка больших объемов данных, которые нет смысла целиком тащить во внутренние таблицы - например посчитать какую либо статистику, но запросом это сделать не получится - тогда select...endselect в сочетании с PACKAGE SIZE самое на мой взгляд подходящее решение

nikolay1880

ArmAnn написал:

2. Обработка больших объемов данных, которые нет смысла целиком тащить во внутренние таблицы - например посчитать какую либо статистику, но запросом это сделать не получится - тогда select...endselect в сочетании с PACKAGE SIZE самое на мой взгляд подходящее решение

А разве не проще сделать UPDATE?

ArmAnn

nikolay1880 написал(а):

ArmAnn написал:

2. Обработка больших объемов данных, которые нет смысла целиком тащить во внутренние таблицы - например посчитать какую либо статистику, но запросом это сделать не получится - тогда select...endselect в сочетании с PACKAGE SIZE самое на мой взгляд подходящее решение

А разве не проще сделать UPDATE?

Если возможно апдейтом - то конечно лучше апдейтом. Но бывает что нужно считать какой нибудь сложный показатель, алгоритм расчета которого вы в апдейт (или селект) не запихнете - вот тогда и пригождается select...endselect. Или вот как то видел - раз в месяц по HRным данным считали какую то статистику, причем за все предыдущие периоды. Статистика собиралась раз в месяц, запускалось фоновое задание на ночь - тут нет смысла исхищряться и придумывать сложные решения

MantiCore1977

nikolay1880 написал(а):

А разве не проще сделать UPDATE?

не уловил связь между UPDATE и SELECT ... ENDSELECT
в SELECT разве можно менять данные в БД?

вобще UPDATE в SAP коварная штука
в силу того, что полно дублирующих полей в связанных таблицах, можно так наапдэйтить :shock:

ArmAnn

MantiCore1977 написал:

не уловил связь между UPDATE и SELECT ... ENDSELECT

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

dump

SELECT ... ENDSELECT позволяет заполнить хеш или сортед вн.таблицы с уникальным ключом если записи в таблице БД не с уникальными значениями этих полей. Если использовать обычный SELECT into table то будет дамп - нарушения уникальности

troy

ArmAnn написал:

Вытащить только одну запись по не очень четко заданному условию

+1
для использования команд, которые не разрешены вместе с приставкой SINGLE,
например "UP TO 1 ROWS" + "FOR ALL ENTRIES IN"

Sergeant

А в чем сакральный смысл SINGLE по сравнению с UP TO 1 ROWS?
А UP TO 1 ROWS вроде разрешено вместе с FOR ALL ENTRIES IN.

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

troy

Sergeant написал(а):

А в чем сакральный смысл SINGLE по сравнению с UP TO 1 ROWS?
А UP TO 1 ROWS вроде разрешено вместе с FOR ALL ENTRIES IN.

В том что FOR ALL ENTRIES IN не разрешено вместе с SINGLE

Parazit

Еще удобно для отладки перед тем, как объединить в JOIN.

Sergeant

troy написал(а):

Sergeant написал(а):

А в чем сакральный смысл SINGLE по сравнению с UP TO 1 ROWS?
А UP TO 1 ROWS вроде разрешено вместе с FOR ALL ENTRIES IN.

В том что FOR ALL ENTRIES IN не разрешено вместе с SINGLE

Так я ведь и спрашиваю - в чем разница между SINGLE и UP TO 1 ROWS, которая вроде разрешена?
Может я не знаю чего.

ArmAnn

Sergeant написал(а):

Так я ведь и спрашиваю - в чем разница между SINGLE и UP TO 1 ROWS, которая вроде разрешена?
Может я не знаю чего.

select single чуть короче - у вас нет закрывающего endselect

По поводу разницы быстродействии/нагрузке на БД - ИМХО никакой разницы, select single можно просто считать упрощенной формой записи select ... up to 1 rows .... endselect

zsap

Если в условии where с select single не задан полный ключ таблицы, расширенная проверка выдает предупреждение и рекомендацию заменить конструкцию на UP TO 1 ROWS. Видимо select single предполагается применять когда вы точно уверены, что найдется не более одной строки, а UP TO 1 ROWS когда выбираете первую строку из множества

Cerber24

Удобно брать строки начиная с заданной:

Code:

  select * from ekko into corresponding fields of 
                                         ln_ekko up to upto rows
     where
               bedat in  s_edat.
    if sy-dbcnt > skip.                  "Для выборки с заданной записи
      append ln_ekko to lt_ekko.
    endif.
  endselect.

Правила форума

SELECT ... ENDSELECT

Кто сейчас на конференции