Technical Articles
ABAP Lesser Known Heroes Series – APPEND CORRESPONDING : Part 4
This is continuation of my blog series:
- ABAP Lesser Known Heroes Series – Group Column : Part 1 | SAP Blogs
- ABAP Lesser Known Heroes Series – Value Operator : Part 2 | SAP Blogs
- ABAP Lesser Known Heroes Series – TYPE RANGE OF : Part 3 | SAP Blogs
- ABAP Lesser Known Heroes Series – APPEND CORRESPONDING : Part 4
You may know MOVE CORRESPONDING between tables and structures , CORRESPONDING # operators etc. But what about APPEND CORRESPONDING ?
I have rarely seen or anyone talking about this particular command in the forum. So here you go.
SAP opened up a new world of possibilities when they came up with MOVE-CORRESPONDING and CORRESPONDING# between internal tables where you could even map the fields, traverse down to deep structures , fetch the fields excepting some columns and so on.
But what if you want to loop through an internal table, change some values based on condition and append the same to an internal table of slighlty different structure? For example please look at below code.
Types: Begin of ty_city_temp,
city_temp type ztemp,
longitude type zlongitude,
district type zdistrict,
END OF ty_city_temp .
Types: Begin of ty_city_temp_windy,
city_temp type ztemp,
END OF ty_city_temp_windy.
DATA: lt_city_temps TYPE TABLE OF ty_city_temp,
lt_city_temps_windy TYPE TABLE OF ty_city_temp_windy,
lv_windy TYPE ABAP_BOOL .
IF lv_windy = ABAP_TRUE.
LOOP AT lt_city_temps reference into data(lr_city_temp) .
lr_city_temp->city_temp = lr_city_temp->city_temp - 3 . "Only an assumption that temperature will be
"less by 3 degree celcius when windy
APPEND CORRESPONDING ty_city_temp_windy( lr_city_temp->* ) TO lt_city_temps_windy .
ENDLOOP.
ENDIF.
Here we are saved from declaring another structure of type ty_city_temp_windy and another MOVE-CORRESPONDING statement . we are using APPEND CORRESPONDING statement and adding to the internal table.
Close, but no cigar I'm afraid. APPEND is no hero. It only works with standard tables, not sorted or hashed. For robust programming, always use INSERT. And it's usually a good idea to explicitly define the internal tables with their key.
Furthermore, CORRESPONDING is a constructor operator. It's not actually part of the APPEND nor INSERT statement. Additionally, LOOP AT ASSIGNING is faster than REFERENCE INTO.
Finally, I'd put the condition outside the loop and get rid of the useless prefixes. The variable names adequately explain already what they represent.
Matthew Billingham
Thanks for your comment.
I just want to point out that there exists a statement called APPEND CORRESPONDING and the suggestion to use INSERT CORRESPONDING is more than welcome. 🙂
It is a fact(may be sad ) that most of the developers use standard tables( and it is not going to change any time soon) than other tables albeit the situation demands other way. So just thought of reminding them there is one more tool they can have in their Arsenal.
or in situations mentioned in Clean ABAP .
"Use
STANDARDtables for small tables, where indexing produces more overhead than benefit, and "arrays", where you either don't care at all for the order of the rows, or you want to process them in exactly the order they were appended. Also, if different access to the table is needed e.g. indexed access and sorted access viaSORTandBINARY SEARCH."I mentioned the CORRESPONDING constructor not as replica for INSERT or APPEND statement but just to point out that what techniques exist already for data transfer from one internal table to other. (Here what we are trying to do is also kind of corresponding but when some conditions satisfied)
Regarding Hungarian Notations, I am also not a fan of it but some of our customers are and just habits creep in. The point of the blog is not that any how and paid less attention. Next time I will change in my blogs. Thank you.
Even though 'Prefer REF TO to FIELD_SYMBOL' in Clean ABAP is challenged, i just stuck to Clean ABAP in this example. (May be not in performance critical situations) .
Yes , you are right lv_windy could make more sense above the loop. I stand corrected.
Regards,
Philip.
My contention is the there isn't a statement APPEND CORRESPONDING nor INSERT CORRESPONDING. It only look like there is. As I said, it's a constructor operator.
In the same way, INSERT VALUE isn't part of the INSERT syntax. Or INSERT CONV, or INSERT FILTER, INSERT SWITCH ... etc.
A bit pedantic, possibly, but if you read the documentation for APPEND or INSERT, you won't find CORRESPONDING discussed.
Agree with Matt. I found the title of the blog a bit misleading.
As Matt (and the ABAP docu) mentions the insert/append table_line, the table_line is a general expression position
In your examples, you've highlighted the use of CORRESPONDING. It can be any other expression - COND, a functional method et al.
For robust and intent-declaring programming use INSERT when inserting and APPEND when appending. Know both and use the one that fits the inherent logic you are implementing.
Why not stick to INSERT without ever worrying about the table type - STANDARD vs SORTED/HASHED?
IMO, you always insert the line into the table.
When I use APPEND I am trying to reveal that the order or uniqueness of the data set is not relevant, or that the relevant order is the sequential order of insertion.
When I use INSERT I try to reveal that order based on a key or uniqueness within the data set is relevant.
My personal rule of thumb is to use APPEND unless you need or benefit from an INSERT (which is often the case as well). I'm supposed to know exactly what I'm doing and like to communicate that to the rest of the world and to my future self. I think the ITAB_ILLEGAL_SORT_ORDER exception is not a fearsome enemy.
Hi Matt,
I was team ASSIGNING until immutable (FINAL) data references were introduced. AFAIK, field-symbols cannot be immutable. When i want to just iterate on a "wide" internal table without modifying it, i use immutable data references over field-symbols.
Would you still prefer non-immutable field-symbols because ASSIGNING is faster?
~ Suhas