Выборка данных с последующим обновлением.

[Uukrul]

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

Код Виділити Розширити


DATA: BEGIN OF lt_int_file OCCURS 1,
    fld_1(18) TYPE c,
    fld_2(18) TYPE c,
    status(1) TYPE c,
END OF lt_int_file.

SELECT xxx.fld_1 zzz.fld_2 INTO CORRESPONDING FIELDS OF TABLE lt_int_file
FROM xxx
  JOIN zzzz
WHERE <разные ограничения>

* Далее делаем типа
UPDATE z_table
FROM TABLE lt_int_file.


Так вот, надо всем записям которые обновились для поля status например поставить значение 'U', т.е. в выборке такого поля нет, конструкции типа SELECT xxx.fld_1 zzz.fld_2 'U' as status INTO CORRESPONDING FIELDS OF TABLE lt_int_file, вроде как тоже нет, т.е. остается только пройтись

Код Виділити Розширити


LOOP AT lt_int_file.
  lt_int_file-status = 'U'.
  MODIFY lt_int_file.
ENDLOOP.

* И дальше уже
UPDATE z_table
FROM TABLE lt_int_file.

Или есть идеи как это можно сделать по другом? Просто не очень хочется проходиться по всей выборке после SELECT-а ???

[Dmitriy]

Код Виділити Розширити

  DATA: BEGIN OF lt_int_file OCCURS 1,
      fld_1(18) TYPE c,
      fld_2(18) TYPE c,
      status(1) TYPE c,
  END OF lt_int_file.
* В данном случае можно обойтись без INTO CORRESPONDING FIELDS,
* т.к. выбираемые поля во вн.табл. и выборке перечислены соответственно   
  SELECT xxx~fld_1 zzz~fld_2 INTO TABLE lt_int_file FROM xxx
    JOIN zzz ON (условия соединения)
    WHERE (разные ограничения).
Первое, что пришло на ум (возможно из-за неполного понимания всей задачи, стоящей "за кадром"): если мы проводим UPDATE dbtab из внутренней сразу всех записей без цикла, то не означает ли это, что установка поля status в строке ее эквивалента простому наличию строки? К тому же, лог, как я понял, не ведется...

[Паганель]

Код Виділити Розширити

  DATA: BEGIN OF lt_int_file OCCURS 1,
      fld_1(18) TYPE c,
      fld_2(18) TYPE c,
      status(1) TYPE c,
  END OF lt_int_file.
* В данном случае можно обойтись без INTO CORRESPONDING FIELDS,
* т.к. выбираемые поля во вн.табл. и выборке перечислены соответственно   
  SELECT xxx~fld_1 zzz~fld_2 INTO TABLE lt_int_file FROM xxx
    JOIN zzz ON (условия соединения)
    WHERE (разные ограничения).
Первое, что пришло на ум (возможно из-за неполного понимания всей задачи, стоящей "за кадром"): если мы проводим UPDATE dbtab из внутренней сразу всех записей без цикла, то не означает ли это, что установка поля status в строке ее эквивалента простому наличию строки? К тому же, лог, как я понял, не ведется...

Не очень понял, что ты написал.

Реально, задача стоит в том, что бы проапдейтить табличку выборкой с нее же + еще кое-какие данные, и + установить статус.

[Dmitriy]

Не очень понял, что ты написал.
Реально, задача стоит в том, что бы проапдейтить табличку выборкой с нее же + еще кое-какие данные, и + установить статус.

Если поле status есть в z_table, то пардон, значит неправильно понял подоплеку. Скорее всего только в цикле.
 

[Паганель]

пока так и сделал.

[Uukrul]

Если поле status есть в z_table, то пардон, значит неправильно понял подоплеку. Скорее всего только в цикле.

Дело в том что если в выборку попадает так скажем 10 000 000 записей, то в цикле получается очень долго, вот и искались мысли, а нельзя ли как-то например при апдейте указать начальное значение для одного из полей. Похоже нельзя и надо вообще искать какой-то другой метод для контроля обновившихся записей.

[Паганель]

