CEN Com IT MET ABAP Recommending Performances V2

KHEOPS CORE MODEL INTERNATIONAL

ABAP Recommended performances
Document information :
Team
Technical - Development
Responsible
Philippe Bride
Version
V2
Last modification on
02/09/2004
Status
Validated
Version
Date
Author
/var/www/apps/conversion/tmp/scratch_2/261948625.doc
Modification
Page 1 of 38
last modification: 2/28/2015
TABLE OF CONTENTS
1.
INTRODUCTION.................................................................................................................................4
2.
NOTATIONS..........................................................................................................................................5
2.1.
2.2.
3.
PICTOGRAMS....................................................................................................................................5
NOTATIONS IN THE ALGORITHMS.....................................................................................................5
GENERAL RULES................................................................................................................................6
3.1.
3.2.
3.3.
3.4.
3.5.
4.
DATABASE SERVER / APPLICATION SERVER........................................................................................6

DATA LOADING IN INTERNAL TABLE..................................................................................................6
TEST OF THE RETURN CODE.............................................................................................................6
AUTHORIZED TOOLS/ FORBIDDEN TOOLS...........................................................................................6
QUERY.............................................................................................................................................6
SELECTION ON ONE TABLE............................................................................................................7

4.1.
4.2.
4.3.
4.4.
5.
SELECTED FIELDS.............................................................................................................................7
THE <WHERE> CLAUSE.....................................................................................................................7
THE <SELECT> INSTRUCTION........................................................................................................8
INFORMATION STRUCTURES.............................................................................................................12
SELECTION ON MANY TABLES....................................................................................................13

5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
5.7.
LOGICAL DATABASE (LDB).............................................................................................................13

NESTED SELECT................................................................................................................................13
SUB-QUERY......................................................................................................................................14
JOINS................................................................................................................................................14
STOCKING IN AN INTERNAL TABLE THANKS TO A <FOR ALL ENTRIES>........................................15
VIEW..............................................................................................................................................17
USING RECOMMENDATIONS..............................................................................................................18
6.
COMMIT AND ROLLBACK.............................................................................................................20
7.
DATA DICTIONARY..........................................................................................................................21
7.1.
7.2.
7.3.
8.
TABLE CREATION.............................................................................................................................21
BUFFERING.......................................................................................................................................22
INDEXING.........................................................................................................................................22
MASS TREATMENTS........................................................................................................................23
8.1.
8.2.
8.3.
9.
DELETION.........................................................................................................................................23
MODIFICATION...............................................................................................................................25
INSERTION........................................................................................................................................26
REMARKS ON SOME INSTRUCTIONS.........................................................................................27

9.1.
9.2.
9.3.
9.4.
9.5.
10.
10.1.
10.2.
10.3.
10.4.
<READ TABLE> INSTRUCTION....................................................................................................27

DECLARATION OF AN INTERNAL TABLE...........................................................................................28
LOOP................................................................................................................................................28
NESTED LOOPS.................................................................................................................................29
FORM/ PERFORM............................................................................................................................35
HIGH-LEVEL PERFORMANCE..................................................................................................36
HASHED TABLES..........................................................................................................................36
BUFFERING..................................................................................................................................36
INDEXING.....................................................................................................................................37
PERFORM..................................................................................................................................37
Page 2 of 38
10.5.
USE OF THE DATABASE SERVER..................................................................................................37
Page 3 of 38
1. Introduction
The objective of this documentation is not to provide solutions regarding performance problems
from an ABAP point of view but to suggest some methods, which will improve the execution run
time of specific programs.
In the development phase, the programmer must always keep in mind that the way in which he or
she codes has a direct impact on the execution run time.
Considering significant volumes of the databases at EUROVIA, the least access "badly coded" on a
table, for example MSEG, can appear catastrophic. Indeed in most of the cases, accesses to the
bases represent the major part of the total execution time of a program. That is why the developer
must be rigorous when he must code readings, insertions, suppressions and modifications of
recordings in the tables.
First of all, in Chapters 2 and 3, the notations used in this document and some general rules for
developing are presented.
The two following chapters deal with data selection: on one table with the <SELECT> instruction,
then on many tables with different loops and joins.
Chapter 6 treats the aspects of the <COMMIT> and <ROLLBACK> instructions.
Chapter 7 provides some advice about the data dictionary.
Chapter 8 explains how to carry out optimized mass treatments: deletion, modification, and
insertion.
Chapter 9 brings several remarks on some instructions as the nested loops.
Last but not least, Chapter 10 provides some solutions to big problems of performance in order to
make high-level performance.
THE PERFORMANCE OBJECTIVE IS NOT TO WRITE A PROGRAM

QUICKLY BUT TO WRITE A PROGRAM CORRECTLY WHICH WILL BE
MORE PERFORMING IN ITS EXECUTION TIME
Page 4 of 38
2. Notations
2.1. Pictograms
High performance.
Tool to use in priority.
Low performance.
Tool to avoid except in some particular cases.
Very low performance.
Forbidden tool.
In some very particular cases, if the use of the tool seems essential, the
developer must indicate it inside the program and talk about it with the
Performance team before releasing the order.
Significant remark.
Trap to avoid.
Informations
2.2. Notations in the algorithms

Notation
table
wt_table
wa_
wc_const
<wf_>
ws_struct
field1, field2
key
s_
zv_view
Treatment
Signification
Name of a transparent table (ORACLE table for example)
Name of an internal table
Name of a work area
Name of a constant
Name of a field symbol
Name of an internal structure
Name of a field of a table
Name of a key of a table
Name of a Select Option
Name of a specific view
Treatment carried out in a program
Page 5 of 38
3. General rules
3.1. Database server / Application server
Even if working on the database server is often quicker then working on the application server, it is
recommended to solicit the application server in order to avoid overloading the database sever.
Therefore it is important to:
1. Repatriate the data from the database to the application server,
2. Work on the application server.
3.2. Data loading in internal table

When we use the <SELECT INTO TABLE wt_table> instruction, exchanges between
the database server and the application server are made by packets.
When we use the <SELECT ENDSELECT> instruction, exchanges between the
database server and the application server are one recording by one recording.
3.3. Test of the return code

It does not make sense to test the return code (<IF sy-subrc = 0>) inside some loops like
<LOOP ENDLOOP> and <SELECT ENDSELECT>. Indeed if there is no recording, instructions
in the loop are not executed.
3.4. Authorized tools/ Forbidden tools

Authorized tools
SELECT SINGLE
SELECT UP TO 1 ROWS
ENDSELECT
SELECT INTO TABLE wt_table
SELECT INTO TABLE wt_table
FOR ALL ENTRIES
Forbidden tools (by descending order of prohibition)
SELECT
ENDSELECT.
Except in the case of only one record

(SELECT UP TO 1 ROWS ENDSELECT.).
Logical databases
Nested select
GROUP BY
ORDER BY
[]CORRESPONDING FIELDS OF []
DISTINCT
Page 6 of 38
3.5. Query
Queries are forbidden because programs generated by a Query are not performing at all. Requests
are not optimized, thus execution time is too high.
Page 7 of 38
4. Selection on one table

