Sapforum.Biz
Инструменты => ABAP - Инструментальные средства => Тема начата: Uukrul от Февраль 19, 2009, 02:15:59 pm
-
В общем есть запрос который выгребает данные во внутреннюю таблицу, например
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-а ???
-
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 в строке ее эквивалента простому наличию строки? К тому же, лог, как я понял, не ведется...
Не очень понял, что ты написал.
Реально, задача стоит в том, что бы проапдейтить табличку выборкой с нее же + еще кое-какие данные, и + установить статус.
-
Не очень понял, что ты написал.
Реально, задача стоит в том, что бы проапдейтить табличку выборкой с нее же + еще кое-какие данные, и + установить статус.
Если поле status есть в z_table, то пардон, значит неправильно понял подоплеку. Скорее всего только в цикле.
-
пока так и сделал.
-
Если поле status есть в z_table, то пардон, значит неправильно понял подоплеку. Скорее всего только в цикле.
Дело в том что если в выборку попадает так скажем 10 000 000 записей, то в цикле получается очень долго, вот и искались мысли, а нельзя ли как-то например при апдейте указать начальное значение для одного из полей. Похоже нельзя и надо вообще искать какой-то другой метод для контроля обновившихся записей.
-
Дело в том что если в выборку попадает так скажем 10 000 000 записей, то в цикле получается очень долго,
сделаем замер на реальных данных (джоб запускается в 10 утра) ;)
-
сделаем замер на реальных данных (джоб запускается в 10 утра) ;)
Да вообще-то это уже рабочий день полным ходом... какое нафиг утра :D утра это часов в 5...
-
Да вообще-то это уже рабочий день полным ходом... какое нафиг утра :D утра это часов в 5...
Раньше нельзя, еще не все данные есть.
За последнее время статистика (до изменений):
4.003
3.648
2.349
2.047
3.797
4.086
2.762
3.439
посмотрим завтра
-
4.003
3.648
2.349
2.047
А что это за цифры???
-
sm37, продолжительность выполнения.
-
sm37, продолжительность выполнения.
Ну я бы замерял бы все таки время выборки и время выполнения LOOP AT. А так общее время выполнения, никак не корелируется с выборками.
-
я просто посмотрю на сколько увеличилось время выполнения всей проги
-
я просто посмотрю на сколько увеличилось время выполнения всей проги
Да ну, меньше часа крутиться... это фигня еще ;)
-
Если сильно прижмет по быстродействию LOOP at ... assigning <> ... ENDLOOP, то сделайте табличку из 2-х ключевых полей: MANDT и STATUS, и вставьте туда 1 запись: MANDT = sy-mandt и STATUS = 'U'. Джоин - по манданту. Проверил - заполняется статус без цикла. ;)
-
TATUS, и вставьте туда 1 запись: MANDT = sy-mandt и STATUS = 'U'. Джоин - по манданту. Проверил - заполняется статус без цикла. ;)
Что-то я не понял мысли... можешь примером кода набросать?
-
Что-то я не понял мысли... можешь примером кода набросать?
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 (разные ограничения).
-
Ага ясно... а в принципе это таки да мысль.. сделать JOIN с табилице, т.е. там статусов напримеру у меня 5 штук. Вставить эти статусы и джойнить их стем статусом который нужен, автоматически заливаем требуемое значение статуса в нашу выборку и LOOP по таблице для установки статуса уже не нужен...
-
Ага ясно... а в принципе это таки да мысль.. сделать 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. Решение Димы, простое и оригинальное, как все гениальное :), попробуемс ....
спасибо
-
Дима, по поводу 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.
Дает существенное ускорение цикла в котором строки вн. таблицы модифицируются (особенно при большом к-ве записей), пора привыкать.
-
Однако подтверждаю, и так провел небольшой тест, есть табличка 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.
-
Собственно, ждемс, что скажет нам завтра г-н Паганель, лишь бы не перепутал Южную Америку с Австралией и Н.Зеландией, или как там у автора было... Нужно просто сгенерить диалог ведения, для красоты в табличку БД 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 = 'нужный нам статус'.
-
Собственно, ждемс, что скажет нам завтра г-н Паганель, лишь бы не перепутал Южную Америку с Австралией и Н.Зеландией, или как там у автора было...
Ага, есть такое дело... но даже если он LOOP / ENDLOOP перепишет, это ему уже даст ускорение... ;)
-
Ага, есть такое дело... но даже если он LOOP / ENDLOOP перепишет, это ему уже даст ускорение... ;)
Да, результат выигрыша в быстродействии для большого к-ва записей впечатляет.
2 Паганель: завтра, как доберусь до системы, отпишу про возможности работы с ФМ - генерирующим диалог ведения таблицы БД. Здесь будет: http://sapforum.biz/index.php/board,29.0.html (http://sapforum.biz/index.php/board,29.0.html).
P.S. А руки все про FIELD-SYMBOLS так и не доходят написать, охота нормальный пример просто оттестить... ::)
-
....отпишу про возможности работы с ФМ - генерирующим диалог ведения таблицы БД...
А зачем использовать FM? Что бы не делать это ручками? Что-то не понял этой фразы.
Спасибо за советы, осталось 30 мин до запуска Джоба, попробую переделать все циклы на использование FIELD-SYMBOLS.
-
с отделной табличкой не успеваю, а FIELD-SYMBOLS сделал.
так как у меня 2 loop"а, сделал один по класике, а другой с FIELD-SYMBOLS, сделал вывод лога времени. Сравнимс :)
-
с отделной табличкой не успеваю, а 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.
-
так как ты написал.
ОК!
-
ну имеем результаты:
LOOP AT gt_rest
721.907
FIELD-SYMBOLS
11.979
Правда, для чистоты эксперимента надо бы поменять местами (первый сделать FIELD-SYMBOLS а второй LOOP ) так как объемы там разные
-
Общий результат:
вчера 3.439
сегодня 3.095
Но есть несколько "но", видимо данных сегодня было менше, или загрузка системы поменьше, так как по идее оба добавленных цикла, должны были увеличить время работы джоба.
-
Но есть несколько "но", видимо данных сегодня было менше, или загрузка системы поменьше, так как по идее оба добавленных цикла, должны были увеличить время работы джоба.
Ну на LOOP точно будет выигрыш в разы, но надо еще добавить табличку статусов и думаю общее время выполнения должно уменьшиться.
-
Ну на LOOP точно будет выигрыш в разы, но надо еще добавить табличку статусов и думаю общее время выполнения должно уменьшиться.
Табличку статусов по-любому нужно. А по поводу ФМ - нет под рукой системы, по счастливому стечению обстоятельств оказался сегодня выходным, поэтому здесь, и, как грится, на пальцах...
Генерится диалог ведения в течении нескольких секунд. Но это уже ТВОЯ ф-ция. Можно зайти на экран, раздвинуть колонки (эк меня понесло, после Legio ;D) и т.п., т.е. сделать все, как тебе удобно... ;D ;D ;D
-
Дима, так и не понял, о чем ты, ну будешь возле системы, раскажешь .....
Это, как я понял, вроде обычного диалога введения, только как бы подконтрольней?
-
Дима, так и не понял, о чем ты, ну будешь возле системы, раскажешь .....
Это, как я понял, вроде обычного диалога введения, только как бы подконтрольней?
Часть кода из проги, по программному вызову диалога ведения 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 нету, можно для себя использовать, скажем что бы настройки смотреть.
-
о, прикольно, аналог sm30 для пользователей :)
Спасибо большое, так как прав обычно в продуктиве на sm30 нету, можно для себя использовать, скажем что бы настройки смотреть.
И не нужно ничего бояться: максимум, что могут с тобой сделать - это убийство с предварительными многочасовыми мучениями, а потом - другая жизнь. ;)
-
Дополнительный вопрос: будет ли ускорение при использовании FIELD-SYMBOLS, если не проводится модификации таблички, только копирование в другую.
Или как массово перенести данные из одно таблички в другую, если их структура не идентична?
Есть что-то типа move corresponding для все таблички?
-
Дополнительный вопрос: будет ли ускорение при использовании 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. " <--- так не дает обьявить
-
Туплю с утра, так вроде работает, правда будет ли прирост скорости:
Ну мне тоже интересно будет ли прирост, как считать время выполнения есть в ветке про оптимизацию абапа, предлагаю в качество домашнего задания замерять время выполнения двух вариантов по 10 прогонов, на каждый и дописать пример в ветку про оптимизацию.
-
Ну мне тоже интересно будет ли прирост, как считать время выполнения есть в ветке про оптимизацию абапа, предлагаю в качество домашнего задания замерять время выполнения двух вариантов по 10 прогонов, на каждый и дописать пример в ветку про оптимизацию.
Ссори наверное не получится, в тестовой системе не достаточно данных что бы нормально что то проверить, а продуктив не чаще чем 1 раз в день 1 запрос .... притом проверенный без всяких дополнительных фич (типа вставок для тестирования скорости) такова теперь жизнь .... все надо сделать за один раз .....
-
Тут вообще-то что то есть ..... только еще не разобрался ....
http://sapforum.biz/index.php/topic,430.msg2455.html#msg2455 (http://sapforum.biz/index.php/topic,430.msg2455.html#msg2455)
пока вижу что может объявлять FIELD-SYMBOLS: <fs_mseg> TYPE ANY .
-
Ссори наверное не получится, в тестовой системе не достаточно данных что бы нормально что то проверить, а продуктив не чаще
Берешь 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
-
Что группировать нельзя?
-
Что группировать нельзя?
Ну вообще-то 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.
-
Пробывал и так:
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.
-
Есть и другие поля, просто что бы оптимизировать, я использую APPENDING TABLE.
Ну посмотри что на выходе, для пары записей...
-
Не понял, выборка валится сразу .....
Прийдется использовать INTO CORRESPONDING FIELDS OF TABLE
Хотя есть сомнения по поводу оптимальности такого кода.
-
Не понял, выборка валится сразу .....
Ну так типизация же нарушена... конечно оно валится.
-
Я тут немного "покурил травы" котрую индусы предлагали, расслабился, и точно туплю.... мой запрос возвратит только werks, budat, matnr ... но никак не струтктуру z_mkpf_mseg, оттого и валится
Ссори, туплю ...
-
Пробывал и так:
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.
а в чем разница для таблицы в этих двух определениях?
-
Есть табличка обьявленая как 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.
-
Так LIKE это дословно переменная слева будет такая же как переменная справа, а в твоем случае ты объявил тип данных, а потом попытался сказать что переменная будет как... и ссылку на тип даешь, что не логично ::)
-
Так LIKE это дословно переменная слева будет такая же как переменная справа, а в твоем случае ты объявил тип данных, а потом попытался сказать что переменная будет как... и ссылку на тип даешь, что не логично ::)
Ну да в этом и разница, что like - обьявление ссылкой на переменную, а TYPE STANDARD TABLE OF обьявление со ссылкой на тип.
Хотя ты наверное прав, судя по всему разницы нету...