Дело в том что если в выборку попадает так скажем 10 000 000 записей, то в цикле получается очень долго,

сделаем замер на реальных данных (джоб запускается в 10 утра)  ;)

[Uukrul]

сделаем замер на реальных данных (джоб запускается в 10 утра)  ;)

Да вообще-то это уже рабочий день полным ходом... какое нафиг утра  :D утра это часов в 5...

[Паганель]

Да вообще-то это уже рабочий день полным ходом... какое нафиг утра  :D утра это часов в 5...

Раньше  нельзя, еще не все данные есть.

За последнее время статистика (до изменений):
4.003
3.648
2.349
2.047
3.797
4.086
2.762
3.439
посмотрим завтра

[Uukrul]

4.003
3.648
2.349
2.047

А что это за цифры???

[Паганель]

sm37, продолжительность выполнения.

[Uukrul]

sm37, продолжительность выполнения.

Ну я бы замерял бы все таки время выборки и время выполнения LOOP AT. А так общее время выполнения, никак не корелируется с выборками.

[Паганель]

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

[Uukrul]

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

Да ну, меньше часа крутиться... это фигня еще  ;)

[Dmitriy]

Если сильно прижмет по быстродействию LOOP at ... assigning <> ... ENDLOOP, то сделайте табличку из 2-х ключевых полей: MANDT и STATUS, и вставьте туда 1 запись: MANDT = sy-mandt и STATUS = 'U'. Джоин - по манданту. Проверил - заполняется статус без цикла. ;)

[Uukrul]

TATUS, и вставьте туда 1 запись: MANDT = sy-mandt и STATUS = 'U'. Джоин - по манданту. Проверил - заполняется статус без цикла. ;)

Что-то я не понял мысли... можешь примером кода набросать?

[Dmitriy]

Что-то я не понял мысли... можешь примером кода набросать?

Код Виділити Розширити

DATA: BEGIN OF lt_int_file OCCURS 1,
      fld_1(18) TYPE c,
      fld_2(18) TYPE c,
      status(1) TYPE c,
  END OF lt_int_file.
  DATA: ls type yxxx. "Тип нашей таблички с одной записью или без оной.
  SELECT SINGLE * INTO ls FROM yxxx.
  IF SY-SUBRC <> 0.
    ls-mandt = sy-mandt.
    ls-status = 'U'.
    INSERT INTO yxxx VALUES ls.
    COMMIT WORK AND WAIT.
  ENDIF.
* В данном случае можно обойтись без INTO CORRESPONDING FIELDS,
* т.к. выбираемые поля во вн.табл. и выборке перечислены соответственно   
  SELECT xxx~fld_1 zzz~fld_2 yxxx~status INTO TABLE lt_int_file FROM xxx
    JOIN zzz ON (условия соединения)
    JOIN yxxx ON zzz~mandt = yxxx~mandt
    WHERE (разные ограничения).

[Uukrul]

Ага ясно... а в принципе это таки да мысль.. сделать JOIN с табилице, т.е. там статусов напримеру у меня 5 штук. Вставить эти статусы и джойнить их  стем статусом который нужен, автоматически заливаем требуемое значение статуса в нашу выборку и LOOP по таблице для установки статуса уже не нужен...

[Dmitriy]

Ага ясно... а в принципе это таки да мысль.. сделать JOIN с табилице, т.е. там статусов напримеру у меня 5 штук. Вставить эти статусы и джойнить их  стем статусом который нужен, автоматически заливаем требуемое значение статуса в нашу выборку и LOOP по таблице для установки статуса уже не нужен...

Ну про то, что целезообразно там все статусы завести я уже не стал писать. ;)

[Паганель]

1. Результат (запустил на выполнение перед отьездом с работы)
2.491 (правда данныех сейчас там мало, после всех обработок, лишнее данные удаляются), так что это не показатель, завтра, на реальных данных посмотрим.

Дима, по поводу LOOP at ... assigning <> ... ENDLOOP
2. Никак не привикну юзать данную конструкцию все постаринке
LOOP AT gt_sap_rest.
  gt_sap_rest-status = 2. " загруженно с магазина + расчитано в SAP
  MODIFY gt_sap_rest.