4.1. Selected fields
If we wish to select only one record in a table, and not the first record by order of the key, we will
use an instruction, which does not loop on the table.
SELECT *
FROM table
WHERE field1 = xxx.

Treatment.
EXIT.
ENDSELECT.
Use : field1 is not the

primary key.
SELECT *
FROM table
UP TO 1 ROWS
WHERE field1 = xxx.
Treatment.
ENDSELECT.
Use : field1 is the primary key or

a part of the primary key.
SELECT SINGLE *
FROM table
WHERE field1 = xxx.
IF sy-subrc = 0.
Treatment.
ENDIF.
After many compared tests, it is proven that the <SELECT SINGLE> instruction seems to
be more efficient that <UP TO 1 ROWS> one. During the use of a <SELECT SINGLE>
instruction, if the field used in the <WHERE> clause is only a part of the primary key, the
Workbench displays a <Warning> message.
Even if the <SELECT *> instruction is very quick at coding, it unfortunately takes up a lot of
memory space in most of the cases. It is recommended to select only the useful fields for the
treatment.
When we are on the instruction which follows <ENDSELECT>, we do not know if we
have gone into the <SELECT> instruction or not. This implies that it is always
necessary to test the return code after the <SELECT> instruction.
Except for the particular cases:
number of selected fields

0.8
number of fields of the table
Use: Selection of a limited

number of fields.
Dynpro updating
SELECT SINGLE *
FROM table
WHERE field2 = xxx.
SELECT SINGLE field1

INTO table-field1
FROM table
WHERE field2 = xxx.
4.2. The <WHERE> clause

The order of the fields in the <WHERE> clause has an impact on the execution time of the request.
SAP works with a positioning pointer on the tables. The first field of the <WHERE> clause permits
the pointer to position itself. Then the table is sequentially read. Therefore the order of the tests in
the <WHERE> clause is very important.
The developer must pay attention while he codes <SELECT> instructions.
When the developer codes an instruction in order to read in the database, he must respect the
following rules by descending priority:
Page 8 of 38
Put the fields in the same order of the key
Put the fields in the same order of the existing index
Put the tests the most restricted in first position

Remark: After a <SELECT> instruction, do not code a <CHECK> instruction on the fields of the
table. It is better to insert these tests in the <WHERE> clause.
The test is in the <WHERE> clause.
SELECT *
INTO TABLE wt_table
FROM table
WHERE field1 = xxxx.
SELECT *
INTO TABLE wt_table
FROM table
WHERE field1 = xxxx
AND field2 EQ zzz.
LOOP FROM wt_table

CHECK wt_table-field2 EQ zzz.
Treatment.
ENDLOOP.
IF sy-dbcnt NE 0.
LOOP AT wt_table.
Treatment.
ENDLOOP.
ENDIF.
4.3. The <SELECT> instruction

General rules
If we select all the fields of a table, it is not necessary to specify the <INTO> option in the
<SELECT> instruction. Indeed, SAP, which works only with buffers, will automatically fill in the
buffer of the read table.
Not useful to specify the
<INTO> option.
SELECT SINGLE *
INTO table
FROM table
WHERE field = xxxx.
SELECT SINGLE *
FROM table
WHERE field = xxxx.
After a <SELECT> instruction, data are not systematically sorted in the key order. Hence
data must be sorted in the case of a reuse. But non-justified redundant sorts are forbidden
because they cost a lot in term of performance.
Data sorting
Sorting on the database server.
SELECT *
FROM table
WHERE field1 = xxxx
ORDER BY field2.
Treatment.
EXIT.
ENDSELECT.
Sorting on the application server.

SELECT *
INTO TABLE wt_table
FROM table
IF sy-dbcnt NE 0.
SORT wt_table BY field2.
LOOP AT wt_table.
Treatment.
ENDLOOP.
ENDIF.
Page 9 of 38
<INTO> option
This option permits to stock the selected columns in the variables defined by the developer.
SELECT SINGLE *
INTO table
FROM table
IF sy-dbcnt NE 0.
wv_field2 = table-field2.
Treatment.
ENDIF.
Treatment without storing the

data into a table.
SELECT SINGLE field2
INTO wv_field2
FROM table
WHERE field1 = xxxx
IF sy-dbcnt NE 0.
Treatment.
ENDIF.
<INTO TABLE> option

This option permits to stock many records in an internal table.
It is not necessary to carry out a <REFRESH> of the internal table because it is automatically made
by this option. Furthermore, the <APPEND> of the internal table is implicit.
There is no <ENDSELECT> instruction because it is not a loop treatment. The storage of the table is
carried out at one go.
<APPENDING TABLE > option

This option permits to add further records to an internal specified table.
The <APPEND> instruction is included is the <APPENDING TABLE> instruction. If the internal table
is refreshed (<REFRESH>) just before using the <APPENDING TABLE> instruction, it is the same as
using the <INTO TABLE> instruction. Therefore if the internal table is empty, the <APPENDING
TABLE> instruction must not be used.
There is no <ENDSELECT> instruction because it is not a loop treatment. The updating of the table
is carried out at one go.
<[] CORRESPONDING FIELDS OF []> options

If we want to stock the contents of the chosen fields in another field (different of the buffer), it must
have the same structure as the chosen fields.
The <INTO CORRESPONDING FIELDS OF> instruction is equivalent to a <MOVECORRESPONDING> one between the selected columns and the stocking fields.
Indeed, this option is used when there is a difference between the structure consisted of the fields of
the <SELECT> and the target (in the <INTO>). In this case, the SAP process researches one after
one the fields which have the same names and then make the allocation.
But it is better to put the fields of the <SELECT> instruction in the same order
of the structure declaration or the internal table in order to be quicker.
Page 10 of 38
Not recommended use of <INTO CORRESPONDING FIELDS OF>

Direct storage into a table or a structure, without using the fields.
SELECT SINGLE *
INTO CORRESPONDING FIELDS OF table
FROM table
WHERE key = xxxx.
SELECT SINGLE *
FROM table
WHERE key = xxx.
Structure
DATA: BEGIN OF ws_struct,
field1 LIKE table-field1,
END OF ws_struct.
DATA : BEGIN OF ws_struct,

END OF ws_struct.
SELECT SINGLE *
INTO CORRESPONDING FIELDS OF ws_struct
FROM table
SELECT SINGLE field1 field2 field3

INTO ws_struct
FROM table
Internal table
DATA : BEGIN OF wt_table OCCURS 0,
END OF wt_table.

END OF wt_table.
SELECT *
INTO CORRESPONDING FIELDS OF wt_table
FROM table
APPEND wt_table.
ENDSELECT.
SELECT *
INTO CORRESPONDING FIELDS OF TABLE wt_table
FROM table
SELECT field1 field2 field3

INTO TABLE wt_table
FROM table
INTO TABLE wt_table
FROM table
There are several forms like <INTO CORRESPONDING FIELDS OF TABLE> and <APPENDING
CORRESPONDING FIELDS OF TABLE>
Example:
Given a transparent table with the fields field1, field2, field3, field4 and field5 in this order,
Given an internal table with the fields field1, field 3 and field 4 in this order,
We get:
REFRESH wt_table.
SELECT *
FROM table
APPEND wt_table.
ENDSELECT.
Use: Storage of data into a empty table. .

