Some time ago I wrote a post here showing the advantages of using internal tables with defined indexes instead of simple STANDARD tables.

Confession: that habit is so ingrained that since then, almost all the internal tables I have created have continued to be STANDARD TABLE.

It’s very common to create internal tables to cache data that I know I’ll often use inside LOOPS to avoid having to SELECT SINGLES inside them.

Obviously you already know the SE30 transaction (run time analysis) and obviously you use it often to analyse standard programs and to discover tables, functions, BADIs and similar contained within them.

But if you are like me, then you have a love-hate relationship with this transaction – on the one hand you love it because it enables you to see the guts of a program without having to debug it, yet on the other hand you hate it because normally the list of guts tends to have thousands of lines and becomes unmanageable.

In the beginning there was INTO. Actually, in the beginning it was not even INTO.

Whatever the case, it is necessary to put a program to sleep. And, as with almost everything else, there are several ways to do this, some better than others.

The most standard way to do this in ABAP is as follows:

WAIT UP TO 10 SECONDS.

The advantage of WAIT UP TO N SECONDS is that the process is freed up during these 10 seconds, thereby making it available for those who want it. The big disadvantage is that it makes an implicit COMMIT, which is not always so good. If you don’t mind the COMMIT, this is the best way to make your program fall asleep. Please note that you cannot sleep for 1.5 seconds as the parameter only accepts whole numbers.

Ladies and gentlemen, boys and girls, the race is about to begin.

Introduction

The four competitors are as follows. They are 4 internal tables, of different races and creeds, which will fight for the athletics title of speed LOOP. Here they are:

Competitor 1: DATA: LT_ITEM TYPE TABLE Competitor 2: DATA: LT_ITEM_HASHED TYPE HASHED TABLE Competitor 3: DATA: LT_ITEM_SORTED TYPE SORTED TABLE Competitor 4: DATA: LT_ITEM TYPE TABLE + INTO INDEX

It’s very easy to get tied up in knots where performance is concerned when you’re working with internal tables – especially when they’re getting really big. In fact these problems often only arise after a few months, when the tables tend to grow as time goes by.

For example, when you’re looping two tables, one of headers and another of entries, do you do this?

LOOP AT itab1 ASSIGNING <fs1>.
   LOOP AT itab2 ASSGNING <fs2> WHERE field1 = <fs1>-field1.
   ENDLOOP.
ENDLOOP.

Did you know that for big tables this can take ages because LOOP WHERE makes a sequential reading of itab2 for each entry in itab1?

Since I was small I have been using the SE30 transaction for two different things:

• To analyze a (normally standard) program I don’t know in order to find out what functions it uses, what BADIs it offers, etc;

• To analyze a program of mine to search for performance problems.

The simple truth is that the SE30 transaction is a total mess. It’s extremely limited and inflexible and it’s useless for any more complex analysis.

Normalmente quando há um pedaço de código que pretendemos reutilizar várias vezes, transformamo-lo numa sub-rotina que pode depois ser invocada repetidamente. Embora a SAP não saiba estruturar o seu próprio código, ainda assim, o ABAP, coitadinho, permite-o. E até disponibiliza várias alternativas para modularizar o código. Eu conto quatro alternativas que listo aqui, da mais rígida para a mais flácida: METHOD, FUNCTION, FORM, DEFINE. Se os 3 primeiros são já familiar de todos, o último - DEFINE - quase ninguém usa. O DEFINE permite definir macros em ABAP. E o que são macros? São sub-rotinas aparentes.

Aparentes porquê?

Por vezes ao fazer READ TABLE a uma tabela interna queremos apenas verificar se um determinado registo existe, e não nos preocupamos com os dados retornados. Algo tipo:

READ TABLE lt_kna1 INTO wa_kna1 WITH KEY kunnr = l_kunnr.
CHECK SY-SUBRC = 0.

Ora já que a estrutura WA_KNA1 não vai ser necessária de qualquer forma, mais vale não a usar, usando antes a opção TRANSPORTING NO FIELDS:

READ TABLE lt_kna1 TRANSPORTING NO FIELDS WITH KEY kunnr = l_kunnr.
CHECK SY-SUBRC = 0.

O Abapinho saúda-vos.