ENDLOOP.

3. Решение Димы, простое и оригинальное, как все гениальное  :), попробуемс ....
спасибо

[Dmitriy]

Дима, по поводу LOOP at ... assigning <> ... ENDLOOP
2. Никак не привикну юзать данную конструкцию все постаринке
LOOP AT gt_sap_rest.
  gt_sap_rest-status = 2. " загруженно с магазина + расчитано в SAP
  MODIFY gt_sap_rest.
ENDLOOP.

Код Виділити Розширити

FIELD-SYMBOLS: <fs> LIKE LINE of gt_sap_rest.
LOOP AT gt_sap_rest ASSIGNING <fs>.
  <fs>-status = '2'. " - с одинарными кавычками, т.к. поле символьное, хотя SAP не ругается " загруженно с магазина + расчитано в SAP
ENDLOOP.
Дает существенное ускорение цикла в котором строки вн. таблицы модифицируются (особенно при большом к-ве записей), пора привыкать.

[Uukrul]

Однако подтверждаю, и так провел небольшой тест, есть табличка MSEG, система тестовая записей  123 226, сделана программка следующего вида:

Код Виділити Розширити


REPORT  yuuk_test_select.

DATA: lt_mseg LIKE mseg OCCURS 1 WITH HEADER LINE,
      runtime_1 TYPE i,
      runtime_2 TYPE i,
      time_diff TYPE i.

FIELD-SYMBOLS: <fs> LIKE LINE OF lt_mseg.

SELECT * INTO TABLE lt_mseg
FROM mseg.

GET RUN TIME FIELD runtime_1.
LOOP AT lt_mseg.
  lt_mseg-bwart = '000'.
  MODIFY lt_mseg.
ENDLOOP.
GET RUN TIME FIELD runtime_2.
time_diff = runtime_2 - runtime_1.
WRITE: / time_diff.

GET RUN TIME FIELD runtime_1.
LOOP AT lt_mseg ASSIGNING <fs>.
  <fs>-bwart = '000'.
ENDLOOP.
GET RUN TIME FIELD runtime_2.
time_diff = runtime_2 - runtime_1.
WRITE: / time_diff.

Результат на экране, комментарии я так думаю излишние, разница в производительности даже не на лице  ;) в надцать раз практически, т.е.  192 580 миллисекунд против  12 172, кажется закрывают данный вопрос как нужно делать обновления внутренних таблиц.

PS: Данный пример так же вставлю в тему по оптимизации ABAP.

[Dmitriy]

Собственно, ждемс, что скажет нам завтра г-н Паганель, лишь бы не перепутал Южную Америку с Австралией и Н.Зеландией, или как там у автора было... Нужно просто сгенерить диалог ведения, для красоты в табличку БД yxxx добавить неключевое поле поле status_text с расшифровкой статуса типа "загруженно с магазина + расчитано в SAP", сгенерить диалог ведения и не париться с INSERT в нее в своей программе, сориентировав ответственных за ведение статусов (то бишь нашей небольшой таблички) при помощи соответствующей спецификации/инструкции:

Код Виділити Розширити

DATA: ls TYPE yxxx. "Тип нашей таблички с одной записью или без оной.
 SELECT SINGLE * INTO ls FROM yxxx.
 IF SY-SUBRC <> 0.
   ls-mandt = sy-mandt.
   ls-status = 'U'.
   INSERT INTO yxxx VALUES ls.
   COMMIT WORK AND WAIT.
 ENDIF.
А сразу же:
 

Код Виділити Розширити

SELECT xxx~fld_1 zzz~fld_2 yxxx~status INTO TABLE lt_int_file FROM xxx
   JOIN zzz ON (условия соединения)
   JOIN yxxx ON zzz~mandt = yxxx~mandt
   WHERE (разные ограничения)
   AND yxxx~status = 'нужный нам статус'.

[Uukrul]