If the table is not empty, data are zapped.
INTO TABLE wt_table
FROM table
Page 11 of 38
SELECT *
FROM table
APPEND wt_table.
ENDSELECT.
Use: Addition of data into a no-empty table

APPENDING TABLE wt_table
FROM table
<FOR ALL ENTRIES IN> option

This option permits to research all the records of a table from the data of an internal table thanks to
the links created in the <WHERE> clause.
To use the <FOR ALL ENTRIES IN> option:
The internal table must not be empty.

The recordings must be sorted in order to
delete the duplicates.

The <WHERE> clause must consist of equalities.
If the internal table is empty, the <SELECT> instruction loops on all of the data of the selected table.
The deletion of the duplicates is compulsory for two reasons:
It enables to accelerate the execution of the <SELECT FOR ALL ENTRIES> instruction
since the volume of the internal table is smaller.
It avoids some dumps of the programs because of a lack of memory in the table2 table
(See the following example)
If we know that the internal table has duplicates, we have to copy the internal table, sort it and
delete its duplicates.
- test the number of recordings
- sort the recordings
- delete the duplicates
SELECT *
INTO TABLE wt_table1
FROM table1
WHERE field1 IN s_field1.
SELECT *
FROM table2
FOR ALL ENTRIES IN wt_table1
WHERE field1 = wt_table1-field1
AND field2 = xxxx.
Treatment.
SELECT *
FROM table
WHERE field1 IN s_field1.
IF sy-dbcnt NE 0.
SORT wt_table1 BY field1.
DELETE ADJACENT DUPLICATES FROM wt_table1
COMPARING field1.
SELECT *
FROM table2
FOR ALL ENTRIES IN wt_table1
WHERE field1 = wt_table1-field1
AND field2 = xxxx.
Treatment.
ENDIF.
Page 12 of 38
4.4. Information structures

The information structures are defined by customizing and are therefore created by the operating
consultants. From a technical point of view, the information structures are only transparent tables
and are always named <SXXX>.
The key of the information structure always begins by the same fields which are: MANDT,
SSOUR, VRSIO, SPMON, SPTAG, SPWOC and SPBUP. The other fields of the key are those
specified by the creating consultant of the information structure.
Furthermore, when an information structure is created, SAP automatically adds on:
- An index on KUNNR if this field exists in the key
- An index on MATNR if this field exists in the key
- An index on PMNUX if this field exists in the key
If two of these fields exist in the key, SAP goes to add on two indexes one for each field.
The first index added on will be called <VAB> the second <VAC> and the third <VAD>.
Looking at the contents of the information structure we can note that most of the keys predefined by
SAP are practically never consulted.
Furthermore, we do not know why the readings on information structures are very costly in
response time even if all the fields of the key are filled.
Example:
Given the information structure S631 daily movements defined in the following way:
- Key: MANDT, SSOUR, VRSIO, SPMON, SPTAG, SPWOC, SPBUP, WERKS and MATNR
- Supplementary Fields: PERIV, UWDAT, BASME, MZUBB, MAGBB
Index automatically added on by SAP:
- VAB defined as: MANDT, MATNR
Index created for the performances:
- A1: MANDT, VRSIO, WERKS, MATNR and SPTAG
Use of the created index
SELECT *
INTO TABLE wt_s631
FROM s631
WHERE ssour = space
AND
vrsio = wv_vrsio
AND
spmon = 000000
AND
sptag >= wv_beginning
AND
sptag <= wv_end
AND
spwoc = 000000
AND
spbup = 000000
AND
werks = wv_werks
AND
matnr = wv_matnr.
SELECT *
INTO TABLE wt_s631
FROM s631
WHERE vrsio = wv_vrsio
AND
werks = wv_werks
AND
matnr = wv_matnr
AND
sptag >= wv_beginning
AND
sptag <= wv_end.
Where created index is MANDT, VRSIO, WERKS, MATNR
and SPTAG.
Page 13 of 38
5. Selection on many tables

5.1. Logical database (LDB)
Principle
A logical database (LDB) is an interface used by a program for the reading and the treatment of
data. The order in which the data are read is determined by the directory structure of the LDB.
This method of programming is largely used for acceding to databases in an SAP R/2 environment.
This method can be assimilated to the one used in the hierarchical databases like for example DL/1.
Treatment.
GET mkpf.
Treatment.
GET mseg.
Treatment.
Example
Advantage
During a reading on a son segment, it is not necessary to carry out a reading on the parent
segments. Indeed these are implicit.
For example, if a LDB has MKPF as <Father> segment and MSEG as <Son> segment, a <GET> on
MSEG is sufficient to know the data of MSEG and also that of MKPF.
GET mseg.
CHECK mkpf-blart = xx.
Treatment
Another advantage is that each LDB possesses a selection screen, the fields of which are generated
by the BDL.
Performance
This method is forbidden because in SAP R/3 it is far from being the most performing
method for reading data in the databases.
5.2. Nested select

Principle
During the execution of a <SELECT> instruction the process accesses to the database. Therefore, on
a <SELECT *>, there is nearly the same number of accesses to the database as the quantity of read
records.
Example
SELECT *
FROM table1
WHERE .
Treatment.
SELECT *
FROM table2
WHERE table1-field1 = table2-field1 AND .
Treatment.
Page 14 of 38

