Pass internal tables by value is good

images/thumbnail.jpg - Thumbnail

When a method returns a value as a RETURNING parameter this is always done by value and not by reference. Several of my methods return internal tables, some of them quite large. It always worried me the idea that, since it’s being passed by value, ABAP would be returning a copy of the internal table, impacting both performance and the program’s used memory.

Fortunately, I recently learned that this is not​ a problem.

Internal table secondary indexes

images/thumbnail.jpg - Thumbnail

This is how internal tables used to be declared:

DATA: itbl TYPE TABLE OF bkpf.

DELETE vs CLEAR vs REFRESH vs FREE

images/thumbnail.jpg - Thumbnail

DELETE CLEAR REFRESH FREE

These are different ways of deleting all data from an internal table. They look the same. But they aren’t.

Teach ABAP to juggle

images/thumbnail.jpg - Thumbnail

What can be done when a night is not enough to complete the daily processes?

Thou shalt use TRANSPORTING NO FIELDS

images/thumbnail.jpg - Thumbnail

Many times we do READ TABLE itbl or LOOP AT itbl just to do a CHECK SY-SUBRC = 0. In these cases, the actual data read is not needed. For these cases always use TRANSPORTING NO FIELDS. This way is faster and avoids having to declare a target structure.

INNER JOIN vs FOR ALL ENTRIES vs artificial RANGES

images/thumbnail.jpg - Thumbnail

Since data operations are much more optimized in the database server than in ABAP, it is always better to use the first as much as possible. FOR ALL ENTRIES should only be used when INNER JOIN doesn’t give us what we need or is not possible (like with BSEG for example). Artificial ranges are also a possible alternative to FOR ALL ENTRIES but be careful not to reach the SQL parser limit. It depends on the database server but as a rule of thumb avoid ranges with more than 1000 lines. When using FOR ALL ENTRIES always make sure the internal table is not empty or else all lines of the database table will be fetched.

Thou shalt not SELECT *

images/thumbnail.jpg - Thumbnail

Always try to select only the fields you’ll need. Selecting others is a waste of resources. Exception made for the use of FM *_SINGLE_READ because, even though these do select all fields, since they cache the data, they are still faster when used multiple times for the same key. If you just want to check if a record exists, select just one field, if possible the one you’re using as criteria to avoid declaring an extra variable. Example: SELECT KUNNR INTO V_KUNNR FROM KNA1 WHERE KUNNR = V_KUNNR. https://abapinho.com/en/2010/11/select-todos-os-campos/ (portuguese)

Thou shalt use FIELD-SYMBOLs instead of working areas

images/thumbnail.jpg - Thumbnail

READ TABLE itbl ASSIGNING is always faster than READ TABLE itbl INTO wa. Besides, when making changes to internal tables, not only it doesn’t require the explicit MODIFY but it also does away with the auxiliary TABIX variable. The only situation in which a working area is better is when adding new lines to an internal table. Some people contend that working areas should still be used when no changes are to be made to the data. This is still slower, but visually can be more intuitive.

SELECT within SELECT

images/thumbnail.jpg - Thumbnail

ABAP programmers don’t explore the possibilities of SQL, probably for historical reasons. There are many who instead of using INNER JOINs still think it’s faster to do several SELECTs for internal tables and then process the data in ABAP. But the truth is that even if there are exceptions, the rule is: the lower the number of accesses to the database, the better the performance. And it makes sense because, after all, they were written explicitly for this; relational databases are much more adept at processing relational data than an ABAP program.

There are of course things that, due to their complexity, cannot be done with a simple INNER JOIN. Nevertheless, some of these things can be done in a single SELECT.

With many fields avoid INTO CORRESPONDING FIELDS

images/thumbnail.jpg - Thumbnail

I have already advised here that, in tables with many fields, it’s always recommended to avoid using SELECT *, you must always select, explicitly, only the necessary fields.

But I didn’t warn you that there’s yet another optimisation worth making: avoid INTO CORRESPONDING FIELDS OF TABLE.