Собственно, ждемс, что скажет нам завтра г-н Паганель, лишь бы не перепутал Южную Америку с Австралией и Н.Зеландией, или как там у автора было...

Ага, есть такое дело... но даже если он LOOP / ENDLOOP перепишет, это ему уже даст ускорение...  ;)

[Dmitriy]

Ага, есть такое дело... но даже если он LOOP / ENDLOOP перепишет, это ему уже даст ускорение...  ;)

Да, результат выигрыша в быстродействии для большого к-ва записей впечатляет.
2 Паганель: завтра, как доберусь до системы, отпишу про возможности работы с ФМ - генерирующим диалог ведения таблицы БД. Здесь будет: http://sapforum.biz/index.php/board,29.0.html.

P.S. А руки все про FIELD-SYMBOLS так и не доходят написать, охота нормальный пример просто оттестить... ::)

[Паганель]

....отпишу про возможности работы с ФМ - генерирующим диалог ведения таблицы БД...

А зачем использовать FM? Что бы не делать это ручками? Что-то не понял этой фразы.

Спасибо за советы, осталось 30 мин до запуска Джоба, попробую переделать все циклы на использование FIELD-SYMBOLS.

[Паганель]

с отделной табличкой не успеваю, а FIELD-SYMBOLS сделал.
так как у меня 2 loop"а, сделал один по класике, а другой с FIELD-SYMBOLS, сделал вывод лога времени. Сравнимс  :)

[Uukrul]

с отделной табличкой не успеваю, а FIELD-SYMBOLS сделал.
так как у меня 2 loop"а, сделал один по класике, а другой с FIELD-SYMBOLS, сделал вывод лога времени. Сравнимс  :)

Лог времени как получал?

[Паганель]

так как ты написал.

Код Виділити Розширити


GET RUN TIME FIELD runtime_1.
LOOP AT gt_rest.
  gt_rest-status = 2. " загруженно с магазина + расчитано в SAP
  MODIFY gt_rest.
ENDLOOP.
GET RUN TIME FIELD runtime_2.
time_diff = runtime_2 - runtime_1.
WRITE: /'LOOP AT gt_rest'.
WRITE: / time_diff.


[Uukrul]

так как ты написал.

ОК!

[Паганель]

ну имеем результаты:

LOOP AT gt_rest
   721.907         
FIELD-SYMBOLS     
    11.979       

Правда, для чистоты эксперимента  надо бы поменять местами (первый сделать FIELD-SYMBOLS а второй  LOOP ) так как объемы там разные

[Паганель]

Общий результат:
вчера     3.439
сегодня  3.095

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

[Uukrul]

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

Ну на LOOP  точно будет выигрыш в разы, но надо еще добавить табличку статусов и думаю общее время выполнения должно уменьшиться.

[Dmitriy]

Ну на LOOP  точно будет выигрыш в разы, но надо еще добавить табличку статусов и думаю общее время выполнения должно уменьшиться.

Табличку статусов по-любому нужно. А по поводу ФМ - нет под рукой системы, по счастливому стечению обстоятельств оказался сегодня выходным, поэтому здесь, и, как грится, на пальцах...
Генерится диалог ведения в течении нескольких секунд. Но это уже ТВОЯ ф-ция. Можно зайти на экран, раздвинуть колонки (эк меня понесло, после Legio ;D) и т.п., т.е. сделать все, как тебе удобно... ;D ;D ;D

[Паганель]

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

Это, как я понял, вроде обычного диалога введения, только как бы подконтрольней?

[Dmitriy]

Дима, так и не понял, о чем ты, ну будешь возле системы, раскажешь .....
Это, как я понял, вроде обычного диалога введения, только как бы подконтрольней?

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

Код Виділити Розширити