ENDSELECT.
Treatment.
ENDSELECT.
Advantage
The developer controls the access to the database.
Drawback
Considering the important number of accesses to the database, this method is not very
performing from the point of view of the execution duration. Therefore it is forbidden
to use it.
5.3. Sub-query
A sub-query solicits the database sever. So, it is not recommended. However, in some particular
cases, we can use it (See Section 10)
Example:
SELECT * FROM table
INTO TABLE wt_table
WHERE field IN ( SELECT FROM WHERE).
5.4. Joins
Principle
Instead of carrying out the selections in many tables from the database, the join permits to carry out
dynamically in memory only one access to the different tables. The join can be assimilated to a
view but the difference is that the join is not defined in the dictionary.
Example
SELECT mkpf~mblnr mkpf~mjahr mseg~zeile mseg~
FROM mkpf INNER JOIN mseg ON mseg~mblnr = mkpf~mblnr
AND mseg~mjahr = mkpf~mjahr
WHERE mkpf~ =
AND
mseg~ = .
Treatment.
Advantage
The developer maintains that he makes only one access because the code can be interpreted like a
<SELECT* FROM table WHERE Treatment ENDSELECT>.
This is a lot quicker than the method of nested SELECT because there are fewer accesses to the
database.
Drawback
The system needs a lot of memory space because it dynamically creates a pseudo table of pointers
in order to optimize the different accesses to different tables of the join.
The performance problem comes from the fact that the code generated by SAP is interpreted by an
internal layer at SAP and not by the database server itself.
Page 15 of 38
Use
The inner join can be only used in the case of a 1 to n relation on the key of type
header data <-> item data.
In the other cases, it is forbidden.
5.5. Stocking in an internal table thanks to a
<for all entries>
Principle
We choose in a first transparent table some records that are stocked in an internal table. We get in a
second transparent table all the records related to each entry of the first internal table by a condition.
Example
* Selection of data at the top of the table
SELECT * INTO TABLE wt_mkpf FROM mkpf
WHERE
AND
.
IF sy-dbcnt NE 0.
SORT wt_mkpf BY mblnr mjahr.
* Selection of data from the table lines
SELECT * INTO TABLE wt_mseg FROM mseg
FOR ALL ENTRIES IN wt_mkpf
WHERE mblnr = wt_mkpf-mblnr
AND
mjahr = wt_mkpf-mjahr
AND
lgort = wc_lgort.
IF sy-dbcnt NE 0.
SORT wt_mseg BY mblnr mjahr zeile.
* Treatment of the selected data
LOOP AT wt_mseg.
Treatment.
AT NEW mjahr.
CLEAR wt_mkpf.
READ TABLE wt_mkpf WITH KEY mblnr = wt_mseg-mblnr
mjahr = wt_mseg-mjahr
BINARY SEARCH.
Treatment.
ENDAT.
Treatment.
AT END OF mjahr.
Treatment.
ENDAT.
Treatment.
ENDLOOP.
ENDIF.
ENDIF.
It is important to test the number of records returned during the stocking in an internal
table from the first transparent table and to read the second transparent table, only if the
internal table contains at least one record. Indeed, if the test is not done and if the first
table is empty, the access to the second table will provide ALL the records of this table.
Page 16 of 38
Advantage
This reduces the number of accesses to the database not only from the data selection but also from
the data processing in the body of the program.
Drawback
In some cases we can choose more data than necessary in reality. Furthermore if there are many
tables to stock it will request a large quantity of memory.
Warning
If there are several identical records, the result given by the clause <for all entries in> will
keep only the first occurrence.
Contents of the ekko table:
ebeln
bukrs
zterm
1000
2000
3000
4000
5000
6000
7000
8000
050C
050C
100D
050C
050C
100D
100D
050C
30J
60J
90J
30F
60F
90F
30J
90F
Contents of the ekpo table:
--------------------------
ebeln
ebelp
bukrs
matnr
menge
1000
1000
2000
2000
3000
3000
6000
6000
010
020
050
060
030
040
010
060
050C
050C
050C
050C
100D
100D
100D
100D
2818
2818
2420
2420
2750
2750
2818
2750
100,00
100,00
200,00
200,00
300,00
500,00
600,00
600,00
ebeln
1000
2000
3000
4000
5000
6000
Example with a partial key or complete key

Contents of the wt_ekko table with a select-option
<s_ebeln> between 1000 and 6000 sorted by purchase
orders :
bukrs
050C
050C
100D
050C
050C
100D
zterm
30J
60J
90J
30F
60F
90F
Selection of quantities and material numbers for purchase orders.

SELECT ebeln matnr menge
SELECT ebeln ebelp matnr menge
INTO TABLE wt_ekpo
INTO TABLE wt_ekpo
FROM wt_ekpo
FROM wt_ekpo
FOR ALL ENTRIES IN wt_ekko
WHERE ebeln = wt_ekko-ebeln.
WHERE ebeln = wt_ekko-ebeln.
Contents of the wt_ekpo with table with ebeln
(partial key) into the selection. The wt_ekpo
table is defined with these 3 fields.
ebeln
matnr
menge
1000
2000
3000
3000
6000
2818
2420
2750
2750
2818
100,00
200,00
300,00
500,00
600,00
Contents of the wt_ekpo table with ebeln et ebelp

(complete key) into the selection. The wt_ekpo
-------------------------
ebeln
ebelp
matnr
menge
1000
1000
2000
2000
3000
010
020
050
060
030
2818
2818
2420
2420
2750
100,00
100,00
200,00
200,00
300,00
Page 17 of 38

6000
2750
600,00
3000
6000
6000
ebeln
4000
1000
5000
2000
6000
3000
Example without a key

Contents of the wt_ekko table with a select-option
<s_ebeln> between 1000 and 6000 sorted by
company code and payment code :
040
010
060
2750
2818
2750
bukrs
050C
050C
050C
050C
100D
100D
500,00
600,00
600,00
zterm
30F
30J
60F
60J
90F
90J
Selection of quantities and material numbers for company codes.

SELECT bukrs matnr menge
SELECT bukrs matnr menge werks
INTO TABLE wt_ekpo
INTO TABLE wt_ekpo
FROM wt_ekpo
FROM wt_ekpo
WHERE bukrs = wt_ekko-bukrs.
WHERE bukrs = wt_ekko-bukrs.
Contents of the wt_ekpo table. The wt_ekpo
bukrs
050C
050C
100D
100D
100D
100D
matnr
2818
2420
2818
2750
2750
2750
menge
100,00
200,00
600,00
600,00
300,00
500,00
Contents of the wt_ekpo table. The wt_ekpo

-----------------
bukrs
050C
050C
050C
050C
100D
100D
100D
100D
matnr
2818
2818
2420
2420
2818
2750
2750
2750
menge
100,00
100,00
200,00
200,00
600,00
600,00
300,00
500,00
werks
A000
A001
A000
A001
A000
A000
A001
A001
Solution:
To avoid this major inconvenience, it is compulsory to quote the complete key in the list of fields to be
selected.
5.6. View
Principle
A view is a virtual table which does not have a physical existence and which is composed of
columns belonging to one or many tables. During the first call of the view, the system loads all the
data into a memory table corresponding to the view.
Page 18 of 38
Creating a view
As we can see, there are at least four sections to fill
out in order to create a view.
- The name of the database view and its
description
- The list of the different tables used in the
view.
The join conditions, i.e. the requests that link

the different tables.
All the zones which are in this section must
belong to the keys of the tables, or to one of the
indexes of the tables so that the join request may
be the most performing.
The view fields: the different columns we wish

to see in the view.
Example
SELECT *
FROM zv_view
WHERE
AND
.
Treatment.
ENDSELECT.
Advantage
There are very few accesses to the database for choosing many records which are in different tables.
Drawback
If we want to optimize all the programs by this method, it should be necessary to create at least as
many views as that of the programs. But it takes a lot of memory space.
Furthermore, if there are many tables in the view, the relation between them must point on a key or
on an index so that the view may be the most performing.
Use
Many views have been created by SAP. So we must use them in priority (instead of using
a inner join).
We must avoid creating new specific views because of the memory space.
5.7. Using recommendations

Type of selection
on many tables
For all entries
Using recommendations
(1=high, 6=low)
1
Commentary
Always use it except in the case of a 1 to n relation.
Test if the table is empty, sort the table and delete
Page 19 of 38
duplicates.
Join
Use it when there is a 1 to n relation on the key.
View
Use the views created by SAP.

Avoid creating new specifics views.
Sub-query
Not recommended.
Nested select
Forbidden.
Logical
database
Forbidden.
Page 20 of 38
6. Commit and Rollback