AT SELECTION-SCREEN.
* Вызов диалога ведения настроечной таблицы видов движения объектов НКС
  CASE sy-ucomm.
    WHEN 'FC01'.
      CALL FUNCTION 'VIEW_MAINTENANCE_CALL'
           EXPORTING
                action                       = 'S'
                view_name                    = 'ZRTC_CC'
           EXCEPTIONS
                client_reference             = 1
                foreign_lock                 = 2
                invalid_action               = 3
                no_clientindependent_auth    = 4
                no_database_function         = 5
                no_editor_function           = 6
                no_show_auth                 = 7
                no_tvdir_entry               = 8
                no_upd_auth                  = 9
                only_show_allowed            = 10
                system_failure               = 11
                unknown_field_in_dba_sellist = 12
                view_not_found               = 13
                OTHERS                       = 14.
      IF sy-subrc <> 0.
*       ошибка вызова диалога ведения
        MESSAGE e070(zunikr_001) WITH sy-subrc 'ZRTC_CASHFLOW_1'.
      ENDIF.
  ENDCASE.
К чему это бишь я? Да к тому, что на любом проекте можно создать прогу, у которой один входной параметр: view_name, и презентовать ее юзерам, а потом, создавать на нее проги (и транзакции на них) с оператором SUBMIT и подстановкой этого параметра view_name в зависимости от SY-TCODE. А дальше уже пизанты разнесут полномочия на твои транзакции.

[Паганель]

о, прикольно, аналог sm30 для пользователей  :)
Спасибо большое, так как прав обычно в продуктиве на sm30 нету, можно для себя использовать, скажем что бы настройки смотреть. 

[Dmitriy]

о, прикольно, аналог sm30 для пользователей  :)
Спасибо большое, так как прав обычно в продуктиве на sm30 нету, можно для себя использовать, скажем что бы настройки смотреть. 

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

[Паганель]

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

Или как массово перенести данные из одно таблички в другую, если их структура не идентична?
Есть что-то типа move corresponding для все таблички?

[Uukrul]

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

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

Или как массово перенести данные из одно таблички в другую, если их структура не идентична?
Есть что-то типа move corresponding для все таблички?

Ну вот именно и есть для этого move corresponding. А ты как хотел типа мувкорреспондинг но быстро?  ;)

[Паганель]

Ну вот именно и есть для этого move corresponding. А ты как хотел типа мувкорреспондинг но быстро?  ;)

Туплю с утра, так вроде работает, правда будет ли прирост скорости:

Код Виділити Розширити


TYPES: BEGIN OF gs_alvtab.
TYPES: celltab TYPE lvc_t_styl.
TYPES: colinfo TYPE lvc_t_scol.
        INCLUDE STRUCTURE mkol.
TYPES: mjahr LIKE mseg-mjahr.
......
TYPES: END OF gs_alvtab.

DATA: gt_alvtab TYPE STANDARD TABLE OF gs_alvtab WITH HEADER LINE.
DATA: ls_alvtab LIKE LINE OF gt_alvtab.

DATA: gt_mkol TYPE STANDARD TABLE OF mkol WITH HEADER LINE.


" Выбор Поставщ. Завода, Материала, и Текущего Остатка
  SELECT matnr werks lifnr SUM( slabs ) AS slabs
   INTO TABLE gt_mkol " Для быстроты выборки
   FROM mkol
   WHERE mkol~matnr IN so_matnr AND
         mkol~werks IN so_werks AND
         mkol~lifnr IN so_lifnr AND
         mkol~sobkz = 'K'
   GROUP BY matnr werks lifnr.

  MOVE-CORRESPONDING gt_mkol to gt_alvtab. " <<< ---- тут


[Паганель]

Еще один вопросик, что бы не плодить тем кучу.

Что-то не найду как обьявить FIELD-SYMBOLS для таблички которая обьявлена как TYPE STANDARD TABLE OF.

Код Виділити Розширити


DATA: gt_mkol TYPE STANDARD TABLE OF mkol WITH HEADER LINE.

FIELD-SYMBOLS <fs_mkol> TYPE LINE OF gt_mkol. " <--- так не дает обьявить


[Uukrul]

Туплю с утра, так вроде работает, правда будет ли прирост скорости:

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

[Паганель]

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

Ссори наверное не получится, в тестовой системе не достаточно данных что бы нормально что то проверить, а продуктив не чаще чем 1 раз в день 1 запрос .... притом проверенный без всяких дополнительных фич (типа вставок для тестирования скорости) такова теперь жизнь .... все надо сделать за один раз .....

[Паганель]

Тут вообще-то что то есть ..... только еще не разобрался ....

http://sapforum.biz/index.php/topic,430.msg2455.html#msg2455

пока вижу что может объявлять FIELD-SYMBOLS: <fs_mseg> TYPE ANY .

[Uukrul]

Ссори наверное не получится, в тестовой системе не достаточно данных что бы нормально что то проверить, а продуктив не чаще

Берешь MSEG и проверяешь, там данных наверное должно быть достаточно... тебе же скорость надо проверить, именно твоя таблица в данном случае не важна.

[Паганель]

а ну да ....

[Паганель]

Что-то туплю, может кто-то подскажет .....

Для оптимизации делаю следующее:

Код Виділити Розширити


"Вьюха z_mkpf_mseg mkpf + mseg
DATA: gt_mseg TYPE STANDARD TABLE OF z_mkpf_mseg WITH HEADER LINE.
SELECT
         werks AS werks budat AS budat  matnr AS matnr
         lifnr AS lifnr shkzg AS shkzg
         SUM( menge ) AS menge
    "APPENDING CORRESPONDING FIELDS OF TABLE gt_mseg
    APPENDING TABLE gt_mseg
    FROM mseg
    WHERE
      werks IN  so_werks  AND
      budat => so_budat-low  AND   "!!! (может быть просто >) ???
      matnr IN  so_matnr AND
      lifnr IN  so_lifnr  AND
      sobkz = 'K'
      GROUP BY werks budat matnr lifnr shkzg. " Может не группировать?

Чего то падает в дамп:DBIF_RSQL_INVALID_RSQL

[Паганель]

Что группировать нельзя?

[Uukrul]

Что группировать нельзя?

Ну вообще-то APPENDING TABLE gt_mseg а на входе у тебя DATA: gt_mseg TYPE STANDARD TABLE OF z_mkpf_mseg, как-то структурки не сходятся?!

[Паганель]

Не понял ....
Есть табличка обьявленая как DATA: gt_mseg TYPE STANDARD TABLE OF z_mkpf_mseg WITH HEADER LINE.
z_mkpf_mseg  - это ракурс, вьюха.

И есть выборка из этой вьюхи

Код Виділити Розширити


SELECT
         werks AS werks budat AS budat  matnr AS matnr
         lifnr AS lifnr shkzg AS shkzg
         SUM( menge ) AS menge
    "APPENDING CORRESPONDING FIELDS OF TABLE gt_mseg
    APPENDING TABLE gt_mseg
    FROM mseg
    WHERE
      werks IN  so_werks  AND
      budat => so_budat-low  AND   "!!! (может быть просто >) ???
      matnr IN  so_matnr AND
      lifnr IN  so_lifnr  AND
      sobkz = 'K'
      GROUP BY werks budat matnr lifnr shkzg.


Так вроде бы типы сходятся.

[Паганель]

Пробывал  и так:
DATA: gt_mseg like z_mkpf_mseg OCCURS 10000 WITH HEADER LINE.

[Uukrul]

Пробывал  и так:
DATA: gt_mseg like z_mkpf_mseg OCCURS 10000 WITH HEADER LINE.

Ну вообще-то я всегда думал что если SELECT * APPENDING TABLE <>, а вот если поля перечисляешь тогда, типа APPENDING CORRESPONDING FIELDS OF TABLE или у тебя в z_mkpf_mseg только поля которые ты указал:

Код Виділити Розширити

werks AS werks
budat AS budat 
matnr AS matnr
lifnr AS lifnr
shkzg AS shkzg
SUM( menge ) AS menge
В такой последовательности и других нет?

[Паганель]

Ну вообще-то я всегда думал что если SELECT * APPENDING TABLE <>, а вот если поля перечисляешь тогда, типа APPENDING CORRESPONDING FIELDS OF TABLE или у тебя в z_mkpf_mseg только поля которые ты указал:

Код Виділити Розширити

werks AS werks
budat AS budat  
matnr AS matnr
lifnr AS lifnr
shkzg AS shkzg
SUM( menge ) AS menge
В такой последовательности и других нет?

Есть и другие поля, просто что бы оптимизировать, я использую APPENDING TABLE.

[Uukrul]

Есть и другие поля, просто что бы оптимизировать, я использую APPENDING TABLE.

Ну посмотри что на выходе, для пары записей...

[Паганель]

Не понял, выборка валится сразу .....

Прийдется использовать INTO CORRESPONDING FIELDS OF TABLE
Хотя есть сомнения по поводу оптимальности такого кода.

[Uukrul]

Не понял, выборка валится сразу .....

Ну так типизация же нарушена... конечно оно валится.

[Паганель]

Я тут немного "покурил травы" котрую индусы предлагали, расслабился, и точно туплю.... мой запрос возвратит только werks, budat, matnr ... но никак не струтктуру   z_mkpf_mseg, оттого и валится

Ссори, туплю ...

[Martha]

Пробывал  и так:
DATA: gt_mseg like z_mkpf_mseg OCCURS 10000 WITH HEADER LINE.

Есть табличка обьявленая как DATA: gt_mseg TYPE STANDARD TABLE OF z_mkpf_mseg WITH HEADER LINE.


а в чем разница для таблицы в этих двух определениях?

[Uukrul]

Есть табличка обьявленая как DATA: gt_mseg TYPE STANDARD TABLE OF z_mkpf_mseg WITH HEADER LINE.

а в чем разница для таблицы в этих двух определениях?

Думаю что уже ни в чем... и со временем оно все перейдет на использование TYPE, просто это объявление если не ошибаюсь с версии 4.6 стало доступно, как и не обязательность использования циферки после OCCURS <n>, типа сейчас там ставишь 0 и всех делов, раньше это вроде как влияло на количество буферов открываемых для внутренней таблицы, что типа на прямую влияло на производительность работы с ней. Я по привычке ставлю там как бы для себя если 1, предполагаю, что тут данных будет не много, если 100 то так среднее, если 1000 или больше, то это значит, что-то будет глобальное выгребаться эту таблицу.

[Паганель]

Ну какая то разница все же есть:

LIKE  - можно использовать в том случае если есть структура, табличка и тд. которые определенные в словаре данных.

А TYPE STANDARD TABLE OF - можно использовать,  даже если тип (табличка, структура) не определена в словаре данных, т.е. вы прямо в коде объявляете тип, типа так:

Код Виділити Розширити

TYPES: BEGIN OF gs_outtab.
  TYPES: celltab TYPE lvc_t_styl.
  TYPES: colinfo TYPE lvc_t_scol.
  TYPES: sticon TYPE icon_d.
  "
  INCLUDE STRUCTURE msku.
  "
TYPES: END OF gs_outtab.

такое обьявление «пройдет», т.е. система допустит объявление:

Код Виділити Розширити

DATA: gt_outtab TYPE STANDARD TABLE OF gs_outtab WITH HEADER LINE.
DATA: ls_outtab LIKE LINE OF gt_outtab.

"А так нельзя

Код Виділити Розширити

DATA: gt_outtab1 LIKE gs_outtab OCCURS 0 WITH HEADER LINE.
DATA: ls_outtab1 LIKE LINE OF gt_outtab1.

[Uukrul]

Так LIKE это дословно переменная слева будет такая же как переменная справа, а в твоем случае ты объявил тип данных, а потом попытался сказать что переменная будет как... и ссылку на тип даешь, что не логично  ::)

[Паганель]

Так LIKE это дословно переменная слева будет такая же как переменная справа, а в твоем случае ты объявил тип данных, а потом попытался сказать что переменная будет как... и ссылку на тип даешь, что не логично  ::)

Ну да в этом и разница, что like - обьявление ссылкой на переменную, а TYPE STANDARD TABLE OF обьявление со ссылкой на тип.

Хотя ты наверное прав, судя по всему разницы нету...