During a correction on a table (deletion, insertion, correction) data are not physically updated in the
database. Indeed, corrections are physically carried out on the database only at the end of the logical
unit of treatment, which can be assimilated to a program or even during the execution of a
synchronizing point (<COMMIT>). The end of a program is also the end of the logical unit of
treatment, so a <COMMIT> is done at this moment by the system.
If a program breaks off because of a division by zero (for example) and there is not an explicit
COMMIT in the program, the SAP processor will return to a stable condition, i.e. the situation
before the execution of the program. This backward return is carried out by a <ROLLBACK>, which
is implicit.
In the case of a loop treatment where there is an update on a table and a COMMIT, in the case of a
dump, the SAP processor will go back to the situation just after the last executed COMMIT and not
to the situation before the execution of the program.
Example: Extraction of the coding from the program ZCIV0061 at EUROVIA.
DELETE FROM y9nav
WHERE zznom
NE space
OR
zzpavillon NE space.
IF sy-subrc NE 0.
ROLLBACK WORK.
EXIT.
ENDIF.
By extension, after each database correction, it is important to keep the database in a stable
statement. To do this, test the return code of the correction instruction to make a rollback if the sysubrc is not equal to zero.
It is forbidden to use the <COMMIT> instruction in the case of a program that updates
tables by carrying out many treatments to do it (in User-Exit for example).
It is also forbidden to use the <COMMIT> instruction in loop structure.
Page 21 of 38
7. Data dictionary
7.1. Table creation
Summary of the parameters for a specific table
Buffering
Table
category
Data
type
Table
maintenance
Delivery
class
Question
Yes
No
Delivery class C
Delivery class A
Must the table be manually modified?

Is it possible to use the SM30/SM31 transaction to
maintain it?
Tick authorized
SM30/SM31 box and
generate the table
maintenance
Specific program
Is the table of delivery class C?
Data type APPL2
See the following question.
Is the table often modified?
Data type APPL1
Data type APPL0
Is the size of the table in production uncertain?
Choose a category with a

size greater than those of
the forecast
Key the corresponding size

category between 0 and 4.
Is the table often read by transactions?

Is the table rarely modified ?
It is possible to buffer the

table.
It is forbidden to buffer
the table.
Is the table use buffering?

Is the table small?
Is the number of readings high?
Is the number of writings small?
Complete buffering
Is the table large?

Are few different recordings read?
Individual buffering
Generic buffering
No buffering
Do we wish to update the table in production only

by transport?
Does the modification of the table need obligatory
integration tests?
Log Data Changes
Is the table always read with the same beginning of

key (language code, company, analytical perimeter,
country code)?
Is the volume of creations/modifications is small?

Is it important to know who and when a table has been
Log Data Changes
modified?
No Log Data Changes
Is it important to be able to restitute the table contents

at a given date?
A more comprehensive document is available in Doc-DSI:

- table_creation.doc
Page 22 of 38
7.2. Buffering
Buffering a table is forbidden except in some particular cases (see Section10):
7.3. Indexing
The role of the index is to accelerate the data selection in a table.
An index corresponds to the copy of certain fields of a table. These fields are sorted to access more
quickly to data.
The order of fields in the index is very important to determine the speed of the access to the table.
The drawbacks are:
- An index is like a table, which signifies that it takes up disk space.
- All the indexes of a table are updated at the same time and at each time that there is a correction
carried out at a table (INSERT, DELETE, UPDATE, MODIFY). This implies an update of
more than one table. Therefore there is a degradation of the execution time.
Using an existing index is very good for performance.
However, the creation of an index is not recommended except in some very particular
cases (see Section10).
We must be very careful when we create one index.
Page 23 of 38
8. Mass Treatments
8.1. Deletion
Internal Table
If we want to delete many records from an internal table satisfying a condition, it is recommended
to carry out a large suppression instead of a suppression record by record.
Deletion record by record.
LOOP AT wt_table
WHERE field1 = xxx.
DELETE wt_table.
ENDLOOP.
Large deletion.
DELETE FROM wt_table
WHERE field1 = xxx.
Transparent Table
The mass deletion is good when we want to delete records from a transparent table. Instead of
erasing the records one by one, it is advised to stock the records for deletion (only the key fields) in
an internal table with the format of the complete key (even <mandt> field) of the transparent table
and afterwards to use the instruction <DELETE table FROM TABLE wt_table>.
Case 1: The comparison in the <WHERE> clause is made with a constant
Mass deletion
SELECT *
DELETE FROM table
FROM table
WHERE field1 = wc_const.
IF sy-subrc = 0.
DELETE table.
ENDIF.
ENDSELECT.
Case 2: The comparison in the <WHERE> clause is made with a variable (a field of wt_table)
- Storage of the data for deletion in an internal table.
- Deletion of the data of the transparent table thanks
to the internal table.
LOOP AT wt_table.
DATA: BEGIN OF wt_table OCCURS 0,
SELECT *
mandt LIKE table-mandt,
FROM table
key1 LIKE table-key1,
WHERE field1 = wt_tablekey2 LIKE table-key2,
field1.
(all the keys of the table)
IF sy-subrc = 0.
END OF wt_table.
DELETE table.
SORT wt_table_tmp BY field1.
ENDIF.
DELETE ADJACENT DUPLICATES FROM wt_table_tmp
ENDSELECT.
COMPARING field1.
ENDLOOP.
SELECT mandt key1 key2 (all the keys)
INTO TABLE wt_table
FROM table
FOR ALL ENTRIES IN wt_table_tmp
WHERE field1 = wt_table_tmp-field1.
IF sy-dbcnt NE 0.
DELETE table FROM TABLE wt_table.
ENDIF.
Page 24 of 38
Remark: If we know that the internal table has no duplicate, it is not useful to sort it beforehand.
Page 25 of 38
8.2. Modification
Internal table
If we wish to modify the contents of one or many fields of a table for some records, it is
recommended to carry out a mass correction instead of a correction record by record.
Correction record by record
LOOP AT wt_table
WHERE field1 = xxx.
wt_table-field2 = aaa.
wt_table-field3 = bbb.
MODIFY wt_table.
ENDLOOP.
Mass correction
CLEAR wt_table.
wt_table-field2
wt_table-field3
MODIFY wt_table
TRANSPORTING
WHERE field1
= aaa.
= bbb.
field2 field3
= xxx.
Transparent table
Mass correction is good too when we want to correct a transparent table. We can use the
<UPDATE> instruction. The main advantage of this statement is that it is quick. But it does not
make any check.
Case 1: Use of the <UPDATE> instruction
Modification record by record
SELECT * FROM table
WHERE field3 = wc_const
field1 = wc_const1.
field2 = wc_const2.
Mass modification
The <UPDATE> instruction does
not make any check.
UPDATE table
SET field1 = wc_const1
Field2 = wc_const2
MODIFY table.
ENSELECT.
We can use also stock the corrections in an internal table with the format of the transparent table
and afterwards use the <MODIFY table FROM TABLE wt_table> instruction. This instruction
is more costly than the <UPDATE> one but its advantage is that it makes some checks (insertion or
modification for example).
Case 2: Use of the <MODIFY table FROM TABLE wt_table> instruction
Correction record by record
LOOP AT wt_table.
table-field1 = wt_table-field4.
table-field2 = wt_table-field5.
MODIFY table.
ENDLOOP.
- Storage of the data for correction in an internal table

- Modifications of the data of the transparent table
thanks to the internal table.
LOOP AT wt_table_tmp.
CLEAR wt_table.
wt_table-field1 = wt_table_tmp-field4.
wt_table-field2 = wt_table_tmp-field5.
APPEND wt_table.
ENDLOOP.
DESCRIBE TABLE wt_table.
IF sy-tfill NE 0.
DELETE ADJACENT DUPLICATES FROM wt_table
COMPARING field1.
MODIFY table FROM TABLE wt_table.
Page 26 of 38
ENDIF.
8.3. Insertion
Internal table
If we wish to append an entire internal table (wt_table1) to another internal table (wt_table2), we
can use the <APPEND LINES OF wt_table1 TO wt_table2> statement.
The wt_table1 table must have the same structure as the wt_table2 table.
Performance
This method of appending lines of one table to another is about 3 to 4 times faster than appending
them line by line in a loop.
LOOP AT wt_table1.
MOVE wt_table1 TO wt_table2.
APPEND wt_table2.
ENDLOOP.
APPEND LINES OF wt_table1

TO wt_table2.
Transparent table
If we wish to insert some records into a transparent table, it is preferable to stock them in an internal
table, sort this internal table in order to suppress then possible duplicates and insert these changed
records into the transparent table.
Insertion record by record
LOOP treatment.
table-field1 = .
table-field2 = .
INSERT table.
ENDLOOP.
- Storage of the data for insertion in an internal table

- Insertion of the data into the transparent table
thanks to the internal table.
LOOP treatment.
wt_table-field1 = .
wt_table-field2 = .
APPEND wt_table.
ENDLOOP.
SORT wt_table BY field1 .
DELETE ADJACENT DUPLICATES FROM wt_table
COMPARING field1.
INSERT table FROM TABLE wt_table.
Page 27 of 38
9. Remarks on some instructions

9.1. <READ TABLE> instruction
To use the <READ TABLE> instruction:
The <BINARY SEARCH> option is compulsory.

The recordings must be sorted before the reading
The sort must be ascending and on the reading key.
This instruction positions itself on the first record in the table

that contains the value.
To carry out a direct reading on an internal table, it is better to make a <READ TABLE wt_table
WITH KEY field1 = wv_field1 BINARY SEARCH> because the data research will be
performed by dichotomy and not sequentially.
The ASCENDING sort on the reading key is compulsory. Otherwise, the <READ TABLE
wt_table WITH KEY field1 = wv_field1 BINARY SEARCH> will give a bad result.
Data research by dichotomy
Sequential data research.

Forbidden except in the case of a small
internal table
READ TABLE wt_table
WITH KEY field1 = wv_field1.
An ascending sorting on the reading

key of the table is compulsory.
READ TABLE wt_table
WITH KEY field1 = wv_field1
BINARY SEARCH.
Tips to use the <read table> instruction inside a loop

<READ TABLE> without
<BINARY SEARCH>
LOOP AT wt_table1.
(or loop from index, loop where, do)
Treatment.
READ TABLE wt_table2
WITH KEY key.
IF sy-subrc = 0.
Treatment1.
MODIFY wt_table2 INDEX sy-tabix.
ELSE.
Treatment2.
APPEND wt_table2.
ENDIF.
Treatment.
ENDLOOP.
Sort inside a loop.

LOOP AT wt_table1.
(or loop from index, loop where, do)
Treatment.
SORT wt_table2 BY key.
WITH KEY key BINARY SEARCH.
IF sy-subrc = 0.
Treatment1.
ELSE.
Treatment2.
APPEND wt_table2.
ENDIF.
Treatment.
ENDLOOP.
Page 28 of 38
A good solution
SORT wt_table2 BY key. (if wt_table2 is not empty)
LOOP AT wt_table1. (or loop from index, loop where, do)
Treatment.
READ TABLE wt_table2 WITH KEY key BINARY SEARCH.
IF sy-subrc = 0.
Treatment1.
ELSE.
Treatment2.
INSERT wt_table2 INDEX sy-tabix.
ENDIF.
Treatment.
ENDLOOP.
9.2. Declaration of an internal table

During the declaration of the internal table the <OCCURS> perimeter must usually be equal to 0
except if we know the total number of records of the internal table. If this amount multiplied by the
record size is less than 8000, it is advised to take the value of the total number of records.
9.3. Loop
The ABAP/4 language possesses instructions, which permit to manage the control breaks in internal
tables.
Control breaks
The instructions between <AT > and <ENDAT> are executed only:
AT FIRST
AT LAST
AT NEW
AT END OF
In the first pass within the <LOOP>.

At the end of the treatment for the last record on the internal table.
At the beginning of each control break on the specified zone after the word <NEW>.
At the end of each control break on the specified zone after the word <END OF>.
The tables must be sorted before using <AT NEW> and <AT END OF> instructions.
For SAP, the <AT NEW / AT END OF> instructions are executed only if there is at least a
byte which changes its value between the first byte of the buffer in the table and the last
byte of the specified zone in the <AT NEW/AT END OF>.
Example:
Given an internal table declared as follows:
END OF wt_table.
If we code <AT NEW/AT END OF field2>, it is sufficient that the value of the field1
changes so that the instructions associated to the break on field2 could be executed.
Page 29 of 38
9.4. Nested loops

Basic nested LOOP
Basic nested LOOP
LOOP AT wt_table1.
LOOP AT wt_table
Treatment.
ENDLOOP.
ENDLOOP.
A basic nested loop is forbidden.
Nested LOOP with the WHERE clause

Principle
At each reading of wt_table1, we entirely read the wt_table2 in spite of the WHERE clause.
- Firstly the SAP processor reads without buffering the records of wt_table2 located between the
first record of the internal table and the first records satisfying the WHERE condition.
- Secondly it reads by buffering the records of wt_table2 while the last records satisfy the
condition of the WHERE clause.
- If there are no more record satisfying this WHERE clause, the SAP processor exits the LOOP.
These three steps are carried out for all the records of the internal table tab1.
Performance
The method of nested LOOP with the WHERE clause is not performing. Consequently it is
forbidden to use it except when there is not another choice.
Nested LOOP with the WHERE clause
LOOP AT wt_table1.
LOOP AT wt_table2
WHERE field = wt_table1-field.
Treatment.
ENDLOOP.
ENDLOOP.
Nested LOOP FROM index with a key-field

Principle
The principle of this method is not to read again the totality of the second internal table for each
record of the first internal table, by keeping the position of the last read record in the second internal
table.
For each reading of wt_table1, we do not loop entirely on wt_table2. Indeed after each reading of
wt_table2 we keep the pointer position from the internal table, which permits to read wt_table2
from the last position, read in wt_table1. Therefore wt_table2 is not read more than twice.
Nested LOOP FROM index with one key field
DATA: BEGIN OF
field1
field4
field5
wt_table1 OCCURS
0,
LIKE wt_table1_key,
LIKE table4-field4,
LIKE table5-field5,
Page 30 of 38

END OF wt_table1.
DATA: BEGIN OF wt_table2 OCCURS
0,
field1 LIKE wt_table1_key,
field6 LIKE table6-field6,
END OF wt_table2.
wv_index = 1.
LOOP AT wt_table1.
Treatment.
LOOP AT wt_table2 FROM wv_index.
IF wt_table2-field1 > wt_table1-field1.
wv_index = sy-tabix.
EXIT.
ELSE IF wt_table2-field1 = wt_table1-field1.
Treatment.
ENDIF.
ENDLOOP.
Treatment.
ENDLOOP.
Nested LOOP FROM index with several key-fields

If several fields compose the common key of the two tables, it is necessary to write the program
differently. In this case, the key is no longer composed of one field, but a sub-structure. It enables to
make tests on the sub-structure as if it was one field.
Nested LOOP FROM index with several key fields
Page 31 of 38

DATA: BEGIN OF wt_table1,
field1 LIKE ,
field2 LIKE ,
field3 LIKE ,
field4 LIKE ,
field5 LIKE ,
field6 LIKE ,
END OF wt_table1.
DATA: BEGIN OF wt_table2,
field1 LIKE ,
field2 LIKE ,
field3 LIKE ,
field4 LIKE ,
field5 LIKE ,
field6 LIKE ,
END OF wt_table2.
DATA: BEGIN OF ws_struct1,

field1 LIKE wt_table1-field2,
END OF ws_struct1.
DATA: BEGIN OF ws_struct2,
END OF ws_struct2.
SORT wt_table1 BY field2 field4 field6.

SORT wt_table2 BY field2 field4 field6.
wv_index = 1.
LOOP AT wt_table1.
ws_struct1-field1 = field2.
IF ws_struct1 = ws_struct2.
Treatment.
ELSEIF ws_struct2 > ws_struct1.
Exit.
ENDIF.
ENDLOOP.
ENDLOOP.
ws_struct1 (and ws_struct2) must be the key of the table. But, if several records can have
the same value for the field of the FROM clause, we must write:
Nested LOOP FROM index with several key fields.
Use: Several records can have the same value for the field of the
FROM clause.
DATA: BEGIN OF wt_table1_key,
END OF wt_table1_key.
0,
tab1_key LIKE wt_table1_key,
END OF wt_table1.
0,
tab1_key LIKE wt_table1_key,
Page 32 of 38

END OF wt_table2.
SORT wt_table1 BY tab1_key.
SORT wt_table2 BY tab1_key.
wv_index = 1.
LOOP AT wt_table1.
Treatment.
IF wt_table2-tab1_key = wt_table1-tab1_key.
Treatment.
ELSEIF wt_table2-tab1_key > wt_table1-tab1_key.
wv_index_tmp = sy-tabix.
EXIT.
ENDIF.
ENDLOOP.
AT END OF tab1_key.
wv_index = wv_index_tmp.
ENDAT.
Treatment.
ENDLOOP.
The index is here memorized in a temporary variable. The variable index is only updated when all
the records having the same value for the field tab1-tab1_key have been processed.
<LOOP FROM index> or <LOOP AT NEW with READ TABLE>?

If there is a common field to sort the tables, we use <nested LOOP FROM index>. Otherwise
we use <LOOP AT NEW with READ TABLE>.
Nested LOOP FROM index
Use: Common fields between the tables
wv_index = 1.
LOOP AT wt_table1.
Treatment.
IF wt_table1-key = wt_table2-key.
Treatment.
ELSEIF wt_table2-key > wt_table1key.
EXIT.
ENDIF.
ENDLOOP.
Treatment.
ENDLOOP.
LOOP AT NEW
READ TABLE BINARY SEARCH
Use: No common fields between the tables
SORT wt_table2 BY field.
LOOP AT wt_table1.
AT NEW field1.
CLEAR wt_table2.
WITH KEY field = wt_table1-field2
BINARY SEARCH.
ENDAT.
Treatment.
ENDLOOP.
Nested LOOP with READ TABLE BINARY SEARCH

This method is useful in the case that wt_table1 is not sorted by field1. This case occurs when there
are already two nested LOOPs according to the previous method and we have to focus on the annex
data. By this method, we do not loop on the entire wt_table2 table but only on the desired data.
Page 33 of 38
Nested LOOP FROM

READ TABLE BINARY SEARCH
Use: wt_table1 is not sorted by field1.
SORT wt_table2 BY field.
LOOP AT wt_table1.
Treatment.
WITH KEY field = wt_table1-field1
BINARY SEARCH TRANSPORTING NO FIELDS.
IF sy-subrc = 0.
LOOP AT wt_table2 FROM sy-tabix.
IF wt_table2-field = wt_table1-field1.
Treatment.
ELSE.
EXIT.
ENDIF.
ENDLOOP.
ENDIF.
Treatment.
ENDLOOP.
Nested LOOP with a table of <sorted> Type (only up from 4.0 Release)
This method is similar to the previous one. The wt_table2 table being defined as sorted by field1
and field2 fields, the <LOOP WHERE> instruction is optimized in the same way as the <READ
BINARY SEARCH> method. In this case, the coding is easier to read and SAP generates an error if
the table is not correctly sorted.
Page 34 of 38
Performance
Deletions and modifications on a table of type <SORTED> are good in term of
performance (as a <READ TABLE BINARY SEARCH>).
But, insertions are very costly because the new records must be correctly positioned so
that the table remains sorted.
So it is not recommended to use this type of table. It is better to use a standard table with
a <READ TABLE BINARY SEARCH> statement for example.
Nested LOOP
with a sorted table
DATA: wt_table2 LIKE SORTED TABLE OF ws_struct
WITH UNIQUE KEY field1 field2
WITH HEADER LINE.
LOOP AT wt_table1.
Treatment.
LOOP AT wt_table2 WHERE field1 = wt_table1-field1.
Treatment.
ENDLOOP.
Treatment.
ENDLOOP.
It is necessary to use the instruction <INSERT TABLE wt_table2> to keep the table
sorted and not to have a duplicate key.
LOOP AT wt_table ASSIGNING <fs> (only up from 4.6 Release)

Up from the 4.6 release it is possible to use the < LOOP AT itab ASSIGNING <fs>> instruction.
In this case, the field symbol directly points to the line of the table. It is therefore possible to
directly modify a record without copying it in the header line and update it afterwards.
Up from the 4.6 release.
DATA: BEGIN OF wt_table1 OCCURS 0,
END OF wt_table1.
FIELD-SYMBOLS: <fs_tab1> LIKE wt_table1.
LOOP AT wt_table1 ASSIGNING <fs_tab1>.
<fs_tab1>-field1 = value1.
<fs_tab1>-field2 = value2.
Treatment.
ENDLOOP.
This instruction is more costly than a classical <LOOP MODIFY ENDLOOP> because it
requires a time to maintain the table. This solution is good to use only if lots of data must be
updated in the table.
The READ instruction has a similar coding: READ TABLE wt_table ASSIGNING <fs>.
Page 35 of 38
Comparative study of performance

Type of loop
Performance
(1=high, 7=low)
Nested LOOP FROM index

with one key field
Nested LOOP with several
key fields
Nested LOOP with READ
TABLE BINARY SEARCH
LOOP AT NEW READ
TABLE BINARY SEARCH
Nested LOOP WHERE with
SORTED TABLE
Commentary
The execution time is proportional to the

number of records processed.
Use: one field composes the common key of
the tables.
Use: several fields compose the common key
of the two tables.
Use: A table cannot be sorted.
Use: no common fields to sort the tables.
Nested LOOP WHERE
Basic Nested LOOP
The table is defined as a sorted table.

Not recommended.
The execution time is exponential to the
number of records processed.
Forbidden.
Forbidden.
9.5. Form/ Perform

The use of <FORM> enables to organize the program to make it more readable, easier to maintain,
with appropriate names easier to understand.
The <FORM> instruction permits to add on parameters during the function call. A parameter is a
variable. Therefore the conversion is important. That is why, if a <FORM> is used and has
parameters, it is advised to standardize the different parameters as often as possible in order to
avoid the conversions that are very costly in time for the SAP processor. The <ANY> type is not a
real type.
DATA: wv_var TYPE i.
DATA: wv_var TYPE i.
LOOP AT wt_table.
PERFORM add1 USING wv_var.
ENDLOOP.
LOOP AT wt_table.
PERFORM add1 USING wv_var.
ENDLOOP.
FORM add1 USING param.

ADD 1 TO param.
Treatment.
ENDFORM.
FORM add1 USING param TYPE i.

ADD 1 TO param.
Treatment.
ENDFORM.
Page 36 of 38
10. High-level performance

In this section, some methods will be presented. These methods can be used ONLY in EXTREME
CASES, i.e. when there are big problems of performances or/and very large volumes.
10.1. Hashed tables

Principle
The access to a hashed table is only made by a unique key thanks to a hashed algorithm.
Advantage
The time required to read a hashed table is independent of the number of read records. Therefore
hashed tables are very useful for voluminous tables which are often accessed for reading.
Drawbacks
Sorting a hashed table is impossible.

The key must be complete when we do a research.
The reading of a hashed table is carried out by the <READ TABLE

wt_table WITH TABLE KEY>.
A hashed table is quick in reading; otherwise there is a not lot of uses.
It is impossible to read/ insert/ modify a record in a hashed table by
using an index.
Example
DATA wt_table TYPE HASHED TABLE OF ws_struct
WITH UNIQUE KEY key
[INITIAL SIZE n] [WITH HEADER LINE]
Performances
The cost of a <SELECT INTO TABLE> is the same with a standard internal table or a hashed table.
But the time for reading a hashed table is less than or equal to the time required for a standard table.
A document is available on this subject:
-
Hashed_tables.doc
10.2. Buffering
Buffering a table is forbidden in most of the cases. However, in some cases and when a good
optimization is important, we can use it. The particular case is the following one:
transparent or pool table,
AND access to the table by reading,
AND a lot of queries to the table,
AND access by primary key (or a part of it),
AND few data updating.
Page 37 of 38
More comprehensive documents are available:
general_buffering.doc
single_record_buffering.doc
AxxxTables_buffering.doc
10.3. Indexing
In most of the cases, the creation of an index is not recommended because we must be very careful.
An index can be created when there is no more solution. Each creation must be studied
individually.
The Trace SQL tool permits to check the use of an index.
10.4. PERFORM
The use of <PERFORM> is very important for the program structure. But it is costly. Therefore, if
there are big performance problems, it is advised to avoid using <PERFORM>.
10.5. Use of the database server

In most of the cases, it is advised to use the application server (to sort a table, join two tables...). But
if there is a particular big problem in one program, it is advised to use the database server.
The use of a sub-query can be good in the case of a query needs to do intermediate selections in the
tables and these intermediate data are not useful for following treatments.
Page 38 of 38

CEN Com IT MET ABAP Recommending Performances V2

Uploaded by

Copyright:

Available Formats

CEN Com IT MET ABAP Recommending Performances V2

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CEN Com IT MET ABAP Recommending Performances V2

Uploaded by

Copyright:

Available Formats

KHEOPS CORE MODEL INTERNATIONAL

KHEOPS CORE MODEL INTERNATIONAL

KHEOPS CORE MODEL INTERNATIONAL

DATABASE SERVER / APPLICATION SERVER........................................................................................6

SELECTION ON ONE TABLE............................................................................................................7

SELECTION ON MANY TABLES....................................................................................................13

LOGICAL DATABASE (LDB).............................................................................................................13

COMMIT AND ROLLBACK.............................................................................................................20

REMARKS ON SOME INSTRUCTIONS.........................................................................................27

<READ TABLE> INSTRUCTION....................................................................................................27

KHEOPS CORE MODEL INTERNATIONAL

USE OF THE DATABASE SERVER..................................................................................................37

KHEOPS CORE MODEL INTERNATIONAL

THE PERFORMANCE OBJECTIVE IS NOT TO WRITE A PROGRAM

KHEOPS CORE MODEL INTERNATIONAL

2.2. Notations in the algorithms

KHEOPS CORE MODEL INTERNATIONAL

3.2. Data loading in internal table

3.3. Test of the return code

3.4. Authorized tools/ Forbidden tools

Forbidden tools (by descending order of prohibition)

Except in the case of only one record

KHEOPS CORE MODEL INTERNATIONAL

KHEOPS CORE MODEL INTERNATIONAL

4. Selection on one table

WHERE field1 = xxx.

Use : field1 is not the

Use : field1 is the primary key or

number of selected fields

Use: Selection of a limited

SELECT SINGLE field1

4.2. The <WHERE> clause

KHEOPS CORE MODEL INTERNATIONAL

Put the fields in the same order of the key

Put the fields in the same order of the existing index

Put the tests the most restricted in first position

LOOP FROM wt_table

4.3. The <SELECT> instruction

Sorting on the application server.

KHEOPS CORE MODEL INTERNATIONAL

Treatment without storing the

<INTO TABLE> option

<APPENDING TABLE > option

<[] CORRESPONDING FIELDS OF []> options

KHEOPS CORE MODEL INTERNATIONAL

Not recommended use of <INTO CORRESPONDING FIELDS OF>

DATA : BEGIN OF ws_struct,

SELECT SINGLE field1 field2 field3

DATA : BEGIN OF wt_table OCCURS 0,

SELECT field1 field2 field3

Use: Storage of data into a empty table. .

KHEOPS CORE MODEL INTERNATIONAL

Use: Addition of data into a no-empty table

<FOR ALL ENTRIES IN> option

To use the <FOR ALL ENTRIES IN> option:

The internal table must not be empty.

delete the duplicates.

KHEOPS CORE MODEL INTERNATIONAL

4.4. Information structures