Abap Details - Sap Hub

ABAP Basics
Data Types and Data Objects
We differentiate between data objects and data types in ABAP. Data types are mere descriptions that are not linked with
an address in the memory. Data objects are instances of data types and occupy memory to store the specific data that a
program uses at runtime.
You can define data objects in a program using the DATA statement. As shown in the figure, the name of the data object
is followed by a TYPE addition. The type is linked to the data object statically and cannot be changed at runtime.
Other syntax variants are available (for legacy reasons). Some of these legacy variants are no longer supported within
classes.
You can declare data objects using the following:
 Predefined ABAP types

The ABAP runtime environment provides predefined data types. Incomplete types (C, N, P, and X) and complete
types (I, F, D, T, STRING, XSTRING, DECFLOAT16, and DECFLOAT34) are differentiated depending on whether
the system requires an additional length specification when you declare the corresponding data objects.
 Global data types

Global data types refer to predefined Dictionary types, which largely correspond to the predefined ABAP types.
 Local data types

The TYPES statement defines local data types within the ABAP program. The local data types refer to predefined
ABAP types or global data types from the Dictionary.
Predefined ABAP Types
Numeric ABAP Data Types
SAP Locking Page 1 of 146

The following table lists the numeric ABAP data types:
Data Type Description Length in Bytes/Initial Length Value Range Decimals
-2,147,483,648 -
I Integer 4 0
+2,147,483,647
1 ... 16 Digits: 2*Length-1

P Packed Number Up to 14
8 Decimals: up to 14
Max: +/- 1.79E+308

F Binary Floating Point Number 8 Min: +/- 2.22E-308 16
and 0
Max: +/- 1E+385

DECFLOAT16 Decimal Floating Point Number 8 Min: +/- 1E-383 16
and 0
Max: +/- 1E+6145

DECFLOAT34 Decimal Floating Point Number 16 Min: +/- 1E-6143 34
and 0
Note that data types DECFLOAT16 and DECFLOAT34 exist as of SAP NetWeaver 7.0 EhP2 as a replacement for data
type F.
The numeric ABAP data types differ in the following ways:
 Rules for storage

 Value range
 Arithmetic used in calculations
Predefined ABAP Types - Character Types
Character ABAP Types

The following table lists the character ABAP data types:
Data Length in
Description Initial Value Additional Information
Type Bytes/Initial Length
Sequence of 1 … 65535 LENGTH addition can be used to specify

N 0…0
digits 1 length if default length of 1 not required

Data Length in
Description Initial Value Additional Information
Type Bytes/Initial Length
1 … 65535
Sequence of LENGTH addition can be used to specify
C Space
characters 1 length if default length of 1 not required
-Length fixed
00000000
D Date field 8
(YYYYMMDD) -Date calculations possible
-Length fixed
T Time field 000000 (HHMMSS) 6
-Time calculations possible
0…
Sequence of
STRING -Length variable
characters 0
Predefined ABAP Types - Byte Types
ABAP Byte Types

The following table lists the ABAP byte types:
Initial Length in
Data Type Description Additions
Value Bytes/Initial Length
Sequence of bytes in 1 … 65535 LENGTH addition used to specify length if

X 00 …
hexadecimal notation 1 default length of 1 byte not required
0…
Sequence of bytes in
XSTRING -Length variable
hexadecimal notation 0
Predefined Data Types
The tables above list all the elementary predefined data types provided by the ABAP runtime environment. You can use
the complete types (I, F, DECFLOAT16, DECFLOAT34, D, T, STRING, and XSTRING) to type a data object directly.
Supplement the incomplete types (P, N, C, and X) with a length specification to create a complete type. You can specify
the length in the DATA or TYPES statement, usually by using the LENGTH addition. For example:
TYPE <type_name> TYPE <ABAP-Type> LENGTH <length>.
DATA <obj_name> TYPE <ABAP-Type> LENGTH <length>.
TYPE <type_name>(<length>) TYPE <ABAP-Type>.

DATA <obj_name>(<length>) TYPE <ABAP-Type>.
Use the DECIMALS addition to define the number of decimal places for type P (packed number).
The numeric data types (I, F, P, DECFLOAT16, and DECFLOAT34) differ primarily in their value ranges, and in the
arithmetic used for calculations.
The major differences among the character data types (N, C, D, and T) are as follows:
 The characters that can be used to form the strings of these types
 The way they are formatted when output to the screen
 Data objects with types D and T are handled in a special way in arithmetic operations
A primary attribute of the string data type is that data objects with this type have variable lengths. The runtime system
adjusts this length to the respective contents dynamically at runtime.
Each predefined data type has its own initial value. This type-specific initial value plays an important role in instantiating
the data objects and executing the CLEAR statement. All numeric data types have 0 as their initial value. The character
data types N, D, and T have a sequence of character 0 as their initial value, while type C has a sequence of spaces. The
variable-length data types have length 0 in their initial state.
Generic ABAP Types
Predefined Generic ABAP Types

The following table lists the predefined generic ABAP types:
Generic Data Type Meaning Compatible ABAP Types
Fully generic
any Any type All
data Any data type All
Elementary, flat
Elementary data type or flat,

Simple All
character-type structure
Numeric
numeric Numeric data type I, F, P, DECFLOAT16, DECFLOAT34
decfloat Numeric data type DECFLOAT16, and DECFLOAT34

Generic Data Type Meaning Compatible ABAP Types
Character-type
clike Character data type C, N, D, T, STRING
csequence Text data type C, and STRING
Hexadecimal
Byte data type X, and XSTRING
xsequence
In addition to the predefined ABAP types, the runtime environment also provides predefined generic types. Generic types
do not completely define the attributes of a data object, and therefore they cannot be used in the declaration of data
objects.
Instead, generic types are used exclusively to type formal parameters (of subroutines, function modules, or methods) and
field symbols.
Data Object Categories
Data objects can be categorized as follows:
Type Reference Internal Structure Elementary Field

Table
At least one deep

Deep All All STRING and XSTRING
component
I, F, P, DECFLOAT16, DECFLOAT34, C, N, D, T,
Flat No No No deep components
and X
In terms of internal structure, you can distinguish the following data object categories:
 Elementary fields
 Structures
 Internal tables
 References
You can nest structures and internal tables to any number of levels. A structure that contains other structures as its
components, or even an entire internal table, is called a nested structure.
In terms of memory requirements and memory management, you can also differentiate between flat and deep data objects,
as follows:
 Flat data objects

Flat data objects have a static length and do not refer to other objects. All elementary data objects apart from strings
and all structures with exclusively flat components (regardless of potential nesting) are flat.
 Deep data objects

Deep data objects include references, strings, and internal tables. Structures are also called deep if they contain at
least one deep component, taking all includes and substructures into account.
Literals
Literals are data objects that you define in the source code of a program by specifying a string representing a value.
The ABAP runtime environment differentiates among the following types of literals:
 Numeric literals
You can define a numeric literal as a sequence of digits in the program text, with or without + or - signs. A numeric
literal has type I if its value lies within the value range of this type (-2^31+1 to 2^31-1), otherwise it has type P.
 Text field literals

You can define a text field literal as a character string that is enclosed in single quotation marks (') in the program
text. A text field literal can be from one to 255 characters long, and any spaces at the end are ignored. Text field
literals have type C.
 String literals
You can define a string field literal as a character string that you enclose in back quotation marks (`) in the program
text. String literals have the type string, and their length is limited to 255 characters. They can also have zero length.
In contrast to text field literals, spaces are not suppressed at the end of a string literal.
Hint: To display a single quotation mark within a text field literal, you have to enter it twice. The same applies if you enter
a back quotation in a string literal. No restrictions apply to single quotations in a string literal, or back quotations in a text
field literal.
Visibility of Data Objects in Procedural ABAP

The extent to which data objects are visible depends on the context.
The following rules apply for data objects that are defined using the DATA statement:
 If the DATA statement appears between FORM and ENDFORM, it defines a local data object of a subroutine.
 If the DATA statement appears between FUNCTION and ENDFUNCTION, it defines a local data object of a
function module.
 In all other positions, the DATA statement defines a global data object, which is visible in the entire program.
 If a global data object and a local data object have the same name, only the local data object is visible within the
modularization unit. In technical terms, it ignores the identically named global data object.
Caution: Data objects in modules and event blocks are always global. If the DATA statement appears between MODULE
and ENDMODULE, the object you define is still a global data object that is visible in the entire program. Likewise, data
objects that you declare in an ABAP event block are visible globally.
To avoid misunderstandings, SAP recommends that you declare such data at the start of the program, and avoid declaring
DATA statements completely in modules and event blocks.
The TABLES statement always creates data objects that are visible throughout the program. Data objects that you create
using the TABLES statement are always visible in the entire program, even if the statement appears within a subroutine or
function module.
Visibility of Data Objects in Object-Oriented ABAP
If you use objects (instances of ABAP classes) in your application, the visibility of data is determined in a different way.
Data objects that are defined in the declaration part of a class are called attributes.
For attributes, the visibility sections are as follows:
 Private attributes
Private attributes are visible only within the object or class. All the methods of the object can read and change the
data. External access to these attributes is possible only when you use a suitably defined method.
 Public attributes
Public attributes are also visible and accessible outside of the object or class.

 Protected attributes
Protected attributes are visible within the object or class, and also to instances of any subclasses.
If the DATA statement appears within METHOD..ENDMETHOD, it defines a local data object in the method.
Lifetime of Data Objects
The lifetime of a data object is usually linked with its visibility.

Global data objects remain valid as long as the corresponding program is in the memory.
The lifetime of object attributes begins when the object is instantiated at runtime and ends when the last reference to the
object has been deleted.
The lifetime of a local data object is usually identical to the lifetime of the surrounding modularization unit, which means
the contents of the data object are lost between two calls of the same modularization unit.
Hint: If you use the STATICS statement instead of DATA when you declare local data objects, the system extends their
lifetime to the overall program lifetime. Therefore, such data objects have the same lifetime as global data objects, but
their visibility is still limited to the respective modularization unit. You can use the STATICS statement in function
modules, subroutines, and static methods.

Statements, Functions, and Expressions for Simple Data
Statements and Functions in ABAP
The ABAP language originally had relatively limited support for expressions and was very imperative, leading to the need
for sequences of statements and intermediate variables to calculate results used in subsequent statements. The situation
has improved considerably over the last years, for example with the introduction of method call chaining, lots of new
built-in functions, string expressions with the new concatenation operator && combined with string templates, and the
ability to write expressions at many operand positions.
In SAP NetWeaver 7.40, ABAP has become even more expression-oriented. More expressions and more expression
positions are now possible. ABAP now supports inline data and field symbol declarations, constructor expressions and
table expressions.
This allows you to write ABAP code in a style that corresponds more to what you may be accustomed to in other
programming languages such as C or Java. It allows you to express more about “what” you want to calculate, and less
about “how” you want to calculate it. You do not have to write a statement for each intermediate step in the calculation
and therefore need fewer local variables which are only used once.
In the past, ABAP was a statement-oriented language. With Release SAP NetWeaver 7.02, ABAP took the first step
toward expression enabling.
An expression in a programming language like ABAP is a combination of constants, variables, operators, functions, and
values that is evaluated at runtime and returns a result. It can therefore be used in program statements in places where a
constant or variable could also be used.
Expressions and Inline Declarations
The following expressions can be constructed in certain operand positions:

 Writer positions include the following:
o Declaration expressions
o Certain constructor expressions
o Certain table expressions
 Reader positions include the following:
o Logical expressions
o Constructor expressions
o Table expressions
o Arithmetic expressions
o String expressions
o Bit expressions
Expressions are possible in both writer and reader positions.

An expression in a writer position produces a result to which a value is assigned, whereas an expression in a reader
position produces a result that is used as an operand in the statement. Logical expressions can contain calculation
expressions (arithmetic expressions, string expressions, and bit expressions) as relational expressions. The three different
calculation expression types cannot currently be mixed in a single calculation expression.
Inline Declarations
A very simple example of this is as follows. Without the use of inline declarations, you can write the following ABAP
code:

DATA text TYPE string.
text = ‘Hello World’.
Using an inline declaration, the code is written as follows:
DATA(text) = ‘Hello World’.
Inline declarations are a particularly interesting kind of expression. Inline declarations are a new way of declaring
variables and field symbols at operand positions.
In ABAP there are many operand positions, where the value of the operand is changed by the statement. One example of
these write positions is the left hand side lhs of an assignment:
lhs = rhs.
The data objects you can use at these write positions are either parameters of the procedure you are working in (for
example a method), or variables declared using the DATA statement.
In many cases the variables filled by a statement are “helper variables” that you only need temporarily. For each of these
helper variables you have to write a data declaration with the DATA statement and a suitable type.
However, the operand type of most write positions is fixed and known to the ABAP compiler. This is what makes inline
data declarations possible. Inline declarations involve the use of declaration positions (write positions with a fully known
operand type) and the new declaration operator DATA(...).
Potential Pitfalls of the Use of Expressions
One of the possible problems with the extensive use of expressions is that your ABAP code becomes very difficult to read
and understand.

Numeric Data Objects and Arithmetic Expressions
You can differentiate between the following data types:
 Type i
Integer arithmetic
 Type p
Fixed-point arithmetic
 Type f
Binary floating-point arithmetic
 Type DECFLOAT16 and Type DECFLOAT34

Decimal floating-point arithmetic
In this lesson, pure arithmetic expressions (that is, expressions in which all of the involved data objects have the same
type) are discussed first. Then, mixed arithmetic expressions and the way the runtime environment determines which
arithmetic to use is analyzed.
There are five numeric data types in ABAP, which differ in their inner representation of values and maximum value
range. Therefore, the data type that you choose for a data object depends on its required value range. In addition, each of
the five data types is linked to a specific type of arithmetic, which you can use for calculations involving data objects of
the respective type.
Integers and Integer Arithmetic
Calculations with integer arithmetic are faster than calculations with fixed-point or floating-point arithmetic because the
system executes them directly using the processor’s arithmetic command set.
The system rounds the non-integer results to the next whole number.

The system represents whole numbers with type i internally as binary numbers with a length of 4 bytes and they therefore
have a value range of -2 31 to 2 31-1.
Floating Point Numbers and Binary Floating Point Arithmetic
Floating point numbers are represented by binary precision floating point numbers. Floating point numbers are
normalized, and both the exponent and the mantissa are stored in binary form. This representation complies with the
Institute of Electrical and Electronic Engineers (IEEE) norm for double precision floating-point numbers (IEEE-754).
Caution: The binary floating point operations of the relevant processors are used for calculations in floating point
arithmetic. Because algorithms are converted to binary, inaccuracies can occur. The extent and effect of these inaccuracies
are difficult to estimate.

Example of a Floating Point Number
The following is an example that can give you a better understanding. Suppose you want to calculate 7.27% of 73050 and
display the result accurate to two decimal places. The answer should be 5310.74 (73050 * 0.0727 = 5310.735).
However, the program returns the following:
DATA: float TYPE f,
pack TYPE p DECIMALS 2.
float = 73050 * '0.0727'. " ==> 5.3107349999999997E+03
pack = float.
WRITE pack. " ==> 5310.73
Due to these effects, floating-point arithmetic is unsuitable for business calculations because business calculations have to
be exact and comply with legal rounding regulations. You should, therefore, use floating-point numbers only for
approximations. When you compare floating-point numbers, always use intervals and round up the values at the end of
your calculations.
The main advantage of floating-point numbers is their large range of values, from 2.2250738585072014E-308 to
1.7976931348623157E+308, including both positive and negative numbers and zero. In addition, you need to use
floating-point numbers for special aggregation functions of the SELECT statement.
Packed Numbers and Fixed Point Arithmetic

SAP introduced packed numbers in ABAP to expand the value range of decimal numbers, but avoiding the rounding
problems associated with floating-point numbers.
When you define packed numbers, you can determine the length of the number, specified in bytes. The system determines
the connection between the value range and the length from the internal representation of packed numbers.
Each decimal digit is represented by a half-byte; the last byte is reserved for the plus or minus sign.
The system derives the number of decimal digits from the number of bytes according to the following rule: n digits = 2
n bytes -1.
The DECIMALS addition determines how many of these decimal digits are handled as decimal places. The maximum
number of decimal places is 14. However, the number must contain at least one digit to the left of the decimal point.
Decimal point-aligned, fixed-point arithmetic is used for calculations. Packed numbers are therefore well-suited to
business calculations where the correct rounding to the specified number of decimal places is important. The algorithm for
this arithmetic is similar to using "pencil and paper". Interim results initially use packed numbers with 31 decimal places.
In case of an overflow, the entire expression is calculated again with an internal accuracy of 63 decimal places. If another
overflow occurs, an exception is raised, and can be handled.
Hint: You can switch off fixed-point arithmetic in the program attributes. If you do switch off fixed-point arithmetic, the
DECIMALS addition for defining a packed number affects only the output of the number. Internally, the system interprets
all numbers as integers, regardless of the position of the decimal point. Fixed-point arithmetic is active by default. You
should always accept this value and use packed numbers for business calculations.
Decimal Floating Point Numbers
The two kinds of decimal floating point numbers are as follows:
Type Memory Consumption Digits Range
Decfloat16 8 bytes 16 +/- 1.0E-383 through +/- 1.0E385
Decfloat34 16 bytes 34 +/- 1.0E-6143 through +/- 1.0E6145
Decimal floating-point arithmetic is used for calculations using data objects of type DECFLOAT16 and DECFLOAT34.
The algorithm for this arithmetic is similar to using "pencil and paper". Interim results use numbers with 16 (decfloat16)

or 34 (decfloat34) decimal places. The largest number in the arithmetic expression defines the exponent. Numbers that are
too small (according to the exponent and the number of decimals defined by the type) are rounded.
If an overflow occurs when working with DECFLOAT16, the system calculates the entire expression again with an
accuracy and number range based on type decfloat34. The same applies if the number of decimals (16) is too small to
store the intermediate result without having to round. If another overflow occurs, an exception is raised and can be
handled.
SAP introduced decimal floating-point numbers in SAP NetWeaver 7.0 EhP2 to overcome the drawbacks of binary
floating-point numbers.
Type f data objects cannot represent every decimal number precisely due to the internal binary representation. Results of
calculations may depend on the platform, there is no rounding to a specific number of decimal places, division by powers
of 10 is inexact, and no uniform behavior exists across database systems.
Decimal floating-point numbers have a range larger than type f, while the calculation accuracy is identical to type p.
Mixed Arithmetic Expressions
An arithmetic expression can contain a mix of all the numeric data types. If an arithmetic expression contains at least one
data object with a numeric type, it can also contain character-type data objects, provided their contents can be interpreted
as numbers. The values contained in these character-type objects are converted to numeric type objects.
The system determines the arithmetic to be used based on the data types involved before it performs the calculation.
Different types of arithmetic have different degrees of internal accuracy. Thus, the same arithmetic expression can lead to
different results, depending on the data types involved. The examples in the figure illustrate this.
In order to determine the arithmetic, the system takes into account the data types of all operands along with the data type
of the result field. After determining the arithmetic, the system converts all operands to the numeric type that corresponds
to the chosen arithmetic. The system performs the calculations using these converted values and ultimately converts the
result to the desired result type.
Hint: Remember that conversions affect performance. To avoid conversions, ensure that all operands and the result field
have the same numeric type.
Arithmetic Used for Mixed Expressions
Rules to Determine the Arithmetic Used for Mixed Expressions

 The system uses decimal floating-point arithmetic if at least one operand or the result field is of data type
decfloat16 or decfloat34.
 The system uses binary floating-point arithmetic if at least one operand or the result field is of data type f and
none of the operands is of data type decfloat16 or decfloat34.
 The system uses fixed-point arithmetic, which is the default, if at least one operand or the result field is of data
type p and none of the operands or the result field is of data type f, decfloat16, or decfloat34.
 The system uses integer arithmetic in all other cases, that is, if all operands and the result field are of data type i.
Classical Statements for Character and Byte String Processing
All elementary data objects with a byte-type data type (x, xstring) are byte-type data objects. All elementary data objects
with a character-type data type (c, n, d, t, string) are character type data objects.
In non-Unicode systems, byte-type data objects, as well as all flat structures, can be handled in the same way as character-
type data objects. In Unicode systems, in contrast, you have to differentiate clearly between byte-type and character-type
data objects.
Moreover, you can only handle flat structures as character-type data objects if they consist entirely of character-type
components.
The figure provides an overview of the ABAP statements for processing character-type data objects.
In each of these statements, the operands are treated like type c fields, regardless of their actual field type. They are not
converted. All of the statements apart from TRANSLATE and CONDENSE set system field sy-subrc.
Note: As of SAP NetWeaver 7.0, the statement FIND replaces the statement SEARCH.

String and Byte Sequence Processing
With the exception of CONDENSE and OVERLAY, you can also use the statements listed in the figure Overview-
Statements for Character and Byte String Processing to process byte-type data objects. In a Unicode system, you have to
use the IN BYTE MODE addition to ensure that each byte is examined individually, and not in pairs.
The corresponding IN CHARACTER MODE addition is optional for processing character-type data objects.
Subfield Access
You can access a fragment of a character-type or byte-type data object directly by specifying the appropriate offset and
length.
The specifications for length and offset are interpreted as numbers of bytes for byte-type data objects, and as numbers of
characters for character-type objects (that is, one or two bytes, depending on the system setting).

Access with Offset and Length Specifications for Structures
In flat structures, offset access is possible even if they are not completely character-type (that is, only the first field(s) are
character-type), provided the access does not go beyond the character-type area.
Caution: If possible, avoid using this method to access structure contents. Using components and string operations makes
your program much more reliable and easier to read.
Logical Operators
The following operators are available to compare the content of character-type data objects: CO, CN, CA, NA, CS, NS,
CP, and NP. With the introduction of Unicode, corresponding operators with the prefix BYTE- are available for byte-type
data objects.
Date and Time Fields

ABAP uses separate data types for dates and times. They are character-type data types that consist of eight and six
numeric characters, respectively. However, these data types also have a number of special attributes.
The special attributes are as follows:
 For input and output, the preferences for the current users are taken into account for formatting of the data.
 If a data object with type D is used in arithmetic expressions or assigned to a numeric data object, its contents are
converted to the number of days since January 1, 0001.
 If a data object with type T is used in arithmetic expressions or assigned to a numeric data object, its contents are
converted to the number of seconds since midnight.
Caution: If you have to specify start values for date or time fields (in the VALUE addition of the DATA statement), the
value must be supplied as a text literal. This is because numeric literals have type I, which means they would be
interpreted incorrectly as the number of days.
String Functions
As well as ABAP statements, predefined ABAP functions can be used to analyze character strings and byte strings.
ABAP functions are divided into three groups as follows:
 Descriptive functions (returning a numeric result)

 Processing functions (returning a character-type result)
 Predicate functions (returning TRUE or FALSE)
Predicate functions can only be used as conditions in control statements, as arguments of Boolean functions, or in
relationships with Boolean operators. Important descriptive string functions for character-type arguments can be used to
determine the length of strings, to find character patterns in strings, or to count the occurrence of character patterns in
strings.
To determine the occupied length of a string, use the standard function STRLEN( ). The corresponding function,
XSTRLEN( ), is available for byte-type data objects.

Examples of Processing Functions
As well as those displayed in the figure, the following processing functions are available:
 Cmax and cmin – return the values of the largest / smallest character-like argument
 Concat_lines_of – concatenates all row contents of an internal table and returns the result as a character string
 Escape - takes the content of a character string, and hides certain special characters with escape characters
according to a specified rule
 Match - returns a subfield of a character-like argument that matches a regular expression
 Repeat - returns a character string that contains content repeated as many times as specified
 Reverse – returns a reversed character string
 To_lower - converts all letters in the character string to lowercase letters
 To_mixed - converts all letters in the character string to lowercase letters from the second position
 From_mixed – inserts an underscore before each uppercase letter (from left to right and from the second position).
A different separator can be specified if an underscore is not suitable
 Translate – replaces characters in a character string
For full details about all of the processing functions, including their parameters and examples, see the ABAP Keyword
documentation.
Processing functions have a character-like result. They can be declared at general expression positions and character-like
expression positions. The return values have the type string.

Examples of Predicate Functions
Finally, two predictive functions exist: CONTAINS...() and MATCHES().

These can be used to find out if a certain substring or search pattern exists in a character string. MATCHES( ) accepts
regular expressions only, while CONTAINS...( ) also supports strings defining search patterns. In addition, CONTAINS...
( ) allows you to check for multiple occurrences of search patterns.
The code samples listed in the figure represent frequently used variants of these functions, but some of them contain
additional interface parameters not shown.
Depending on the function, the following interface parameters may be permitted:
 val: String to be analyzed.

 sub: Substring or search pattern.
 regex: Regular expression defining search pattern.
 off, len: Offset and length, used to restrict operation on segment of string.
 occ: Number of matches that are to be searched for in the search range (integer value). Counted from the right if
negative.
If invalid values are assigned to the interface parameters, catchable exceptions are raised.
See the ABAP Keyword documentation for full details of the interface parameters for each function.

String Expressions and String Templates
This section describes functionality available as of SAP NetWeaver 7.0 EhP 2.

A string expression formulates an operation with character-like operands. The result of a string expression is a character
string. A string expression consists either of one string template or of two or more operands concatenated as a character
string using the string operator && . Each of the operands can itself be a string template.
In operands with a fixed length, trailing blanks are not taken into account.
A string template is enclosed in two “|” characters. A string template defines a character string. The character string is
determined by any sequence of the following syntax elements:
 Text literals
 Embedded expressions such as, data objects, calculated expressions, predefined functions, or function methods
surrounded by { }
 Control characters
A string template that starts with “|” must be closed with “|” within the same line of source code. The only exceptions to
this rule are line breaks in embedded expressions.
String templates can only be specified in Unicode programs.
The data type of the expression must be an elementary data type and the value of the expression must be character-type or
must be convertible to a string.

Formatting Options for Embedded Expressions
Formatting Options that can be used in String Expressions
 Width-Output length (decreasing minimum length is not possible)

 Align-Output alignment (left, center, or right)
 Pad-Replacement sign for excess spaces in output string
 Case-Letter format (upper case, lower case, or raw)
 Sign-Visibility and position of sign in numeric type expressions
 Exponent-Exponent value for numeric expressions
 Decimals-Number of decimal places for numeric expressions
 Zero-Visibility of value 0 for numeric expressions (yes or no)
 Style-Output style for numeric expressions (for example, position of sign, usage of exponent)
 Currency-Number of decimal spaces when formatting expressions of type i, p, or f, valid values are defined in
database table TCURC, column WAERS
 Number-Format of decimal and thousand separators for numeric expressions
 Date-Format for expressions of type d
 Time-Format for expressions of type t
 Timestamp-Format for expressions of type timestamp or timestampl (both data elements defined in ABAP
Dictionary)
 Timezone-Time zone used to convert expressions of type timestamp or timestampl. Valid values are defined in
database table TTZZ, column TZONE
 Country-Country used to set format options number, date, time, and timestamp in one step.

When a string template is analyzed, the value of each embedded expression is converted to a character string. By default,
the string is formatted according to the data type of the expression (predefined formatting). However, a number of
formatting options can be used with the embedded expression. Formatting options have to be listed in the delimiting
characters ({, }) behind the expression.
Regular Expressions
Parsing and processing character strings is a frequent programming requirement. ABAP has for a long time provided a
range of functions to do this (for example, FIND, REPLACE, SPLIT, OVERLAY, SEARCH, and so on). In many cases, a
combination of various commands is necessary, mostly with IF queries and the use of loops.
With SAP NetWeaver 7.0, so-called regular expressions were introduced in ABAP to simplify string processing. They are
used to find and, if necessary, replace special character strings that correspond to a pattern in a character string.
Often, the structure of a character string you are analyzing cannot be described precisely, because parts of it are variable.
For this reason, patterns with special placeholders that represent certain characters or sequences must be used. Although it
was possible in the past to use patterns in ABAP for searching (when working with the SEARCH statement, * could be
used to represent any number of characters and + to represent any character), the options were limited and processing
more complex character strings was very complicated.

Special Operators used in Regular Expressions
A regular expression is a literal containing all kinds of characters. However, some characters or character combinations
have a special syntactical meaning.
Special Character Combinations to Describe a Single Character
To describe a single character, the following special character combinations can be used:
 . - Placeholder for single character

 \<c>-Placeholder for group of characters. Group depends on value of <c>. Example: \u = single upper case
letter, \d = single digit
 [ ]-Value set for single character. Example: [ABC] = ’A’, ’B’, or ’C’
 [^ ]-Negation of a value set for single character. Example: [^ABC] = not ( ’A’, ’B’, or ’C’)
 [ - ]-Value range for single characters. Example: [A-D] = any character between ’A’ and ’D’
 [[:<c>:]]-Description for group of characters. Group depends on value of <c>. Example: [[:upper:]] = single upper
case letter and [[:digit:]] = single digit
Additional Special Character Combinations to Describe a Character String Expression
Additional special character combinations to describe a character string by a regular expression include the following:
 {n}-Concatenation of n single characters. Example: ’A{5}’ = ’AAAAA’

 {n,m}-Concatenation of n to m single characters. Example: ’A{2,4}’ = ’AA’, ’AAA’, or ’AAAA’
 ?-One or no single character. Thus ? = {0,1}. Example: ’A?’ = ’A’ or empty string.
 *-Arbitrary number of characters (including empty string). Thus * = {0,}. Example: ’A*’ = empty string, ’A’,
’AA’, ’AAA’, ...
 +-Arbitrary number of characters (excluding empty string). Thus * = {1,}. Example: ’A+’ = ’A’, ’AA’, ’AAA’, ...
 |-Logical OR. Example: ’AB|CD’ = ’AB’ or ’CD’
 (?: )-Subgroup definition (without registration). An operator following the character combination acts on
subgroup. Example: ’AB(?:A|a)P’ = ’ABAP’ or ’ABaP’
 ( )-Subgroup definition with registration. In addition to simple subgroup definition, the character patterns
matching the subgroups are stored for latter reference. The matching pattern for subgroup n can be referred to using
the character combination \n. In text replacements, the character combination $n can be used to access the matching
pattern. Example: ’(>|-)ABAP\1’ = ’>ABAP>’ or ″-ABAP-″.
Examples of the use of Regular Expressions
Regular expressions can be used in the statements FIND and REPLACE.

String Functions that Support the Use of Regular Expressions
String functions that support the use of regular expressions include the following:
 COUNT ()
 COUNT_... ()
 CONTAINS... ()
 FIND ()
 FIND_... ()
 MATCH ()
 MATCHES ()
 REPLACE ()
 SUBSTRING ()
 SUBSTRING_... ()
One of the principle uses of regular expressions is the search for substrings in character strings. In general, a user is
interested in a specific selection of character strings that match a regular expression.
In ABAP, the search of regular expressions is realized using the addition REGEX of the statement FIND, whereby the
substrings found are determined without overlapping according to the leftmost-longest rule:
First, the substring is determined that is the furthest to the left in the character string, and that matches the regular
expression (leftmost). If there are several substrings, the longest sequence is chosen (longest). This procedure is then
repeated for the remaining sequence after the found location.
Special Character Combinations that Support Searching in a Character String
The special character combinations that support searching in a character string are as follows:
 ^ Anchor for offset before first character of line.

 $ Anchor for offset after last character in a line.
 \A Anchor for offset before first character of character string. If character string does not contain control
characters, \A and ^ behave identically.
 \z Anchor for offset after last character of character string. If character string does not contain control
characters, \z and $ behave identically.
 \< Begin of word.
 \> End of word. Example: ’(one)’ matched by ’one’ but also by ’done’ or ’lonely’. In contrast ’\<(one)\>’ is only
matched by ’one’
 • (?= ) Subsequent condition for previous regular expression. String has to match previous regular expression. In
addition, the substring following matching position has to fulfil subsequent condition. Example: ’(AB)(?=AP)’ is
matched by ’ABAP_BC402’ since ’AB’ is contained in literal and ’AP’ is contained directly behind ’AB’
 (?! ) Subsequent condition for previous regular expression. String has to match previous regular expression. In
addition, the substring following matching position must not fulfil subsequent condition. Example: ’(AB)(?!AP)’ is
not matched by ’ABAP_BC402’, the substring following ’AB’ matches the subsequent condition.
After searching, the replacement of substrings in character strings is the most important application of regular expressions.
When replacing, the found locations of a search (or the substrings that match a regular expression), are replaced by one or
more different character strings. The replacement is realized using regular expressions with the addition REGEX of the
statement REPLACE.
In contrast to normal text replacements, when you use regular expressions, you can use operators in the replacement text
that refers to the relevant found location.
Character Combinations that can be Used in the Replacement Text
The character combinations that can be used in the replacement text are as follows:
 $`-Complete text before current found location

 $'-Complete text after current found location
 $n-Character string stored in the register of subgroups for the n-th found location
 $&-Complete text
Internal Tables
1. Stores dynamic datasets in the main memory.

2. Internal tables are used for the buffering or formatting of contents from database tables.
3. The negative effects of inefficient accesses to internal tables for the overall system can be compensated more
easily than inefficient database accesses by adding further CPUs or application servers.
4. Inefficient database accesses affect the database as a central resource, whereas inefficient accesses to internal
tables impact the better scalable application layer.
When you define internal tables, you can select one of three table types: standard, sorted, or hashed. The table type
determines how an application can store and access data in the table.

Storage and access are simplest for standard tables. In terms of functionality, there is little difference between the standard
table type and other table types, except for the option of using unique keys. In fact, some access types that use indexes are
not possible with sorted and hashed tables.
The main reason for using sorted and hashed tables is not to gain additional features but to improve efficiency when
accessing large internal tables. An exception to this is the selection of a unique key for sorted tables.
Internal tables are among the most complex data objects available in the ABAP environment. The use of internal tables
lets you store dynamic datasets in the main memory. Internal tables are comparable to arrays and they spare the
programmer the effort of program-controlled memory management thanks to their dynamic nature. The data in internal
tables is managed per row, whereas each row has the same structure.
In most cases, internal tables are used for the buffering or formatting of contents from database tables. The type of access
to internal tables plays an important role for performance, as is the case with database tables. Experience shows that the
tuning of internal tables enables similarly major effects as the tuning of database accesses. The negative effects of
inefficient accesses to internal tables for the overall system can be compensated more easily than inefficient database
accesses by adding further CPUs or application servers. Inefficient database accesses affect the database as a central
resource, whereas inefficient accesses to internal tables impact the better scalable application layer.
The following sections first provide a general overview of the internal tables. This is followed by a description of how the
internal tables are organized in the main memory. The subsequent section discusses the different types of internal tables.
The major part of this chapter then details the performance aspects for the processing of internal tables.
Organization in the Main Memory
In the main memory, the internal tables, just like the database tables, are organized in blocks or pages. In the context of
internal tables, the following sections use the term pages.
When an internal table is declared in an ABAP program, the system only creates a reference (table reference) in the main
memory initially. Only when entries are written to the table does the system create a table header and a table body.
The table header has a reference to the first page of the table body and another reference to page management. Page
management manages the addresses of the pages in the main memory.
The table reference currently occupies 8 bytes of memory space. The table header occupies about 100 bytes of memory
space depending on the platform. The space required for page management depends on the number of pages.
The table body consists of pages that can include the table rows. The first two pages are — depending on the row length
and other factors — usually smaller than the pages 3 to n (if the row lengths are not so long that the maximum page size is
reached already at the beginning).

As of the third page, the pages are created with the maximum page size, which is usually between 8 KB and 16 KB. This
depends on the length of the row. Unlike database tables, the access is not per page but per row. So if you access a row of
an internal table, the system reads only one row. The effort for searching table entries (or data records) is comparable to
the database tables. For this purpose, the index or hash administration provides support for the internal tables.
The table header includes the most important information about an internal table. For example, you can quickly query the
number of rows using DESCRIBE TABLE <itab> LINES <lines> or the integrated function, LINES( itab ), from the table
header.
As very small internal tables with only a few rows can result in wastage due to the memory use of the automatically
calculated first page, INITIAL SIZE is added for the declaration of internal tables. It can provide information on the size
of the first page, so a smaller memory allocation than in the standard case occurs.
However, if considerably more rows are required than originally specified for INITIAL SIZE, the third page is created
faster with the maximum page size. For example, if 4 was specified for INITIAL SIZE, the third page may already be
required as of the 13th row if the second page is twice as large as the first page. Relatively few rows (13, for example)
require relatively much memory (three pages, third page with a size of 8 to 16 KB), whereas one page would have been
sufficient if a higher value (for example, 14) had been specified for INITIAL SIZE. Consequently, for small tables it is
important that INITIAL SIZE is not selected too small. Select a value that provides sufficient space in the first (or first
and second) page for most cases.
INITIAL SIZE should always be specified if you require only a few rows and the internal table exists frequently. For
nested tables, if an internal table is part of a row of another internal table, this is likely for the inner internal table. It can
also occur for attributes of a class if there are many instances of this class.
Caution: INITIAL SIZE and APPEND SORTED BY
In conjunction with the APPEND wa SORTED BY comp command, the INITIAL SIZE addition not only has a syntactic
but also a semantic meaning (see documentation). However, don’t use the APPEND wa SORTED BY comp command;
instead, work with the SORT command.
Depending on the table type or type of processing, you also require a management for the access to the row, that is, an
index for the index tables and a hash administration for the hashed tables. At this point, memory may be required for the
management of entries in addition to the pages. This management also occupies memory. Both in the Debugger and in the
Memory Inspector, this memory is added to the table body and not displayed separately. Compared to the user data, this
management can generally be neglected.
But how can you release allocated space in the internal tables again? The deletion of individual or multiple rows from the
internal table using the DELETE itab command doesn’t result in any memory release. The rows concerned are only
“selected” as deleted and not deleted from the pages.
Only when you use the REFRESH or CLEAR statements the system does release the pages of the internal tables again.
Only the header and a small memory area remain.
In this context, released means that the occupied memory can be reused. As the memory allocation from the Extended
Memory (EM) for a user is usually done in blocks (see Section 6.1 in Chapter 6), which are considerably larger than the
pages of an internal table, this is referred to as a two-level release. Release initially means that the pages within an EM
block are released and this space can then be reused by the same user. Only if the EM block is completely empty and
doesn’t contain any data (variables, and so on) of the user any longer is this block returned to the SAP memory
management and available for the other users again.

The FREE itab ABAP statement, however, results in the complete de-allocation of the table body, that is, all pages and the
index (if available) of the internal tables are released. Additionally, the table header is added to a system-internal “free
list” for reuse.
If an internal table should be reused, it is advisable to use REFRESH or CLEAR instead of FREE because this way the
creation of the first page can be omitted. If a large part of the rows of an internal table was deleted using DELETE and the
occupied memory should be released, it is recommended to copy the table rows. A simple copy to another internal table is
not sufficient because of table sharing, which is discussed in Section 7.4, Performance Aspects. Alternatively, you can
revert to ABAP statements (INSERT or APPEND) or to the EXPORT/IMPORT variants (see Section 6.2.2 in Chapter 6)
for copying. In the context of performance, the “release” of memory only plays a secondary role (as long as no memory
bottleneck exists in the system). In contrast to fragmented database tables, fragmented internal tables have no negative
effects on the performance because the entries can always be addressed efficiently because internal tables are always
managed per row.
Background: Difference between Internal Tables and Database Tables
Internal tables can be compared to database tables in many respects, but there is one major difference:
Internal tables are always processed on a row basis, whereas database tables are always processed on a set basis. A set-
based processing, possible with Open SQL on database tables, is not possible on internal tables because the single row is
the main processing criterion for internal tables, whereas a set of data records is the main processing criterion for database
tables. Set-based accesses to internal tables, for instance, LOOP ... WHERE or DELETE ... WHERE, are emulated by the
ABAP VM and can be mapped in an optimized way for some table types (see Section 7.4, Performance Aspects). More
complex, set-based operators, such as joins and aggregates,… are not possible on internal tables. They must be
programmed using the existing ABAP language techniques.
After you’ve learned about the organization of internal tables in the main memory, the next section focuses on the
organization of internal tables and discusses the different types of internal tables.
Access Time for Internal Tables
The figure illustrates how access time changes with the size of the table for the various table types. While access times are
similar when tables are small, the more lines that a table contains, the larger the differences become. A notable exception
is that the access times for key access to hashed tables are not dependent on table size.

Properties of Internal Tables
The following are the properties of an internal table:

 Line type: The line type describes the structure of table rows. The developer usually specifies a structure type for
that, but any data types are possible.
 Primary key: The primary key of an internal table consists of key fields in a particular order. The system uses the
sequence of the key fields, among other things, for sorting according to keys. Depending on the access type, the
primary key can be defined as unique or non-unique. Uniqueness means that a particular combination of key field
values can only appear once within the table.
 Table kind: Table kinds are of three types: standard, sorted, and hashed. Depending on the access type used, you
should use the appropriate table kind for the definition to enable high performance access.
Definition of Internal Tables
The type of an internal table is called a table type. Table types can be defined globally, in the ABAP Dictionary, or
locally, within a program.
The figure illustrates a table type declared in the ABAP Dictionary, as well as the program-internal definition of a table
variable with reference to the table type.

Definition of Internal Tables with Local Types
The figure illustrates a table type declared locally in the program as well as the internal definition of a table variable in the
program with reference to the locally declared table type.
When you list key fields in the table type, note that the sequence matters for certain types of processing (such as “sort by
key”). For detailed information about declaring local table types, refer to the keyword documentation for the TYPES
statement.
Hint: Instead of defining a table type first you can also define an internal table directly. All you have to do here is use
DATA instead of TYPES.
Caution: A common beginner’s error consists of the following syntax:
DATA gt_itab TYPE TABLE OF <Table type>.
This would result in the definition of an internal table with rows that are internal tables of the specified table type.
Possible Definitions of Internal Tables
Default Value for the Short Form of a Table Definition

 The short form of a table definition illustrated in the figure implicitly uses the following default values:
o Table kind – standard (default)
o Uniqueness of key – non-unique (only option for a standard table)

o Table key – default key (all non-numeric table fields are key fields)
Usage of Internal Tables
For processing single records of an internal table, a structure variable that has the same type as the line type of the internal
table is required. This structure variable is known as the work area.
The figure illustrates the processing of an internal table using the corresponding work area.
 The following statements are used to access single records of internal tables:
o APPEND appends the content of a structure to an internal table, and this operation can only be used with
standard tables.
o INSERT inserts the content of a structure into an internal table.
o READ TABLE copies the content of a table row to a structure.
o MODIFY TABLE overwrites an internal table row with the content of a structure.
o DELETE deletes a row of an internal table.
o COLLECT accumulates the content of a structure in row of an internal table that has the same key and in
doing so, only non-key fields are added. Therefore, this statement can only be used for tables whose non-key
fields are all numeric.
For detailed information about the ABAP statements described, refer to the relevant keyword documentation.

Processing of Sets of Records (Overview)
The following statements are used to access sets of records:
o LOOP AT . . . ENDLOOP places the rows of an internal table into the structure specified in the INTO
clause one-by-one. Within the LOOP, the current content of the structure can be output, or you can change
and write the current content back to the table.
o DELETE deletes all rows of the internal table that satisfy the logical condition <condition>.
o INSERT LINES OF copies the content of several rows of an internal table to another internal table.
o APPEND LINES OF appends the content of several rows of an internal table to another standard table.
The following figures are actual examples of syntax for the most common statements.

Syntax Example – Inserting a Row
Insert a row into an internal table by writing the data for the required record into the prepared work area and then inserting
it into the internal table with an INSERT statement.
With standard tables, this content is appended. With sorted tables, the row is inserted in the right place to keep the table
sorted by its key fields and, in hashed tables, it is inserted according to a hash algorithm.
Deletion of Table Content
Statements for Deleting Table Content

 You can use the following statements for deleting the table content:
o REFRESH-This statement deletes the entire content of the internal table. A part of the previously used
memory remains available for future insertions.
o CLEAR-This statement has the same effect as REFRESH for most internal tables (all those that have
been previously defined in the course).
For internal tables with header lines (see later), this statement only initializes the header line but does not delete the
table content.
o FREE-This statement deletes the entire content of the internal table and releases the previously used
memory. Use the FREE statement for internal tables that have already been evaluated and are no longer required in
the further course of the program. By this you make the no longer required memory available again.
Reasons for Not Using Tables with Header Lines
 You should no longer use tables with header lines for the following reasons:

o The automatically generated work area will have the same name as the internal table, which hinders
program readability.
o The table with a header line is not allowed in nested data objects (structures and internal tables that have
internal tables as components) and ABAP Objects (object-oriented extension of ABAP).
Example of Addressing the Body of a Table with itab
 You can address the body of a table with itab. The following example illustrates this situation:
 DATA itab1 TYPE TABLE OF scarr WITH HEADER LINE.
 DATA itab2 LIKE itab1.
 itab1 = itab2. "Operation only with header lines
itab1[] = itab2[]. "Operation with the table bodies
Example of Defining an Internal Table with the Header Line

 The following syntax also defines an internal table with the header line, even though that is not stated specifically:
 DATA: BEGIN OF itab OCCURS n,
 field1 TYPE ... ,
 field2 TYPE ... ,
 ... ,
END OF itab.
Internal tables with header lines are mentioned here because some older programs still use them and you have to work
with such programs from time to time. It is for this purpose that further particularities of the header line are listed.
If an internal table with header line is called "itab" you can use itab-comp to address component "comp" of the header line
(work area).
Standard Tables
Standard tables are managed internally using a table index (line numbers). You can append new lines at the end of the
table or insert them at specific positions. The lines within the internal table can be in any sequence and, consequently, the
system has to search the entire table sequentially during a key access. While this can be done relatively quickly for small
tables, the search effort increases linearly with the number of lines.
Note: If the internal table is explicitly sorted by using the SORT statement, the BINARY SEARCH addition can
significantly speed up access. This will be discussed later in the lesson.

Sorted Tables
You must never change the sort sequence of a sorted table, even temporarily. In many cases, the system automatically
ensures that the table contents are sorted correctly, such as when a sorted table is specified for a database access
after INTO TABLE or when a MOVE statement copies the contents of a table into a sorted table. The runtime
environment also ensures the correct sort sequence for key accesses.
Like standard tables, sorted tables are managed using a table index. The entries are always sorted in ascending order by
the table key. As a result, the system automatically performs a binary search during table key accesses.
Based on the total number of lines, the runtime environment determines an index in the middle and reads a line by index
access there. By comparing the key field values of this line with the search criteria, the system determines whether the
sought entry is before or after the current line. This step halves the data in a single step and is repeated until the sought
entry is found or the system determines that no entry in the table matches the criteria.
Hint: If the sorted table has a non-unique key, several lines could match the criteria. The result of sorting is that all lines
with the same key are in a contiguous block, and the system always returns the first line of the block, that is, the one with
the smallest index.

Hashed Tables
Hashed tables are managed internally using a hash algorithm. To enable this, a hash board is created in addition to the
actual table and the memory addresses of the table lines are managed in that table. Whereas the table contents are
completely unsorted, a hash function makes it possible to directly calculate the position of the entry in the hash board
from the key values. Accordingly, the key of a hashed table must always be unique.
The effort required to calculate the position in the hash board and then read the table line is identical for all lines,
regardless of the number of table entries. The entries in the hash board are not consecutive but are instead spread over a
certain memory area. These gaps make it possible to insert additional lines later. The hash function that is used determines
how large the gaps are. If the system calculates that the entries in the hash board are too close to one another when
inserting a line, it reorganizes the hash board. To do so, the positions are calculated with a different hash function that
distributes the entries over a larger memory area.
Hint: Loops (LOOP ... ENDLOOP) ignore the hash board and search the table contents directly. The content is unsorted,
but for this purpose, it can be sorted by using the SORT statement.

Index Access and Key Access
When working with the different table types, it is essential to understand the difference between index access and key
access. The system does not allow index access to hashed tables. You must be careful when using index access statements
that modify a sorted table, because doing so may violate the sort sequence, which causes a runtime error.
While the syntax check ensures that no index accesses are made to hashed tables, developers of sorted tables must be able
to spot index accesses that modify the internal table and avoid using them incorrectly.
Single Record Read Accesses
Single records from internal tables are read using the READ TABLE statement.
Index accesses are characterized by the INDEX addition, which specifies an explicit index. The INDEX addition is not
allowed for hashed tables. Key accesses can be performed with an implicit specification of the key (using
the FROM addition), and an explicit specification (using WITH (TABLE) KEY ). Keys can be either implicit or explicit
as follows:
 Key is implicit
When you specify the key implicitly, the key field values are taken from the structure after
the FROM addition. FROM and INTO do not need to have the same structure.
 Key is explicit
When the key is specified explicitly, the full table key can be specified using WITH TABLE KEY, or any other key
can be specified using the WITH KEY addition. If you use the WITH TABLE KEY addition, the syntax check
demands that all of the key fields in the table be listed and supplied with a value. If a key field is missing, this causes
a syntax error. If you use the WITH KEY addition, you can specify any column identifier. The syntax check does not
compare them with the key fields.
The addition does not have a direct impact on runtime. When accessing sorted and hashed tables, the system uses the
binary search or hash algorithm respectively, even if you use the WITH KEY addition. The only prerequisite is that you
must specify all the key fields.
By using the optional TRANSPORTING addition, you can copy selected columns instead of the entire line into the
specified structure defined in the program (after INTO).

Hint: If you use the special TRANSPORTING NO FIELDS addition, no data is read. Accordingly, INTO is not needed.
The system looks for a line with the specified index and/or key, setting the SY-SUBRC and SY-TABIX system fields
accordingly. This is an efficient way to check whether the table contains a specific line.
Single Record Write Access
There are various ways to modify records in internal tables, depending on whether you need to add a new entry, change an
existing entry, or delete an entry. The differences between index access and key access are particularly important because
index access statements that modify a sorted table can cause runtime errors.
Hint: In all single record write accesses by key, the keyword TABLE appears next to the name of the internal table (that
is, INTO TABLE, MODIFY TABLE, and DELETE TABLE). You cannot use this addition for single record write
accesses by index (that is, INTO lt_conn, MODIFY lt_conn, and DELETE lt_conn). Therefore, INDEX and TABLE are
mutually exclusive

Important Considerations for Specific Statements
Some important considerations for individual statements are as follows:
 DELETE by key
The table key is either implicit (FROM) or explicit (WITH TABLE KEY). WITH KEY is not supported. Depending
on the table type, the system searches for the line to be deleted sequentially, using a binary search, or hash algorithm.
 MODIFY by key
Only an implicit key can be used. Depending on the table type, the system determines which line is to be changed
sequentially, using a binary search, or a hash algorithm.
Only non-key fields are changed. The explicit specification of key fields after TRANSPORTING causes a syntax
error with sorted and hashed tables.
 INSERT by key
Only an implicit key can be used. For hashed tables, a line is appended to the table contents, an entry is added to the
hash board, and the table is reorganized if necessary. For sorted tables, a binary search determines the insert position.
For standard tables, it simply adds a line to the end.
 APPEND and INSERT by index

This statement is allowed for sorted tables, but only uses it if you are sure that the insert position is correct and the
sort sequence is retained. If in doubt, insert by key access.
 MODIFY by index
This statement also allows changes to key fields. This is risky for sorted tables because it potentially impacts the sort
sequence.
Using the optional TRANSPORTING addition with MODIFY works in a way similar to using READ TABLE to copy
only selected components to the desired line in the internal table.
Abbreviated Syntax for Index Access in Loops
When you perform single-record write accesses by index, you can omit the explicit index specification in a loop. In this
case, the system implicitly uses the current value from SY-TABIX. These syntax variants are only relevant within the
loops of the corresponding internal table and can only be used there.
Caution: The constraint that these statements can only be used within loops is not verified by the syntax check. If you use
them outside of loops, it causes a fatal exception (TABLE_ILLEGAL_STATEMENT).

Use of the WHERE Condition
You should be familiar with restrictions using WHERE from processing internal tables in LOOPs. You can also
specify WHERE conditions in special variants of MODIFY and DELETE.
Although key accesses are involved here, you should specify the internal table without the TABLE addition in these
statements.
If you combine MODIFY and WHERE, you must use the TRANSPORTING addition.
Accessing Standard Tables with WHERE

With the use of WHERE, the runtime required to locate the line depends primarily on the table type. In standard tables,
the entire table contents must be searched sequentially to find the required lines. The runtime requirement increases
linearly with the number of lines and can become large.
In hashed tables, the system ignores the hash board and searches the table contents completely.
Hint: The performance of hashed tables is not better than the performance of standard tables in mass accesses
using WHERE.
Accessing Sorted Tables with WHERE
In sorted tables, the system optimizes access automatically if the WHERE condition restricts the first n key fields to one
value, when a left-aligned, gap-free part of the key is specified. In this case, the desired entries are not scattered
throughout the table, but instead are in a contiguous block. In this case, the system uses a binary search to determine the
start of the block and then begins sequential processing from there. As soon as an entry that does not match the key fields
is reached, the system completes the block and immediately ends processing.
Hint: Mass access to sorted tables has better performance compared to other table types, as long as the WHERE condition
limits the first n key fields to one value.

Sorted Table with Unique Key
Sorted tables with a unique key represent a special application case of this table type. In this case, when you insert a new
line, the system immediately determines whether the table already contains a row with an identical key.
Hint: Ensuring unique keys does not impact performance. When a new line is inserted into a sorted table, the right insert
point needs to be found for non-unique keys as well.
Binary Search for Standard Tables

When sorted tables are accessed using their keys, the system performs a binary search to reduce the access time for large
tables. The BINARY SEARCH addition instructs the system to use a binary search during key access to standard tables.
Using a binary search during key access is helpful when the internal table is already sorted by the fields you use to restrict
access. However, as shown in the figure, using a binary search when the table is not sorted leads to incorrect results.
If the system performs a binary search on an unsorted table, the algorithm continues searching in the first half of the table
because it expects flight LH 0400 before LH 0402. In this case, because the table is not sorted, the sought entry appears in
the second half of the table and is therefore not found.
When using the BINARY SEARCH addition for key access to standard tables, the table must be sorted by the fields used
to restrict access. Otherwise, entries may not be found, even though they are contained in the table.
When calculating performance, you must remember to sort the internal table before performing the binary search, even
though sorting the internal table adds an extra step to the procedure. This extra preparation time is beneficial only if
several key accesses are performed with binary search.
You cannot optimize a single access with the BINARY SEARCH addition if you must sort the table specifically for that
access.
An explicit binary search also helps you design more efficient LOOP statements over standard tables. As a prerequisite,
you must sort the table by the fields restricted in the WHERE condition.
Improving Performance using BINARY SEARCH
As a result of the sort sequence, the entries that satisfy the WHERE condition are located in a contiguous block.
The READ TABLE ... BINARY SEARCH statement determines the position of the first item in this block through the
contents of system field SY-TABIX. Because the position is required only initially, the TRANSPORTING NO
FIELDS addition can be used.
If several entries satisfy the condition, READ TABLE always returns the first entry.
During the subsequent LOOP, the determined line is used as the starting point (the FROM addition). An explicit
termination (EXIT statement) ends processing as soon as the execution reaches a line that does not satisfy the condition;
that is, a line that lies outside the block.
Note: The source code has shown in the figure implements the same algorithm that the system automatically uses for
sorted tables.

Deletion of Duplicates
The DELETE ADJACENT DUPLICATES statement lets you remove duplicate lines from an internal table. The system
deletes all lines in which the contents of certain fields are identical to the contents of the immediately preceding lines.
In the example shown in the figure, the internal table contains several instances of multiple lines with the same value in
the CARRID column. The DELETE ADJACENT DUPLICATES statement retains the first line of each group in the
internal table and deletes all the others.
Caution: The comparison only compares adjacent table lines. The table must therefore be sorted by the comparison fields
if the statement is to find and remove all duplicates.
The COMPARING Addition

The COMPARING addition lets you control the fields that are compared by the system, using the following options:
 Without the COMPARING addition

The system compares contents of the key fields. This variant is only justified for internal tables with non-unique keys.
With unique keys, there cannot be two lines with the same contents in the key fields. The table must be sorted by the
table key.
 COMPARING col1 col2 ...

The system compares the contents of columns col1, col2, ... . You can specify any number of column names, as well
as any combination of key fields and non-key fields. For sorted tables, this variant is usually justified when you
specify the first n key fields.
 COMPARING ALL FIELDS

The system compares all fields. Therefore, it deletes only those lines that are identical to the preceding lines.
Subtotals during Insert (COLLECT)
The COLLECT statement is a special technique for filling an internal table. The system aggregates the table during the
insert operation.
If the table does not have a line with the same key yet, the COLLECT statement has the same effect as inserting by key
access. If the table already contains one or more lines with this key, the system sums the values of all non-key fields in the
new line to the corresponding values in the top line.
Hint: The COLLECT statement is only allowed when all non-key fields are numeric. The syntax check reports an error
when this prerequisite is not met.
The simplest way to ensure that all non-key fields are numeric is to define an internal table with a standard key (the WITH
DEFAULT KEY addition). The standard key is defined such that all non-numeric fields are key fields and all non-key
fields have a numeric type.
Aggregating an Internal Table with COLLECT

The figure illustrates how you can use the COLLECT statement to aggregate an existing internal table; that is, create
subtotals by group.
The COLLECT statement is a key access, which means you can use it for all three table types.
Caution: We recommend that you only use the COLLECT statement for sorted or hashed tables. Using the COLLECT
statement with standard tables results in poor performance because the system first sequentially searches the table to be
filled during each execution of COLLECT. Performance slows as the table becomes larger.
Definition of Secondary Keys
As of SAP NetWeaver 7.0 EhP2, it is possible to define secondary keys for internal tables. Secondary keys can be hashed
or sorted. A sorted secondary key can be unique or non-unique. The maximum number of secondary keys per internal
table is 15.
You can define secondary keys for table types in the TYPES statement or the DATA statement. For global table types in
ABAP Dictionary, a new Secondary Key tab is available.
You must specify a key name for each secondary key. The key name can be random, but must be unique for this table.

In addition to secondary keys, the syntax for defining the primary key has been enhanced. For compatibility reasons, all
additions are optional.
Access to Secondary Keys
The figure shows how you can use a secondary key in a processing statement by specifying the key name with
additions USING KEY key_name or WITH KEY key_name.
Secondary keys can be used in most processing statements, except for the following:
 APPEND
 INSERT (either key or index access)
 READ TABLE ... WITH TABLE KEY ...
 DELETE TABLE ... WITH TABLE KEY ...
A secondary key is not selected automatically. Unless you specify a secondary key during a processing statement, the
system always uses a primary key or primary table index. If you have defined a secondary key for a set of components but
do not use it within a processing statement that is coded for the same set of components, the syntax check issues a
warning.
Hint: When you use a sorted secondary key in an index access, the index you specify is applied according to the sort order
in the secondary key. After an access through a sorted secondary key, the SY-TABIX field contains the position of the
line in the secondary key.
In a key access (single record or with WHERE), the components in the condition must match the components of the
secondary key.
Update of Secondary Keys
The system does not always update the secondary keys immediately when you change the content of the internal table.
The system treats unique and non-unique secondary keys differently.
A non-unique secondary key is only created when it is used explicitly for the first time. After a write access to the internal
table, the update of the secondary key is delayed until the next statement that explicitly uses this secondary key. This type
of update is referred to as a lazy update.

Hint: As a consequence of the lazy update, the first access through a secondary key appears to be expensive in the
performance analysis tools.
Update of Unique Secondary Key Is Not Delayed
A unique secondary key forms a boundary condition for the internal table and is therefore treated differently.
For any write access that adds or removes lines, the secondary key is updated immediately. If the uniqueness is violated,
the system raises an exception that can be caught and handled (exception class CX_SY_ITAB_DUPLICATE_KEY).
For MODIFY statements that change the key fields of a unique secondary key, the system updates the secondary key
immediately. If the uniqueness of the key is violated, the system raises an exception that cannot be handled.
The system only delays the update of a unique secondary key for direct changes through field symbols or data references.
Unlike non-unique keys, the system updates the unique secondary key at the successive access to the internal table. In this
context, it is not necessary that this secondary key is actually used in this access.

Use of Secondary Keys
Use non-unique secondary keys because the system always delays the update and performs the update only when the
respective secondary key is actually used. In addition, when an internal table has a unique secondary key, any write access
to the table risks incurring runtime errors because of a uniqueness violation.
Be careful when using index operations. After an operation that uses a sorted secondary key, SY-TABIX returns the
position of the respective line in this sorted secondary key. To use SY-TABIX to address the line in a subsequent index
access, specify the same secondary key.
Recommendations for Using Secondary Keys
 Use secondary keys only when deployed often because they are expensive and pay back only when used
frequently.
 Use non-unique secondary keys as the update is always delayed and as there is no danger of runtime errors due to
duplicate entries. The secondary key is updated only when it is used.
 Remember that the sort order in secondary keys differs from the sort order in primary keys; SY-TABIX returns
the line index with the secondary key but not with the primary key. The secondary key should, therefore, be used in a
subsequent index access.
The following points are significant when considering the use of secondary keys:
 Do not neglect the additional costs of creating or updating the secondary key.
 Only use secondary keys when they are used often.
Hint: Building a secondary key is more expensive than sorting a standard table.
Data References
Use the dereferencing operator ->* to dereference statically-typed data objects directly. This means that the dereferencing
operator directly accesses the content of the data object that the reference is pointing to. For compatibility reasons, you
must dereference generically typed data references (TYPE REF TO data) and assign them to a field symbol, which you
then use to access the content.
When you type data references statically with a structure type, you can address the components of the referenced data
object directly. Components are addressed by using the component selector ->.
Data references and object references were introduced alongside field symbols as part of the enhancements in SAP R/3
4.6A. From this point on, ABAP features full “reference semantics”.
Data reference variables contain data references or pointers to data objects.
Use the TYPE REF TO addition for the TYPES statement to define a reference type for a data object. You can specify the
data type explicitly or choose the generic variation by using TYPE REF TO DATA. In this case, your data reference can
point to any type of data object.
The corresponding DATA statement defines the data reference variable. Reference variables are data objects that contain
the address of any other data object of the specified type.
Data references use reference semantics; that is, when a data reference variable is accessed, the data reference is
addressed. This means any changes to the data references affect the addresses.
Data reference variables are handled in ABAP like other data objects with an elementary data type. This means a
reference variable can be defined not only as a single field, but also as the smallest indivisible unit of complex data
objects such as structures or internal tables.

After a reference variable has been defined, it is INITIAL (empty), and thus contains a blank pointer. For a data reference
variable to contain a reference that points to a data object, use the statement GET REFERENCE OF to obtain a reference
to a data object that has already been defined.
You can also assign an existing data reference from another data reference variable or create a data object dynamically
with the reference.
Checking the Validity of References
Example:
DATA: gs_flight TYPE sflight,
gr_flight TYPE REF TO sflight.
GET REFERENCE OF gs_flight INTO gr_flight.
gr_flight->fldate = gr_flight->fldate + 5.
WRITE: / gr_flight->seatsmax.
In this case, the component selector corresponds to the hyphen for regular component access to structured data objects.
Validity of References – Logical Expression
... ref IS [NOT] BOUND ...
Use the expression ref IS [NOT] BOUND to query whether the reference variable “ref” contains a valid reference. The
reference variable “ref” must be a data reference variable or an object reference variable.
ref IS [NOT] INITIAL
Field Symbols
Example:
DATA: gv_date TYPE d VALUE '20040101',

gv_time TYPE t.
FIELD-SYMBOLS: <fs_date> TYPE d,
<fs_time> TYPE t.
ASSIGN: gv_date TO <fs_date>,
gv_time TO <fs_time>.
* possible?
<fs_time> = <fs_date>.
Use the expression IS ASSIGNED to find out whether the field symbol is assigned to a field. The
statement UNASSIGN sets the field symbol so that it points to nothing. The logical expression IS ASSIGNED is then
false.
Before the introduction of data references, field symbols were used in ABAP as dereferenced pointers. Field symbols
provide symbolic access to an existing data object. All accesses you make to the field symbol are made to the data object
assigned to that field symbol. Therefore, you can only access the content of the data object to which the field symbol
points. This technique is referred to as the value semantics of field symbols.
You declare field symbols using the FIELD-SYMBOLS statement. Note that the angle brackets (<>) in the field symbol
name are part of the syntax. Use the ASSIGN statement to assign a data object to the field symbol.
By specifying a type for the field symbol, you can ensure that only compatible objects are assigned to the field symbol.
Access to Internal Tables Using Data References and Field Symbols
Data references and field symbols provide new access options when combined with internal tables.
You can use the statements described in the figure to define field symbols and references that are capable of pointing to
individual lines in an internal table. This makes it possible to use these field symbols, or the dereferencing operator, to
access these records.
Field symbols and references point to the assigned row even after the internal table is re-sorted.
Unless there are compelling reasons to the contrary, always type the field symbols and references using types that are
compatible with the internal table. Generic types are also possible within the dynamic programming framework. However,
in such cases, you cannot use the CASTING addition.

Referencing During Read and Loop Processing
When you read a table row using READ TABLE or a series of table rows using LOOP AT, you can assign the rows of the
internal table to a field symbol by using the ASSIGNING <field_symbol> addition. The<field_symbol> field symbol then
points to the line that you assigned, allowing you to access the field content directly. Consequently, the system does not
copy the entry from the internal table to a work area and back again.
The restrictions for using this technique are as follows:
 You can only change the contents of key fields when the table is a standard table.
 You cannot reassign field symbols within the loop. The statements ASSIGN TO <fs_line> and UNASSIGN
<fs_line> cause runtime errors.
 You cannot use the SUM statement for control level processing.
The same restrictions apply for the variant REFERENCE INTO ref_name, which you can use to point a reference to the
lines.

This technique of using the variant REFERENCE INTO ref_name to point a reference to the lines is useful for accessing
multiple table lines or nested tables within a loop. Copying values to and from a work area in this kind of operation
significantly increases the runtime.
Note: These access techniques are also useful for dynamic programming.
References to Inserted or Changed Single Lines
If you use one of the three statements in the figure to exchange data with the internal table through a work area, you can
also use the optional additions ASSIGNING <field_symbol> and REFERENCE INTO ref_name to point a field symbol
or reference to the processed line.
Inline Declarations of Internal Tables
One group of expressions that can be useful when processing internal tables allows the inline declaration of data objects,
using an expression containing the DATA( ) operator. Because internal tables often go hand in hand with a work area to
allow the individual records to be processed, these inline declarations can be used for this work area.
The equivalent also works for field symbols using the FIELD-SYMBOL( ) operator.
Another particularly helpful group of expressions are table expressions.
Table expressions allow you to access table rows in a similar way to a READ TABLE statement, for example by
specifying the index of the row you want to access, or by specifying the value of a column. You can use table expressions
directly as part of statements, without reading into a work area first. You can also directly reference fields of the resulting
row and chain such expressions.
With table expressions and inline declarations, far fewer READ TABLE statements and individual local variables are
necessary to hold intermediate results, making ABAP code more readable.
Inline Declarations when Working with Internal Tables

The figure shows examples of the use of inline declarations of a work area when working with an internal table, and an
inline declaration of a field symbol in a loop.
From Statements to Table Expressions
The figure shows how relatively long and complicated ABAP code can be simplified through the use of table expressions.
Table Expressions
The internal table itab must be specified directly using its name, a field symbol, or a dereferenced data reference. The
structure component selector - can be used to access components of the row in question and direct chainings [ ... ][ ... ] of

multiple table expressions. Table expressions cannot yet, however, be specified on the left side of the object component
selector ->.
If the specified row is not found, a catchable exception of the class CX_SY_ITAB_LINE_NOT_FOUND is raised in all
operand positions, except in the following cases:
 When a table expression is used in the statement ASSIGN, where sy-subrc is set to the value 4
 When used in the predicate function line_exists, where the logical value false is returned
 When used in the table function line_index, where the value 0 is returned
Each table expression can be viewed as a short form for a variant of the statement READ TABLE that enables reads to be
performed on rows of internal tables in operand positions. Unlike READ TABLE, a table expression does not modify the
value of the system field sy-tabix. Like the statement READ TABLE, a table expression is a single row read. If multiple
rows of an internal table are to be read, the statement LOOP should be used.
A table expression consists of an internal table itab, followed directly by a row (itab_line) specified in square brackets [ ].
The expression finds the specified row in the internal table and returns it as the result of the corresponding row type,
which can be used as follows:
 Reader positions
o A table expression can be specified in general expression positions and functional operand positions with
an appropriate operand type. The result is used here as an operand. The category of the result can be controlled in
operand positions using constructor operators.
o A table expression can be specified as a special expression variant for the memory area in the statement
ASSIGN.
o A table expression can be specified as an argument of the table function line_index and the predicate
function line_exists.
 Writer positions
o A table expression can be specified as a writable expression in result positions. Once found, the row in
question can be modified directly here.
Table Expressions: Chaining

Not only can table expressions now be used, but they can also be chained. The figure shows an example of this.
Internal Tables: Built-in Functions
The table function line_index returns the number of the row found for the table expression specified. The return value has
the type i.
The predicate function line_exists checks whether the row of an internal table specified in the table expression exists and
returns the appropriate logical value.
ABAP Open SQL
Subselects and Subqueries
In this example, the subquery is supposed to return several lines, each with one value. If you want to compare all the
returned values, use IN. Subqueries whose WHERE condition contains fields from the main query are called correlated
subqueries. If subqueries are nested, each subquery can use all the fields from the higher-level subqueries in the hierarchy.
Query designers should formulate positive subqueries whenever possible; negative formulations may result in
performance-degrading database reads if no adequate index is available.
A subquery is a query within a SELECT, UPDATE, or DELETE statement. It is formulated in the WHERE or HAVING
clause to check whether the data in various database tables or views possess certain attributes.

A SELECT statement with a subquery has a more restricted syntax than a SELECT statement without a subquery.
If the subquery returns exactly one value, you can use the usual comparison operators apart from LIKE and BETWEEN.
If you use a subquery with a comparison operator instead of with EXISTS, then the SELECT clause of the subquery can
only contain a single column, which can be a field in the database table or an aggregate expression.
Parallel Cursors
Using the Open SQL statements OPEN CURSOR, FETCH NEXT CURSOR, and CLOSE CURSOR to program explicit
cursor handling with several database tables concurrently allows you to process the contents of multiple database tables in
parallel without using nested SELECTs.
In the example in the figure, you want the program to process all flights from database table SFLIGHT, and you want to
read the non-canceled bookings in the economy class for each flight from database table SBOOK and process the
bookings together with the flight. The obvious solution is a nested SELECT, but that solution is likely to have poor
performance.
Due to the large data volume involved, you do not want to buffer the bookings completely in an internal table.

Parallel Cursors Instead of Nested SELECTs
For this technique to work correctly, the following prerequisites must be met:
 Both tables must be sorted by the same criteria (ORDER BY clause).

 Every record in the outer table must specify exactly how many corresponding records exist in the inner table.
Rather than solving the problem with nested SELECTs, you can achieve the same result by addressing the two database
tables with two concurrently open database cursors.
Parallel cursors work as follows:
 Each fetch for the first cursor (cursor variable GV_CURSOR_SFLIGHT) places the next respective record from
database table SFLIGHT into structure GS_FLIGHT (similar to a SELECT loop).
 Each fetch for the second cursor (cursor variable GV_CURSOR_SBOOK) reads the corresponding non-canceled
economy bookings into internal table GT_BOOKINGS. However, these bookings are not actually selected based on
their key. Instead, the next n records are simply read. The value of n corresponds to the value of the seatsocc field in
the record for the flight. Because the selection results are sorted (ORDER BY clause), the next n bookings are the
bookings for the current flight.
Buffering Techniques
Avoiding database accesses in the first place is the simplest way to reduce database load. You can do this by taking table
contents that have already been read and saving them in an internal table (with type SORTED or HASHED, if possible).
In many cases, the application logic does not permit the use of joins. If you need to read data from multiple tables in such
cases, you can use a separate internal table to buffer the read data.
Read-On-Demand and Buffering

In the example, you want to read the matching data from STRAVELAG (travel agency master data) within a loop for the
bookings from table SBOOK. You can accomplish this with a SELECT SINGLE statement or a read routine. If you use
SELECT SINGLE in this approach, multiple identical SQL statements are executed. Therefore, it may be better to
encapsulate the reading of STRAVELAG records in a read routine. In the example, the table contents read from
STRAVELAG are buffered in a static internal table. Before each database access, the system checks whether the
corresponding table entry has already been read.
The read routine can also be a method of a local or global class instead of a subroutine. In this case, a private attribute of
the corresponding class would be used as buffer instead of the static internal table ST_TRAVELAGS.
FOR ALL ENTRIES Addition
The content of the internal table (driving table) is used as a restriction for the database access, and may depend on the
database system. In general, the database interface takes a certain number of entries in the internal table (in the example it
takes 5) and sends one native SQL statement to the database for each group. In the end, the results of the individual native
SQL statements are combined to form the result of the Open SQL statement. Duplicate entries are automatically removed.
Note that the size of the packages is controlled by a profile parameter.
If you want to read large data volumes, use FOR ALL ENTRIES only in exceptional cases.
SELECT … FOR ALL ENTRIES was created in Open SQL at a time when it was not possible to perform database joins
(this was not supported for all SAP-approved DBMS). The connection between the inner and outer database tables was
created in ABAP.
Nowadays, this technique is often used when some data is already available in an internal table, but additional data is to be
read from the database. In such cases, SELECT … FOR ALL ENTRIES replaces a SELECT SINGLE statement inside a
LOOP over the internal table, and normally shows better performance than such a LOOP.
As a possible scenario, use a program exit in which data can be added to an internal table provided by the standard SAP
program.
The figure illustrates an example of how the statement works.

Overview of LOBs in the Database
For normal access to Large Objects (LOBs), use the ABAP data object types string and xstring, into which the entire LOB
is transferred for read access, and from which the entire LOB is taken for write access. Depending on the string length,
this transfer may lead to high memory consumption on the application server. For certain operations on the LOB (for
example, copying the LOB within the database table or storing the LOB in a data object that is not of type string or
xstring), it is not necessary to realize the complete LOB in the ABAP program.
You can reduce memory consumption and improve the program performance with regard to runtime by omitting
unnecessary data transports. You do so by using streaming and/or locator objects (LOB handles).
Hint: SQL streams and locators are supported as of SAP NetWeaver 7.0 EhP 2.
Streams
For read access, read streams can be linked to LOBs using the assignment of corresponding streaming objects. The same
applies for write access and write streams. LOB data can be partially processed using the stream methods.
Specific Instances of ABAP Classes that can be linked to LOBs
 CL_ABAP_DB_C_READER
Can be linked to a large string (CLOB), located on a database table. Use this to read CLOBs sequentially.
 CL_ABAP_DB_X_READER
Can be linked to a large binary string (BLOB), located on a database table. Use this to read BLOBs sequentially.
 CL_ABAP_DB_C_WRITER
Can be linked to a large string (CLOB), located on a database table. Use this to write CLOBs sequentially.

 CL_ABAP_DB_X_WRITER
Can be linked to a large binary string (BLOB), located on a database table. Use this to write BLOBs sequentially.
To create a streaming class instance, use a reference variable in the appropriate SQL statement. To read streams, use the
reference variable in the INTO clause of the SELECT statement. An LOB from the result set can be assigned to an LOB
handle component of a work area, or, to an individual reference variable for an LOB handle.
After the execution of the SQL statement, the reference variable points to the LOB handle. The related class is determined
using the data type of the result set column and the static type of the target variable, or using the CREATING addition if
required. The LOB to be read can be evaluated or forwarded using LOB handle methods.
Create Stream Reader Object and Assign it to LOB (2)
The figure illustrates how to create a structure that contains a reference field for the stream reader, and how to assign the
reader to the LOB during selection.

Create LOB Handler and Assign it to LOB
Methods Defined to Read Streams
 DATA_AVAILABLE ( )
Check whether input stream is empty
 READ( <length> )
Read the next <length> bytes (characters) from the input stream
 SKIP( <length> )
Skip the next <length> bytes (characters)
 IS_CLOSED( )
Check whether data stream is closed
 CLOSE( )
Close data stream
 IS_MARK_SUPPORTED( )
Check whether setting a marker is possible
 SET_MARK( )
Set marker at current reading position
 RESET_TO_MARK( )
Position read cursor to marking position
 DELETE_MARK( )
Delete marker
 IS_RESET_SUPPORTED( )
Check whether jumping to the beginning of the LOB is possible
 RESET( )
Position reading cursor to beginning of LOB
 IS_X_READER( )
Check if stream is binary data stream or character data stream
 GET_STATEMENT_HANDLE( )
Get object describing SQL statement

The figure shows how to use one handle and, by using down-casting, how to refer a stream reading object or a locator
object assigned to an LOB.
Streams – Example
The figure illustrates an example of streams.

A maximum of 1000 LOB handles can be open in a database LUW (Logical Unit of Work).
Hint: Because the number of data streams open at one time is only limited to 16, close them as soon as possible using the
CLOSE method. Independently of this, read streams are closed implicitly at the end of a SELECT statement and at the
end of a database LUW. You can close an open write stream implicitly only by using a database rollback. Database
commits for open write streams, on the other hand, cause a non-catchable runtime error, COMMIT_STREAM_ERROR.
Locators

Specific Instances of Classes that can be linked to LOBs
 CL_ABAP_DB_C_LOCATOR
Can be linked to a large string (CLOB), located on a database table. Use these to get metadata related to the string, or
to read a subsequence of the string.
 CL_ABAP_DB_X_LOCATOR
Can be linked to a large binary string (BLOB), located in a database table. Use these to get metadata related to the
xstring, or to read a subsequence of the xstring.
The creation of a locator class instance and the assignment of this object to the LOB is similar to the situation for stream
reader classes and stream writer classes.
Important Methods Defined in the Locator Classes
 GET_LENGTH ( )-Returns the length of the LOB in characters or bytes

 FIND (start_offset = <off> pattern = <pat>)-Find first occurrence of pattern <pat> in string or xstring and begin
the search at offset <off>. Returns offset of find spot
 GET_SUBSTRING(offset = <off> length = <length>)-Return substring beginning at offset <off> and having the
length <length>
 IS_CLOSED ( )-Check whether data stream is closed
 CLOSE( )-Close data stream
For read and write access, you can link locators to LOBs by assigning the corresponding reference variables. Using the
methods of the locators, you can access the subsequences of LOBs or the properties of LOBs without requiring a complete
realization in the ABAP program. Furthermore, locators enable the copying of LOBs within the database without having
to transport the data between the database and the application server.
Locator Example – Copy BLOB within Database

This figure illustrates how a BLOB can be read and duplicated within the database.
Disadvantages of Streams and Locators
The use of locators leads to higher resource consumption in the database system. Additionally, locators are not yet
supported by all databases. In such cases, the locators have to be emulated from the database interface on the application
server.
The use of data streams does not lead to increased resource consumption in the database system, but data streams are
somewhat more limited in their use. In particular, data streams cannot be used if internal tables are being processed in the
Open SQL statements.
Previous Restrictions of Open SQL
Open SQL is a database abstraction layer with an SQL-like syntax. It defines a common SQL semantic for all databases
supported by SAP, (as opposed to being just a subset of SQL commands common to all databases). This common
semantic for all supported DBs ensures that the result of an Open SQL query is independent of the underlying database.

However, in the past there was a long list of SQL-92 standard features, which were not available in Open SQL. For
example, Open SQL lacked expressions, had only limited JOIN types, and did not support UNION or UNION ALL.
Luckily, as of SAP NetWeaver 7.40 SPS5, these limitations are minimized, because Open SQL has been extended. These
extensions, like the rest of Open SQL, are relevant regardless of the database. (It is worth noting that one scenario where
these extensions are of particular importance is when we think about the performance guidelines for SAP HANA).
New Open SQL Syntax
Using the new Open SQL features has the following implications:
 If you use any of these new features, you have to use the new syntax throughout your statements. For example,
the usage of arithmetic expressions and/or a comma-separated field list implies the escaping of host variables with the
“@” symbol.
 The usage of the new Open SQL syntax implies a so-called strict mode, whereby nearly everything that formerly
resulted in a syntax warning now results in a syntax error in the context of Open SQL commands.
To extend Open SQL, it was necessary to define a common semantic for the new features and functionality. Once this had
been settled, the new syntax was incorporated and the available Open SQL syntax was enhanced.

In the figure, you can see a summary of the main features of the new syntax in Open SQL, along with a syntax example
on the right-hand side.
The first thing you might notice is the “@” symbol used to escape so-called host variables. The ABAP system and
language are considered the host of the embedded Open SQL, so the term ‘host variable’ basically means an ABAP
variable or constant inside an Open SQL statement.
Remember the following:
 Every host variable (except literals) should be escaped with a preceding “@” sign at every position in the
statement.
 If one host variable is escaped, all host variables have to be escaped.
Moreover, a comma-separated list of fields can now be used.
In addition, Open SQL now supports the use of arithmetic and string expressions, as well as conditional expressions like
the CASE command shown in the second coding example.
Arithmetic and String Expressions in Open SQL
In Open SQL, not all arithmetic expressions are available for all types of variables.
Basic features like ADDITION, SUBTRACTION, MULTIPLICATION or the calculation of the absolute value (ABS) are
available for variables of type I and P (with and without decimals). On the other hand, the MOD function is only available
for variables of type I and type P without decimals. The arithmetic expression CAST is only available for FLOAT-typed
columns or host variables, and FLOOR and CEIL can be used for all variables of type P with decimals (even mixed with
I- and P-types without decimals).
In addition to arithmetic expressions, Open SQL now also features string expressions, and string concatenation using the
&& operator. Spaces are trimmed from columns and host variables, unless you use an ABAP constant which contains
exactly one space.
Joins in New Open SQL
Another new possibility is the use of a RIGHT OUTER JOIN. It is similar to the LEFT OUTER JOIN, but with switched
roles for the LEFT and the RIGHT tables.

In addition to this, the limited support for using brackets in JOIN expressions with more than two tables has been
enhanced. Previously, the JOIN had to be performed left-to-right; that is, the left-most tables always had to be joined first
(left-bracketing). This limitation no longer applies.
There is also new functionality with regard to the ON conditions of JOIN expressions, as follows:
 The previous restriction that a field of the right table is present in the ON condition has been dropped.
 Not only the “=” (equal) operator, but also operators like BETWEEN or greater than/less than can be used in the
ON condition now.
 Fields of the right table can also be used in the WHERE clause of a LEFT OUTER JOIN statement.
 Implicit client handling in JOINs has been improved. If the tables on both sides of a JOIN are client-dependent,
the ON condition is enhanced automatically with a filter on equal clients. Additionally, the client dependency is
propagated to the top of the JOIN tree and applied in the WHERE clause of the query statement. You don’t have to
struggle with client fields in JOINs any longer.
Beside these new features, two other restrictions have been removed:
 The maximum number of tables supported in Open SQL JOIN clauses has been increased to 50.
 The maximum number of sub-queries supported in an Open SQL statement has been increased from 9 to 50.
Other Features of New Open SQL
Literals help determine faster if a record exists in a table. Using literals improves performance for the cases where the
number of matches is not important, as opposed to using an aggregate function like COUNT(), which will scan all
matching rows.

CASE Expression in New Open SQL
You can now use the very powerful CASE expression in Open SQL in the projection list. The ELSE part is optional.
Database Updates with ABAP Open SQL

Database Operations using ABAP Open SQL
ABAP has the following commands for making database changes:
 Native SQL
Accessing the database with Native SQL enables you to use database-specific commands. Use of these commands
requires detailed knowledge of their syntax. Programs that use Native SQL commands need additional programming
after they are transported to different system environments (different database systems) because the syntax of the
commands needs to be adjusted on a database-specific basis. Implement database access using Native SQL only if a
Native SQL function that is not available in Open SQL must be used.
 Open SQL

Open SQL commands are not database specific. They are automatically converted into the respective SQL statements
by the database interface and passed to the database. An ABAP program that operates with Open SQL is, therefore,
not database specific and you can use it in any SAP system without adjustments.
Open SQL also enables you to buffer the content of database tables locally on the application server for quick read
access. Local buffering of the content reduces the database load. The data is automatically read from the buffer after
the table settings are done.
Open SQL commands perform operations only for Data Manipulation Language (DML), not for Data Definition
Language (DDL), because DDL commands are integrated in the ABAP Dictionary.
Target Quantity and Return Values
You can limit the target quantity to be read from the database using all the Open SQL commands.
SQL commands are available for single record access and multiple records access (or set access). A single set access
usually performs better than multiple single record accesses (except for the MODIFY command) when applied to a certain
number of records of data.
A syntax variant is available for the change operation that you can use to change individual fields in a record. If you have
masked field selections (WHERE <field> LIKE '<search_mask>'), ‘_’ masks an individual character and ‘%’ masks a
character string of any length in record with the SQL standard.
All the Open SQL commands display a message about the success or failure of the database operation performed. The
message is in the form of a return code in the system field sy-subrc. If sy-subrc equals 0, it means that the SQL operation
has been successfully completed. All other values of the field mean that errors have occurred. For further details, refer to
the keyword documentation for the command in question.
In addition, the sy-dbcnt system field displays the number of records for which the desired database operation was actually
carried out.
Note: Open SQL commands do not perform any automatic authorization checks. You need to execute these explicitly in
your program (statement AUTHORITY-CHECK).

Access to Client-Specific Tables
If you do not specify the addition CLIENT SPECIFIED in an Open SQL command, no client specification is allowed in
the associated WHERE clause. If the database table contains client-dependent data, the records of the current execution
client are accessed. The database interface automatically adds the corresponding WHERE clause.
If you process data from other clients, specify the addition CLIENT SPECIFIED in the Open SQL command and the
associated client(s) in the appropriate WHERE clause.
Caution: If an Open SQL command contains the addition CLIENT SPECIFIED without a client specification, the system
accesses the datasets of all clients.
Creation of a Record
The INSERT command has the following SY-SUBRC return values:

Return Code Description
0 Record inserted successfully.
4 Record could not be inserted because a record with the same key already exists.
Use the statements INSERT, UPDATE, MODIFY, and DELETE to change the content of database tables.
To insert a new record in a database table, enter the command INSERT INTO <dbtab> VALUES <wa>. Before running
this command, you must place the record to be inserted in the structure <wa>. This structure must be of the same type as
the records in the database table concerned.
The client field that may exist in the structure <wa> is used only if the CLIENT SPECIFIED addition is specified. If there
is no CLIENT SPECIFIED addition, the client value of the current logged on client is taken as the default client.
Records can also be inserted using database views. However, the database view must already be created in the ABAP
Dictionary with the maintenance status “read and change” and must only contain fields from a table.
Creation of Multiple Records
You can use the command INSERT <dbtab> FROM TABLE <itab> to create several records in a database table, as
shown in the figure. In this command, the internal table <itab> must have the same record structure as the corresponding
database table.
The client field that may exist in the internal table <itab> is used only if the CLIENT SPECIFIED addition is specified. If
there is no CLIENT SPECIFIED addition, the client value of the current logged on client is taken as the default client.
If it is possible to create all the records, sy-subrc is set to zero. However, if even one data record cannot be created, the
system triggers a runtime error and the entire insertion operation is discarded (database rollback).
If you want to insert all records, use the command addition ACCEPTING DUPLICATE KEYS. This addition has the
effect that in case of an error, the runtime error and also the database rollback are suppressed. The value of sy-subrc is set
to 4, and all the records without errors are inserted.
The sy-dbcnt system field contains the number of records that were successfully inserted in the database.

Change a Single Record
The UPDATE variants have the following return codes:
0 Record was changed.
4 Record could not be changed because, for example, the specified key did not exist.
You can use two variants of the UPDATE command to update a specific record in a database table, as shown in the figure.
In the case of variant 1, the database record that is specified by the key in <wa> is overwritten by the content of <wa>.
However, the key field mandt that may exist in <wa> is used only if the CLIENT SPECIFIED addition is specified.
Otherwise, the client value of the current logged on client is taken as the default client. Logically, <wa> must have the
same structure as the structure of the database record to be changed.
In the case of variant 2, the system changes the record specified in the WHERE clause. However, only the fields specified
in the SET addition are overwritten by the specified values in the database. In this variant, you must define the record to
be changed in the WHERE clause by specifying all the key field evaluations.
You can specify simple calculation operations as evaluation for numeric database fields in the SET addition “f = g, f = f +
g, f = f - g”.
You can also change the records by using database views. However, the view must already be created in the ABAP

Change Several Records
The UPDATE variants has the following return codes:

Subrc Variant 1 Variant 2
0 At least one record has been changed. All the specified records were successfully changed.
4 No record was changed. At least one of the specified records could not be changed (because,
for example, it does not exist). The other records were changed.
If you need to make identical changes to the same fields in several records of a database table, use the syntax of the
UPDATE command specified in the figure.
Using the WHERE clause, you can define the records that are to be changed.
In the SET addition, specify the fields that need to be changed in the records.
It is also possible to perform calculations such as f = g, f = f + g, f = f - g if numeric fields have to be changed.
You can also perform a mass data change by specifying an internal table that has the same structure as the corresponding
database table and the records to be changed.
The mandt field that exists in the specified internal table is used only if the CLIENT SPECIFIED addition is specified.
Otherwise, the client value of the current logged on client is taken as the default client.
The sy-dbcnt system field contains the number of updated records.

Modification of Database Records
The MODIFY command has the following return code:

Subrc Description
0 The specified record or all specified records were processed (updated or inserted).
4 The specified record or at least one of the specified records could not be processed. For example,
because the record does not exist in the database, inserting it would destroy a unique secondary index.
The MODIFY command is SAP specific and it covers the following commands:
 UPDATE
If the data record specified in the MODIFY statement exists in a table, the system updates the record.
 INSERT
If the data record specified in the MODIFY statement does not exist in the table, the system inserts the record.
Using the syntax variants of the MODIFY command, such as the syntax of UPDATE and INSERT, you can process one
or more records.
You can also carry out the update/insert operation on database views. However, the view must exist in the ABAP
The sy-dbcnt field contains the number of processed records.

Deletion of a Record
The DELETE variant has the following return codes:
0 Record was deleted.
4 Record could not be deleted because, for example, it does not exist in the database.
The syntax for the DELETE command is as specified in the figure above. The last syntax of the DELETE command
enables you to delete a record in a database table. In this syntax, define the record to be changed in the WHERE clause by
exactly specifying all the key field evaluations or any other field combination that uniquely identifies a record of existing
data.
A record can also be deleted from database views. However, the database view must already be created in the ABAP
In the syntax DELETE <dbtab> [CLIENT SPECIFIED] FROM <wa>, the structure <wa> must have the same structure as
the records in the respective database table. Also, before calling the command, the structure must be filled with the key
fields of the record that need to be deleted. However, if <dbtab> is client-specific and if the CLIENT SPECIFIED
addition is specified, the client field is taken into consideration (otherwise client value of the current logged on client is
taken as the default client).

Deletion of Several Records
The DELETE variant has the following return codes:
subrc Description
0 All the records specified in the internal table were deleted.
4 At least one record could not be deleted (for example, because it did not exist). The other records were deleted.
The syntax variant of the DELETE command that enables you to delete several records in a database table is as show in
the figure above. Here, you can specify the records that are to be deleted in the WHERE clause.
If you delete several records from a database table, you can specify them first in an internal table that has the same
structure as that of the respective database table, and then use the above syntax of the DELETE command. You need to

specify the key part of the records to be deleted in the internal table. If the key field mandt exists, then it is used only if the
CLIENT SPECIFIED addition is specified. Otherwise, the client value of the current logged on client is taken as the
default client.
The number of records deleted from the database is shown in the system field sy-dbcnt.
Syntax for Deletion of Records in a Cross-Client Database
You can delete all the records in a cross-client database table by using the following syntax:
DELETE FROM <dbtab> WHERE <field> LIKE '%'.
Here, <field> is an arbitrary table field.
If you delete all the records of the execution client from a client-specific database table, you can use the same
syntax, DELETE FROM<dbtab> WHERE <field> LIKE '%'. If you delete all the existing records from a client-specific
database table, you must specify the CLIENT SPECIFIED addition in the command DELETE FROM <dbtab> CLIENT
SPECIFIED WHERE <field> LIKE '%'.
Deleting data records by using conditions produces the following return codes:
0 At least one record was deleted.
4 No record was deleted because, for example, the specified records do not exist.
Restoration of Previous Database Status
If an Open SQL statement that implements a change to the database receives a return code different than zero, then ensure
that the database is reset to the same status as the status before you attempted to implement the change. To reset the
database, perform a database rollback, which reverses all changes to the current database LUW (Logical Unit of Work).
There are two ways to cause a database rollback, they are as follows:
 Send a termination dialog message with message type A or X

 Use the ROLLBACK WORK ABAP statement
The transmission of an A or X Message causes a database rollback and terminates the program. All other message types
(E, W, and I) involve a dialog but do not trigger a database rollback.
The ABAP statement ROLLBACK WORK causes a database rollback without terminating the program. In this case, the
context is not reset in the current program.

Database change bundling
SAP Logical Unit of Work
An SAP LUW consists of a set of dialog steps from Application Server (AS) ABAP that logically belong together.
Database changes from these steps are bundled within one database LUW. These changes are either fully implemented or
not implemented (“all or nothing principle”).
In general, a business transaction is not represented only by a single SAP LUW. The entire process, for example, from
receipt of a customer order to the issue of an invoice, is split into logical parts, each corresponding to an SAP LUW. The
definition of SAP LUWs depends on the entire process and its modeling.
For further information, refer to the ABAP Editor keyword documentation for the term transactions and logical units of
work.
Database Logical Unit of Work
A database LUW consists of changes that are executed until the database status is sealed (database commit).
Within a database LUW, you can discard all changes that have taken place up to a specific point in the database (database
rollback). When changes are discarded, the database is reset to its original status. The DB ROLLBACK function can be
used to restore the previous (consistent) database status if an error occurs.
The current database status is sealed by a database commit. After the database commit, the current database LUW cannot
be discarded.
A database rollback and database commit can be triggered explicitly or implicitly when processing a program.
An explicit database commit is executed if the following conditions occur:

 The ABAP statement COMMIT WORK is processed.
 The function module DB_COMMIT is called.
Wait situations lead to an implicit database commit if the following conditions occur:
 A dialog step is completed.

 A function module is called via Remote Function Calls (RFCs) synchronously or asynchronously, or the called
function ends.
 A WAIT statement interrupts the work process.
 Dialogs (information, warning, or error messages) that occur during the messages of certain quality, which are
processed in between the ABAP Open SQL statements of one LUW are sent in a dialog step.
 A transaction is called (CALL TRANSACTION ..., LEAVE TO TRANSACTION...), or the called transaction
ends.
 A program is called (SUBMIT ...), or the called program ends.
Explicit and Implicit Database Rollback
Explicit Database Rollback
 An explicit database rollback is executed if the ABAP statement ROLLBACK WORK is processed.
Implicit Database Rollback
An implicit database rollback occurs in the following situations:
 A runtime error occurs in a program performing the database changes (for example, division by zero).
 A termination message is sent by the system in a dialog step. This is typically an A or X message type. However,
in certain cases, termination messages are also generated with I, W, and E messages types, for example, at the Process
Before Output (PBO) event of a screen. Termination messages end the current application or program.
Processing an SAP LUW
If there is an error during the processing of an SAP LUW, it is possible to restore the consistent database status that
existed before the SAP LUW started. To restore the database status, the SAP LUW must be processed within a single
database LUW.

A transaction usually has several screens for entering change data because AS ABAP has a client/server architecture.
Whenever there is a screen change, the system automatically triggers an implicit database commit. Within a transaction,
you can bundle the user entries that form an SAP LUW within a database LUW, and write the entries to the database.
Changes to Database Bundles
AS ABAP is based on a client/server architecture with three levels: database server, application server, and presentation
server. This architecture, along with the distribution of user requests (user dispatching), leads to an efficient and cost-
effective multiuser system.
Majority of users with minimum configuration desktop computers can be mapped to a few high-performance work
processes on application servers. Each work process on an application server is assigned a work process on a high-
performance database server.
Distributing user requests to work processes means that individual clients at presentation server level are assigned to a
work process for a particular period after which the request uses another work process. After the work process has
processed the user input in a dialog step, the user and the program context are rolled out of the work process. Another user
can then use the work process.
The three-tier architecture is more scalable than a “fat” client architecture, where the presentation and application levels
run on one server. With a three-tier architecture, the number of database users is lower than the number of users active in
the system. A lower number of database users enables better database performance.
Implicit Database Commits

When a screen is displayed, the current work process is released on the application server. The release of the work process
triggers the release of the respective database work process and automatically initiates an implicit database commit.
Releasing the work process before each user dialog ensures that the user actions, which usually last longer, do not block
any work processes on the application server and, particularly, on the database server, which significantly reduces the load
on the database server. When a user has completed processing the screen, the user context is “rolled in” with the program
context. The user is returned to a work process for processing. The screen then requires internal program processing.
Hint: Due to the implicit database commits triggered at the end of a dialog step, changes that belong to an SAP LUW may
not be placed in different dialog steps. This is because these steps may not be in the same database LUW.
SAP Locking
SAP Lock Concept
If multiple users are competing to access the same resource or resources, the access to data must be synchronized to
protect data consistency.
For example, in a flight booking system, you must check whether seats are available. You must also guarantee that critical
data (in this case, the number of available seats) cannot be changed while you are working with the program.
Locks are a method of coordinating competing accesses to a resource. Each user requests a lock before accessing critical
data. When finished with the data resource, the user must release the lock to make the resource accessible for other users.

Database Locks
Database Management System (DBMS) physically locks the table lines read from the database for changing. Other users
will not be able to access the locked record until the system releases the physical lock. In addition, database locks are
automatically set if the database system receives change statements, such as INSERT, UPDATE, MODIFY, and DELETE
from a program.
However, at the end of a database logical unit of work (LUW), with every database commit, the database system releases
all the locks that were set during the database LUW.
For Application Server (AS) ABAP, the database system releases each database lock if an implicit database commit is
triggered. The release happens at the end of each dialog step (if the system displays a new screen) or if a wait situation
occurs (for example, a function module is called using remote function calls (RFC). Therefore, database locks are not
sufficient if data is collected throughout several screens and the respective data records are to be kept locked during the
LUW time frame.
SAP Lock Concept – Logical Locks

To maintain a lock through a series of screens (from the dialog program to the update program), AS ABAP offers a global
lock table at application server level, which you can use to set logical locks for table entries.
The lock table and the enqueue work process that manages the lock table are on a uniquely defined AS ABAP application
server (lock server, also known as enqueue server). All logical lock requirements of AS ABAP run on the basis of this
system-wide work process.
The lock table is kept in the memory of the lock server. SAP recommends that you use a stand-alone lock server so that it
is not necessary to implement high availability for the entire central instance. The stand-alone lock server, together with
the lock replication server that runs on another machine, is a high availability solution. Then, your SAP system no longer
has a central instance.
You can also use logical locks to lock table entries that do not exist on the database. This is appropriate, for example,
when you enter new table lines, and it is not possible to lock the entries using database locks.
For further information, refer to the ABAP Editor keyword documentation for the term SAP lock concept.
Lock Objects and Lock Modules
A logical lock is set in the lock table by calling a lock module. A lock module is a special, table-related function module
that is created automatically when a table-related lock object is activated. When the lock module is called, logical locks
are set for entries in the respective table(s).
Lock objects are maintained in the ABAP Dictionary. Customer lock objects must begin with EY or EZ. When a lock
object is created, the table whose entries are to be locked (primary or basis table) needs to be specified. Tables with a
foreign-key relationship to the primary table are referred to as secondary tables, and can also be specified. By doing so,
a combination of table entries that are related through the lock module can be locked. For example, a lock object that
contains the tables SFLIGHT (primary) and SBOOK (secondary) enables you to lock a flight together with its bookings.
The lock module that the system automatically creates contains, as input parameters, the lock parameters contained in the
lock object. Lock parameters are used to communicate to the lock module which records are to have a logical lock set in
the locking table. The system automatically proposes names for the lock parameters for the names contained in the table
key fields. The system-proposed names can be overwritten.

Generate Lock Modules
When a lock object is successfully activated, the system automatically generates two lock modules: one for setting locks
for entries in the table(s) specified in the lock object, and one for releasing these locks.
The lock modules have the following name convention: ENQUEUE_<Lock Object Name> orDEQUEUE_<Lock Object
Name>.

Display Generated Lock Modules
This figure shows display of generated lock modules.
SAP Locks
Depending on the lock mode, a lock module is either used to set a logical lock in the lock table or to check whether a lock
can be set.
You can only set a lock if your lock does not collide with entries that already exist in the lock table for the respective table
records. If there is an error, the lock module triggers appropriate exceptions. The application program can then determine
the success or failure of the lock action on the basis of the return code delivered by the lock module and react accordingly.
If there is an error, for example, the current user could receive an error message stating that he or she has been rejected by
the system.

Lock Actions – Possible Results
Depending on the technique used for database updates, an application program may need to delete the lock entries it has
created, or have them deleted automatically (if the SAP update technique is used).
If an application program that has created lock entries is terminated, the locks are released automatically.
Program termination takes place if any of the following statements are encountered:
 Execution of messages of the type A or X

 Execution of the LEAVE PROGRAM statement
 Execution of the LEAVE TO TRANSACTION statement
 If you enter /n in the command field
Set or Release Locks
To specify which lock entry is to be created, use the import parameters of an ENQUEUE lock module that correspond to
the key fields in the respective table. The import parameters are called lock parameters.
If the system does not set the lock successfully (sy-subrc <> 0), issue a corresponding dialog message to the current user.
At the end of the dialog program, use the corresponding DEQUEUE lock module to delete the entries from the lock table.
DEQUEUE lock modules do not trigger any exceptions. An attempt to release an entry that is not locked has no effect. To
release all locks that have been set by the current program execution at the end of your dialog program, use the
DEQUEUE_ALL function module. Locks are released automatically at the end of the program and are passed over to
update techniques. Therefore, DEQUE modules are hardly used.

Lock Argument
The lock argument is constructed from the values of all lock parameters (key fields of the respective table). The core part
of a lock entry, the lock argument defines which table lines are to be locked.
When calling a lock module, a lock parameter may be set to its initial value, or may not be specified at all. The system
interprets a lock parameter that is not specified as a generic value, interpreting the lock as referring to all table lines to
which the other parameter variants apply. An exception to this rule is the client parameter.
The following conditions apply to the use of SY-MANDT on a lock module call:
 If the client parameter is not specified, then the lock applies only to the current execution client (SY-MANDT).
 If the client parameter is specified with a specified client, then the call applies only to that client.
 If the client parameter is specified with SPACE, then the lock applies to all clients.

Use SM12 to Set and Manage the Lock Table
Parameters in ENQUEUE Module
The mode_<table name> parameter overrides the default lock mode of the lock module that is in the lock object.
Use the x_<> to specify lock entries where the <lock_parameter> has an initial value. Otherwise, the initial
<lock_parameter> is regarded as a generic parameter.
The _scope parameter defines the validity range of the lock.
Scenarios and Validity Range of Lock Modules
For value 1 of the _scope parameter, the lock is related to the program that sets it, and can therefore only be deleted by the
generating program. This mode is used for inline updates.

For value 2 of the _scope parameter, the lock is related to the update program (default). Therefore, the lock can be deleted
only by the update program. This default mode is used if the SAP update concept is used to perform the database changes.
For value 3 of the _scope parameter, two locks are set. One of these locks is related to the program and must be deleted
from there, and the other is passed to the update program. It is necessary to delete one lock and send the other to the
update program whenever the update task is triggered for a partial update of a record. The corresponding total record
remains locked in the program for further partial updates.
The _ wait parameter defines whether a lock request is repeated in case the first lock attempt fails. Configure the number
of retries by setting profile parameter ENQUE/DELAY_MAX (default: 5).
Use the _collect parameter to store the lock request in the local lock container until it is dispatched and passed later to the
enqueue server.
The _SCOPE Parameter
Using the Lock Container
Requesting a lock from a program is a communication step with lock administration. If the program sets locks for multiple
objects, the communication effort occurs more than once.
By using the lock container, technical effort required for communication with lock administration can be reduced. To do
this, set the _collect = X parameter whenever a lock module is called. The effect is that the respective lock requests are
stored in the local container for subsequent collective dispatch.
The contents of the lock container can be dispatched to lock management by using the FLUSH_ENQUEUE function
module.
If all the lock requests are successfully issued, the system deletes the entire content of the lock container. If one of the
locks in a container cannot be set, the FLUSH_ENQUEUE function module triggers the FOREIGN_LOCK exception.
When the FOREIGN_LOCK exception is triggered, none of the locks registered in the container are set, and the container
content remains complete for further dispatch attempts.
Hint: Use the RESET_ENQUEUE function module to delete the contents of the lock container.

Lock Modules
If a lock is set when calling the respective lock module, the lock mode can be specified to determine the type and purpose
of the lock. If no specification is made, the default in the definition of the respective lock object applies.
Lock modes used to set locks include the following:
 Mode “S”
Mode "S" can be used by a dialog program to ensure that other users cannot change the data displayed by the program
during the display time. However, the mode also does not allow you to make any changes to the displayed data.
For example, the program determines a price for a flight, and displays it to a customer. While the customer considers
whether or not to book the flight, you want to ensure that the price will not be changed.
Multiple "S" locks on one lock key can exist. When this is the case, no one can add any exclusive lock with the same
key. As a typical use case for mode "S", do not intend to change the data but make sure that no one else performs a
change. This step can be performed by many in parallel.
 Mode “O”
Mode “O” is implemented to display data in the change mode, and provides the option to edit data if necessary.
For example, while displaying a list of flights, you need to add a new booking for one of the flights. Creating a file
booking impacts the number of occupied seats in the chosen flight. Therefore, you want to lock all displayed flights in
a way that does not hinder other users in the system. You also need to create a real write lock if you decide to book
the flight later.
Multiple "O" locks on one key can exist. When this is the case, only one user or program can add or upgrade to an
exclusive lock with the same key.
As a typical use case for lock mode "O", you and other users might intend to change the data. Before changing the
data, again ask the local service to ensure that no one else is in change mode by then.
 Mode “E”
Mode “E” sets a lock for changing data and can be accumulated. Accumulation occurs if the same lock is requested
successfully more than once within the same program run, thus with the same lock key. This can happen, for example,
if a program that asked for a lock is calling a function module or a method, which again is requesting the same lock.

For example, you want to book a flight. After you have chosen the flight you want to book, you must make sure that
no other customer books the same seat on the flight. To do this, you must lock the respective seat with mode “E”.
Only a single "X" or "E" lock can exist for a key. An "E" lock can be cumulated. As a typical use case for lock mode
"E", you explicitly intend to change data and therefore you lock exclusively.
 Mode “X”
Mode “X” functions similarly to mode ”E” when changing data, with the only difference being that, in mode “X”, the
respective lock does not allow accumulation.
For example, navigation options in a program allow you to enter various functions to edit the flight. To ensure that the
flight can be edited in only one of the dialogs, an exclusive and noncumulative lock is used.
An "X" lock cannot be accumulated. As a typical use case for lock mode "X", you explicitly intend to change data
and therefore you lock exclusively.
Cumulate Locks – Additional Lock Request from Another Program Instance
If there are existing locks in the system, attempts to set additional locks may arise from the program instance (or from a
method or function module called synchronously from this program instance) that has already set an existing lock.
However, attempts to set additional locks may also arise from a different program instance. A different program instance
may be a second instance of the same program started by the same or (more likely) any other user.
In case the program instance is a second instance of the same program, attempts to set locks are treated as follows:
 Existing exclusive locks (“E” or “X”) categorically reject every lock attempt of another program, regardless of the
mode in which the other user attempts to set the lock.
 An existing shared lock (“S”) or optimistic lock (“O”) allows other shared locks or optimistic locks for protected
display to be set for the same data record. The system rejects the attempts by other programs to set exclusive locks for
the same data lock entry.

Cumulate Locks – Additional Lock Request from the Same Program Instance
Accumulation is the process when an attempt is made to lock a data record more than once while a program is running.
The lock system reacts in the following ways during this process:
 In case of an existing “E” lock, the system accepts “E”, “O”, and “S” locks for the same data record. The system
rejects attempts to set an “X” lock for the same data record.
 In case of an existing “X” lock, the system rejects every further attempt to set a lock.
 In case of an existing “S” or “O” lock, the system sets these locks for the same data record from within the same
program. In addition, if there are no further shared locks or optimistic locks set by another user for the data record,
you can also set an additional “E” lock.
 The system does not set the “X” lock if there is an existing lock for the data set being accessed.
Pessimistic Locking Pattern – Setting and Releasing Locks
If you want to ensure that you are reading up-to-date data in your program (with the intention of changing the data and

saving it to the database), a pessimistic or an optimistic lock pattern can be applied. The optimistic lock pattern makes use
of optimistic locks available as of Application Server (AS) ABAP 7.0 EhP2.
To implement the classical (pessimistic) lock pattern, perform the following steps in your program:
1. Set exclusive locks (“E”) for the data to be processed.

2. If the lock has been successfully set, read the current data from the database.
3. Change the program data (user inputs) and update the changes to the database.
4. Release the locks.
The order of steps ensures that the changes run completely under the protection of locks. Additionally, the order of steps
also ensures that only data that the other programs have changed consistently is read.
Optimistic Locking Pattern – Setting, Promoting, and Releasing Locks
To implement the optimistic lock pattern, the following phases must be carried out:
Phase I
For reading the data, perform the following steps in your program:
1. Set the optimistic lock (type “O”).

2. If the lock has been set successfully, read the current data from the database.
Phase II
To change the data that was read in Phase I, perform the following steps:
1. Attempt to propagate your optimistic lock (type “R”). This will also delete all optimistic locks set by other
program instances for the same data set.
2. Change and save your data.
3. Release the exclusive lock.

An optimistic lock is set if the user displays data in the change mode. Optimistic locks on the same object cannot collide.
If the user wants to save the changed data, the optimistic lock must be converted into an exclusive lock (type “E”).
The conversion is implemented using lock mode “R”. The conversion fails if a user has previously set a shared lock on the
object, or if the system has already promoted another optimistic lock. If the promotion succeeds, the system deletes the
other optimistic locks on the object, and the lock behaves as an exclusive lock.
The existing ENQUEUE and DEQUEUE function modules can also be used for optimistic locks.
Optimistic Lock Pattern – Possible Conflict in Phase 2

Incorrect Usage of Locks
When using locks, if the sequence "Lock → Read →Change → Unlock" is not adhered to, the program will read data
from the database currently locked by another program( see the figure for a pessimistic lock pattern). In such a case, even
if the lock is successfully set after the read action, the data that the program reads and displays to the user for change is
already out of date.
LLUWs Across Multiple Programs
Programs Called Within Programs
The two ways to call other ABAP programs on a synchronous basis from within a program are as follows:
 For the following calls, the calling program is interrupted and the called program is executed.
CALL FUNCTION '<FUNCTION MODULE>'
CALL METHOD <class>=><method>
CALL METHOD <object>-><method>
CALL TRANSACTION '<TCODE>'
SUBMIT <program> AND RETURN
 For the following calls, the system terminates the calling program and starts the execution of the called program:
LEAVE TO TRANSACTION '<TCODE>'
SUBMIT <program>
Use SUBMIT <program> and SUBMIT <program> AND RETURN to call programs that can be executed (program type
“1” = “executable program”).
Use CALL TRANSACTION '<TCODE>' and LEAVE TO TRANSACTION '<TCODE>' to call transactions.

For more details on SUBMIT, CALL TRANSACTION, and LEAVE TO TRANSACTION, refer to the keyword
documentation integrated in the ABAP Editor.
Asynchronous Call of a Function Module
To call function modules asynchronously to execute processes in parallel, you must supply the call with the addition
STARTING NEW TASK <task name>, where <task name> stands for the name of an individual for the new independent
task in which the function module is processed.
Asynchronously called function modules are processed in parallel to and independent of the calling program. The output
of the function module (addition RECEIVE RESULTS FROM FUNCTION) is received in a later processing phase of the
calling program.
If you call function modules by using the addition STARTING NEW TASK <task name>, you must mark the function
modules as capable of being called remotely (processing type “remote-capable module”) in their properties.
For more information, see the keyword documentation in the ABAP Editor for CALL FUNCTION.

LUW Logic in Program-Controlled Calls
Function modules and methods run in the same SAP LUW as the program that calls them.
Executable programs called by SUBMIT <program> AND RETURN or SUBMIT <program> and transactions called
by CALL TRANSACTION '<TCODE>', or LEAVE TO TRANSACTION '<TCODE>' each run in a separate SAP LUW,
that is, their update requests have separate update keys.
If you use SUBMIT <program> AND RETURN or CALL TRANSACTION '<TCODE>', the system continues the SAP
LUW of the calling program as soon as the called program is completed. The LUWs of calling and called programs run
independently of one another. Update requests and subroutine calls that use the ON COMMIT addition each require an
independent COMMIT WORK in the corresponding SAP LUW.
If you use SUBMIT <program> or LEAVE TO TRANSACTION '<TCODE>', the SAP LUW of the calling program
ends. If you do not conclude the update requests withCOMMIT WORK before the program call, the system does not
create a header for the related update key in the log. This means that the update work process does not execute the update
process for these requests. The same rule applies to subroutines called with the addition ON COMMIT.
Hint: Calling a program with SUBMIT <program> ..., CALL TRANSACTION '<TCODE>', or LEAVE TO
TRANSACTION '<TCODE>' involves an implicit DB commit. Therefore, all inline changes performed by a program are
automatically committed if another executable program or transaction is called.
SAP LUWs for CALL TRANSACTION
If you call transactions with nested calls, each transaction needs its own COMMIT WORK because each transaction maps
its own SAP LUW.
The same rule is true for executable programs that are called with SUBMIT <program> AND RETURN.

Call Mode in CALL TRANSACTION
If you call a transaction from within a program by using CALL TRANSACTION '<TCODE>', the system can execute the
transaction without user dialog (that is, in the background). For this purpose, you need to create an internal table in the
batch-input format (see the online documentation for CALL TRANSACTION) using the USING addition. This table
contains the values for the dynpros and the function code to navigate between the dynpros. For the call with “N” (do not
display), you must specify the MODE parameter.
Other values for the MODE parameter are "A" (display = default), "E" (only display if error), and "P" (display debugger
at break point).
You can overwrite the default update mode for the transaction by using the call parameter UPDATE, which is usually
asynchronous. In this context, the default update mode is the mode that is coded in the called transaction. Therefore, by
calling a transaction that has a coded "A" mode, you can overrule that by calling CALL TRANSACTION <> MODE "S".
If UPDATE = ’S’, the system continues processing the calling program only when the update process triggered by the
called transaction is completed. The system field sy-subrc returns the update status. UseUPDATE = ‘S’ if processing of
the transaction that is called later is dependent on the successful execution of the present transaction.
For more information, refer to the keyword documentation in ABAP Editor for the term CALL TRANSACTION.
SAP LUWs in Asynchronous Function Calls
A function module that you call asynchronously creates its own SAP LUW and runs in a separate session.
The system briefly interrupts the processing of the calling program. The system continues processing after the function
module is triggered; therefore, registered CALL FUNCTION in the UPDATE TASK and subroutines that have been
called with the ON COMMIT addition are retained.
Note: The asynchronous call of a function module triggers an implicit database commit. Inline changes processed in the
calling program up to that point will be committed in the database.

Implementation of Different Program Calls
Any program called by SUBMIT <program> AND RETURN or CALL TRANSACTION '<TCODE>' has its own SAP
LUW. You can use these programs to perform nested (complex) LUW processing.
Function modules and methods are executed within the LUW of the calling program. Therefore, they are suitable for
building up a complex (nested) LUW (for example, report calls various BAPIs = function modules within one LUW, one
COMMIT WORK works for calling report and all BAPIs).
Use asynchronously called function modules to perform tasks that can be processed in parallel. An asynchronously called
function module runs in a new main session, and therefore has its own SAP memory. Use the function module interface to
perform data transfer.
For example, in a program, you want to call up a display transaction that is displayed in a separate window (amodal). You
need to use the statement CALL TRANSACTION '<TCODE>'. Start a new mode by using CF <> STARTING new task
and transfer the data by using the function module interface. Then, call the transaction from within the function module.
The data transfer from the function module to the called transaction can be done by using SAP memory, ABAP memory,
or using the BDC itab within the CALL TRANSACTION statement.

SAP Lock Mechanism in Complex LUW Processing
If a type “E” lock is set in the program for a data record, further locks of type “E” set in the same program can be included
in a function module that was called synchronously or in a called method. This process is called accumulation of a lock.
However, you cannot set additional locks to the existing ones from within a program that you have called using SUBMIT
<program> AND RETURN or CALL TRANSACTION '<TCODE>'. Any lock attempts from such calls will be rejected
with the exception FOREIGN_LOCK as this additional lock request comes from a new LUW.
If you call a program by using SUBMIT <program> or LEAVE TO TRANSACTION '<TCODE>', the system terminates
the calling program immediately and deletes all locks set up to that point. This ensures that no lock conflicts arise between
the calling and the called program.
The system treats lock requests from the same user in different main sessions or terminal sessions as lock requests from
different users. As shown in the figure, this is also the case for the same user, main session, and different INTERNAL
sessions that are created by CALL TA or SUBMIT AND RETURN. This starts a new LUW and therefore, the
accumulation is not possible, for example, for an E lock. In other words, accumulation, that is, to receive the same lock
again, only works within the same LUW.
ALV Design
Layout Variants
You can use the is_variant and i_save parameters to determine the options for variant management that are offered to the
user.
The modes that you can define are as follows:
 Users can change the current layout variant. To set this mode, assign space to both parameters (default setting).

 Users can change the current layout variant and select existing variants. To set this mode, pass a structure of type
disvariant to the is_variant parameter. Assign the name of the current program (sy-cprog) to the report field, and then,
assign the value space to the i_save parameter.
If there is more than one ALV instance in your program, assign a freely-definable name to each instance using the
handle field.
 Users can change the current layout variant and save and manage the existing variants.
To do this, set the is_variant parameter as for the previous mode. The value of the i_save parameter determines the
way in which the user can manage the layout variants.
You can assign the following values to the i_save parameter:
 U (The user can only save user-specific layout variants)

 X (The user can save global layout variants)
 A (The user can save both user-specific and global layout variants)
Saving of Layout Variants
Namespaces of the variants have the following rules:
 Global variants (known as standard variants) of the customer start with a /.

 Global variants of SAP start with a digit.
 User-specific variants start with a letter.
Variants are client-specific.
You can transport only the standard layout variants. Call the layout management, choose the desired variants, and then
choose Layout → Transport.
When saving a layout variant, you can define it as the default variant if the i_default parameter of the
set_table_for_first_display method has the value X. This value is the default value.

To create or change standard layouts or to set them as the default setting, users require an authorization for the
authorization object S_ALV_LAYO with ACTVT value 23.
Passing of a Layout Variant to the Selection Screen
The user can create this parameter on the selection screen that is assigned a type with disvariant-variant. The name of the
layout variant is passed with this parameter. The content of the parameter is assigned to the variant field of the is_variant
parameter before data is displayed in the ALV.
It may be necessary to pass the layout variant to the selection screen of the report, for example, in the case of execution in
the background.
Adaptation of the ALV Grid Control
To create a striped pattern for the lines, create a structure gs_layout in your program with ABAP Dictionary type
lvc_s_layo. Then fill in the relevant fields, for example, gs_layout-grid_title, gs_layout-cwidth_opt, and gs_layout-zebra,
and pass on the structure to the is_layout parameter of the set_table_for_first_display method.

You can change the layout of your ALV grid, for example, you can select the title, create a striped (zebra) pattern for the
lines, or optimize the column width.
Main Fields of the Layout Structure
Lvc_s_layo Fields
Lvc_s_layo is a global structure type and some of its fields are as follows:
Field Description
grid_title Title with a maximum of 70 characters.
zebra If "X", the list is displayed with a striped pattern.
no_headers If "X", no column headers are displayed.
sel_mode A setting that determines how many cells, lines, and columns can be selected.
cwidth_opt If "X", column widths are optimized.
info_fname An additional data table field that contains information about coloring of lines.
ctab_fname An addition data table field that contains information about coloring of individual cells.

Selection of Cells, Columns, and Lines
Depending on the value you enter in the sel_modefield in the layout structure, users can select individual or several lines
or cells.
To select several entries, press the CTRL key and keep the mouse button pressed while clicking further rows, columns, or
cells.
To select a continuous range of rows, columns or cells, press the SHIFT key and keep the mouse button pressed.
Exception Columns
The instructions to display the threshold values are as follows:
1. Add a character field with length 1 to your data table structure.

2. Fill the field for each row of your data table according to the desired threshold value:
 0 = gray
 1 = red
 2 = yellow
 3 = green
 space = nothing
3. Enter the name of the exception column in the excp_fname field of the layout structure, and pass the layout
structure to the is_layout parameter of the set_table_for_first_display method.
If you enter X in the excp_led field of the layout structure, colored LEDs are displayed instead of the standard traffic light
icons.
You can use exceptions to indicate by means of a traffic light whether threshold values have been reached, on a line-by-
line basis.
Sort Criteria
Users can dynamically sort data in the ALV grid. To present the data to the user presorted, you can fill an internal table of
lvc_t_sort type and pass it to the it_sort parameter of the set_table_for_first_display method.
In the internal table, insert a line for each sort criterion that you want to define.
To sort data using sort criteria, enter the column name in the fieldname field. If you use more than one sort criterion, in
each case, enter the sequence in which the sort criterion is evaluated in the sposfield. Alternatively, you can also insert the
fields in the required sequence in the internal table of sort criteria. Enter "X" in the up field if you wish to sort the entries
in ascending order.
If you want to sort the entries in descending order, enter X in the down field.

Line Colors
The formula to color a column is C<color_constant>10, where <color_constant> represents the eight color constants of
the COL type group.
In the info_fname field, enter the component name of your color column for a structure of the lvc_s_layo global type and
pass the structure to the is_layout parameter of the set_table_for_first_display method.
To change the color of a line in the ALV Grid, add an extra field to your data table that contains a code representing the
color of the line. This is a character field with length 4. Add the field at the end of the line type of your internal table. If
you are using a global structure type to describe the contents of the internal table, the color column will not be displayed.
Instead, the ALV uses it to format the line accordingly.
The INCLUDE TYPE or INCLUDE STRUCTURE statement provides a simple way of defining the necessary line type
for the data table, locally in the program.

Color Options
C111, C170, and C501 are some examples of values of the color field. For an overview of colors, see the online
documentation for the ABAP command FORMAT.
Components of the Color Field Value
 Letter ‘C’
 Number of one of the eight colors
 1 (intensified display) or 0 (intensified display off)
 1 (inversion of foreground and background color) or 0 (no inversion)
Cell Colors
To color a cell in the data table, create an entry for it in the internal table containing the field name and the color code. A
cell color has a higher priority than a row color.
To highlight individual cells using colors, extend the line type of the output data table, adding an internal table of
lvc_t_scol type. The contents of the internal table are not displayed; they contain information that controls the output.

Changing of the Cell Color
The steps to change the cell color are as follows:
1. Loop through the gt_sbook internal table into the gs_sbook structure. Different cells can be colored for each data
record. If you want colored cells only in one data record, use the READ TABLE statement instead.
2. Fill the gs_colfield help field that contains two fields, fname and color. The fname field is the name of the field to
be colored. Thecolor field is a structure containing the different parts of the color code to be used. It is made up of
the col, int, and invcomponents.
3. Append the gs_colfield help field to the gs_sbook-it_colfields internal table. The gs_sbook-it_colfields internal
table contains information about the cell color combinations.
4. Write the gs_sbooking work area back into the internal data table using the MODIFY command. Complete steps 2
and 3 for each field to be colored.
Changing of the Cell Color – Procedure
Changing of the Cell Color – Data Declarations
The line type for the internal table contains the following fields:

 fname
The name of the field in which the data is to be highlighted
 color
The color settings for this field are as follows:
o col
One of the eight color constants of the col type group
o int
1 for intense, 0 for not intense
o inv
1 for inverted (the foreground and background colors are switched), 0 for not inverted
o nokeycol
To display a key field as a normal column, and not highlighted.
To extend the output data table, add an internal table of lvc_t_scol type.
The contents of the internal table are not the output, but are included only for the layout.
Changing of the Cell Color − Processing
It is best to loop through the entire table and specify any fields that are to be colored differently.
You must assign the name of the column containing the internal table with the color field information to
thectab_fname field of the layout structure. Transfer the layout structure and the output table using the
set_table_for_first_display method.

Hiding of Standard Functions
The significance of standard functions depends on the application and the data displayed in the ALV grid. You can
display only a subset of the standard functions or hide the entire toolbar.
To hide individual functions, define an internal table with the ui_functions line type. Fill the internal table with the name
of the functions that you need to keep inactive. Inactive functions on the application toolbar are not displayed. Inactive
functions that are assigned to a menu entry are grayed out.
The possible function codes are defined as constants of the cl_gui_alv_grid class. The constants for function codes have
the MC_FC_ prefix. The MC_MB_ prefix represents an entire menu in the toolbar.
Pass the table to the standard functions when you call the set_table_for_first_display method. To deactivate all functions
on the application toolbar, you can use the MC_FC_EXCL_ALL constant.
To hide the entire toolbar, set the no_toolbar parameter of the layout structure to X and pass the layout structure to
set_table_for_first_display.

The Field Catalog
The field catalog is a format description of the display area for data.
Function of the Field Catalog
Examples of situations in which you need to use a field catalog include the following:
 The internal table containing the data has a line type with an ABAP Dictionary reference, however the display
needs to be different, for example, concerning column positions or titles.
 The internal table has columns that are not contained in an ABAP Dictionary structure.
The field catalog must contain a row for every column of the data table that differs from an underlying ABAP Dictionary
structure or a row for every column that is not in the ABAP Dictionary structure at all. This row must contain the
technical properties and other formatting information for the column.
The internal table contains the data to be displayed. This table can have a freely definable row type so that the
representative instance can display the data transferred to it as desired on the screen output or when creating a print list.
To perform this action, the representative instance requires information about the type and formatting of each column.
This is the job of the field catalog.
The representative instance can automatically generate the field catalog. If the structure of the data table corresponds to a
structure that is defined in the ABAP Dictionary, you only need to pass the name of that to the representative instance.
You can also pass this display information to the representative instance using an additional internal table. This additional
table is called the field catalog. The global data type of this internal table is LVC_T_FCAT. The corresponding structure
type (for the work area) is called LVC_S_FCAT.

Grid Structure Adjustment Without the Field Catalog
Alternative Ways to Adjust the Grid Structure

The alternatives to using the field catalog for various requirements are as follows:
 To add additional or different columns

Can use a different global structure type
 To hide columns or different order

Can use standard display variants
 To display only some of the columns left-aligned

Can use the INCLUDE TYPE statement for local row type of the data table
 To generate the data table dynamically (as of SAP Web Application Server 6.10)
Can transfer the structure type as field symbol
Some of the solution approaches also offer additional advantages, such as central maintainability, reusability, and so on.
The INCLUDE TYPE statement has existed from SAP Web AS 6.10. You can use this statement to include Dictionary
types, ABAP types, and self-defined types, directly.
INCLUDE STRUCTURE is still supported for compatibility reasons.
Before you define and fill a field catalog and pass it to the representative instance, consider if you can implement your
requirements in a different way. In some cases, it is simpler or more flexible, to implement these alternative solutions.
Options for Creating a Grid
The way in which you generate a field catalog depends on how the line type of the data table was defined.
Situations when a field catalog is required include the following:

 All fields of a global structure exist in the data table with the same names, however, adjustments are to be made to
the specifications from the ABAP Dictionary, additional columns are to be output, or both. In this case, create rows in
the field catalog for the columns to be changed or added.
 The row type of the data table does not contain any reference to the ABAP Dictionary, individual global structure
fields, or data elements. In this case, you need to create the field catalog completely in the calling program.
 There is another situation when a field catalog may not be required; when all fields of a global structure type exist
in the data table with the same names. These fields should also be the output. In this case, you can have the field
catalog generated automatically by the representative instance. You only need to pass the name of the global structure
type to the parameter i_structure_name of method set_table_for_first_display. Columns of the data table that are
defined in the global structure type are displayed.
Overview of the Structure of the Field Catalog
Other fields of the field catalog can be divided into the following groups with regard to their use when creating a field
catalog:
 References to global types, which are structure fields in the ABAP Dictionary, are created using
the ref_field andref_table fields.
 All other fields of the field catalog contain values for the properties of the columns.
If you assign values to the ref_table andref_field fields, all type definitions are transferred from the specified structure
fields in the ABAP Dictionary. You can overwrite these values by assigning values to individual fields of the latter group.
If you do not assign values either to ref_field orref_table field, assign values, if necessary, for all fields of the latter group.
To create a field catalog in the calling program, proceed as follows:
1. Define an internal table for the field catalog based on the lvc_t_fcat global table type and a compatible structure
as the work area.

2. Assign the name of a column from the data table to the fieldname field. This field assigns a row in the field
catalog to a column of the data table.
3. Fill the fields of the work area for each affected column of your data table and add it to the internal table for the
field catalog.
Assignment of Types to Columns with Dictionary References
The fieldname column in the field catalog contains the column name from the data table. Every column of the data table
that you want to format must have a corresponding row in the field catalog.
If you want to refer to a field of a global structure with the same name, assign the name of the structure to
the ref_table field. Only add the field name from the structure to ref_field if the name of the data table column and
structure field name are different.

Use of the Field Catalog to Set Column Properties
In the figure, the data table consists of fields (columns) of the SBOOK type and two others. You need to describe these
types in the field catalog, along with the column that you want to be hidden.
Example – Adding and Changing Columns
The figure shows a semiautomatic field description. A part of the field description comes from the ABAP Dictionary
structure (SBOOK) whereas another part is defined in the gt_field_cat field catalog.
Fill the field catalog (internal table) in the program and pass it on with the name of the ABAP Dictionary structure in the
set_table_for_first_display method.
Ensure that the fields of the gt_bookings data table that cannot be read from the SBOOK table are also filled.
You must ensure consistency while constructing the field catalog semi automatically or manually. To perform this, press
the SHIFT key and double-click with the right mouse button in an area of the ALV grid that contains no data (for
example, the header).

Assignment of a Type to a Column Without Reference to a Dictionary Structure
You can use ROLLNAME to specify the data element that is used for the F1 help and the text for the column headers,
selection screen, and quick information text if it is not already explicitly set.
If you have not filled the ref_field or the ref_tablefield, there is no adequate reference to the ABAP Dictionary. In this
case, the fields allow you to format the relevant columns for output.
Formatting of Amounts for Units
Currency formatting has the following features:
 If you want to format the contents of a column according to the formatting options of a currency unit that is
specified in another column of the data table, specify the name of the column in the cfieldnamefield.
 If you want to format all values of a column according to a particular currency, specify the relevant currency
abbreviation in thecurrency column.
 If the currency field has a value, ignore the entries in the cfieldname field.
Quantity formatting has the following features:
 If you want to format the contents of a column according to the formatting options of a unit that is specified in
another column of the data table, specify the name of this column in the qfieldname field.
 If you want to format all values of a column according to a particular unit, specify the relevant unit abbreviation
in the quantitycolumn.
 If the quantity field has a value, ignore the entries in the qfieldname field.
For more information, see the online documentation.

Example – Appropriate Formatting for Currency Columns
In the figure, the data table contains the price (the amount to be paid for a flight) and currency columns (currency for the
contents of the price column).
Enter CURRENCY in the cfieldname field of the field catalog for the price column to ensure that contents in
the price column are according to the currency specified in the currency column, for example, USD - two decimal places,
JPY - no decimal places.
Output Properties of a Column
The features of different fields are as follows:
 The COL_POS field determines the output position of a field. It has the following features:
o To calculate the column position, count the hidden columns as well. However, exceptions do not count as
a column.
o Without explicit positioning, fields that are manually added to the field catalog are positioned before the
other fields of the data table.

o Exceptions are always displayed in the first column.
 The EMPHASIZE field has the following features:
o To highlight with a default color, enter X.
o You can also define the color yourself by passing a four-character code in accordance with the convention
- C<col_constant> {0|1}{0|1}.
<col_constant> stands for a color constant from the col type group. The third character specifies whether the color is
to be displayed intensively. 1 as the third digit means an inverted display, for example, C300, C401.
 The NO_OUT field has the following features:

o The column is hidden on the list (screen or print) but appears in the field selection dialog of the standard
functions, for example, sorting, filtering, and so on).
 The TECH field has the following features:
o The column is not displayed in the list or in the field selection dialog.
Formatting of Properties of Column Contents
You can use the decmlfield and decimals_o fields to define the numbers of decimal places in the same way as for currency
fields. These entries affect numerical content.
If you want to output a column as an icon, set theicon field of the layout structure to X. Run the SHOWICON report to
obtain an overview of icons. Note that not all icons can be printed.
If you want to output a column as a symbol, set thesymbol field of the layout structure to X. Run the SHOWSYMB report
to obtain an overview of symbols.

Texts
Make entries in the fields listed if a column has no reference to the ABAP Dictionary, or if you want to define or override
a text.
You can use the value assigned to the colddictxtfield to determine which of the four data element texts are to be used as
the column header (S = short, M = medium, L = long, R = heading). These texts are in the scrtext_s, scrtext_m, scrtext_l,
andreptext fields. If there is no ABAP Dictionary reference, you can set the texts in these fields.
If the colddictxt field has an initial value, set the text of the coltext field as the column header. If thecoltext field also has
an initial value, an appropriate text is automatically used from the four data element texts, depending on the width of the
column.
The texts in selection dialogs, for example, with a filter, behave in the following ways:
 The entry in the seltext field has the highest priority. If the text is missing, the longest of the four data element
texts is used. If none of these four texts exists, the contents of the tooltip field are used, or finally, the field name itself
is used.
 With the tooltip field, you set the text that is displayed when you put the mouse cursor over the column header
(quick information). If there is no entry in thetooltip field, the longest of the four data element texts is used. If none of
these four texts exist, thecoltext field is used.

Other Properties of a Column
You can use the sp_group field to combine multiple fields into a group with a group key. In various dialog boxes (such as
the selection of the sort field), the user can then display all columns or only those of a specific group.
To work with group texts, define an internal table with lvc_t_grp type and fill it with the names and descriptions of the
groups you want to use. Then pass the table to the it_special_groups parameter of the set_table_for_first_display method.
The code for declaring and filling the internal table is as follows:
DATA gt_groups TYPE lvc_t_sgrp.
DATA gs_group TYPE lvc_s_sgrp.
gs_group-sp_group = 'INFO'.
gs_group-text = text-inf.
APPEND gs_group TO gt_group.
You can use the txt_field field to declare additional texts for subtotals. For example, column A contains works numbers
and column B contains the associated long texts. On the list, the associated long texts are also displayed for subtotals of
the works numbers. The name of column B must be in the txt_field for column A (<struc_name>-txt_field = 'B').

ALV Events and Methods
Events and the Control Framework
The graphical user interface (GUI) in the SAP system is based on SAP GUI windows (screens from the technical view of
the programmer). Every user dialog in the system is implemented using the screens of application programs.
The application program communicates with the screen at runtime using various runtime system services (ABAP
processor and screen processor) and the SAP GUI services, which manage windows and their dialog box levels, data
transfer, and so on.
From SAP R/3 4.5, you can also use screen elements other than those provided in the Screen Painter in SAP GUI
windows. These additional screen elements are known as controls. Controls are standalone binary software components
that are reusable. As a developer, you can integrate one or more controls into your user dialogs and use the functions they
make available.
The communication between the control and the application program is different from that of the classic screen elements.
As of SAP R/3 4.6A, communication for all controls is performed in the same way using the Control Framework (CFW).
The CFW uses special services in the SAP GUI and the runtime system on the application server. These services are the
automation controller on the presentation server and the CFW service on the application server.

Controls and ABAP Objects
Every GUI control that communicates with an application program represents an object, which is an instance of a class, on
the presentation server. The communication with the instances uses the method calls and events of the objects.
From SAP R/3 Release 4.6A, there are representative classes (proxy classes) for all GUI controls in the class library.
These representative classes access the CFW in a uniform way and package the control-specific communication. These
are referred to as control wrappers.
Use of a GUI control in an ABAP program involves the following objects:
 Instance in the ABAP program

 Instance of the control at the presentation server
The communication between the ABAP program and a GUI control is performed as follows:
 The ABAP program communicates with the representative object only (method calls, operations on the
attributes). The representative object performs the associated operations on the presentation server instances using the
CFW.
 Actions performed on the presentation server control are forwarded to the representative object, using the CFW.
The representative object then communicates with the ABAP program.
The CFW maintains a list of the active instances with which it is communicating, both at the presentation server and on
the application server.

Events
To pass an event to a presentation server control, the following partner levels are involved:
 SAP GUI/Automation Controller

The Automation Controller in the SAP GUI receives the event triggered by the presentation server control.
The Automation Controller forwards the information about an event that it receives to the basis services of the
runtime system as a special function code (and additional data).
 Basis Services
The basis services forward the information to the representative object in the ABAP program.
 Representative Object
The representative object in the ABAP program triggers an ABAP Objects event, informing the instances registered
for the event. These instances then handle the event with an appropriate method also known as a handler method.

Processing of ABAP Objects Event
An object triggers events to announce a change in its state. Other objects can contain handler methods that are executed
when the event occurs. For the handler methods to be run, they must be registered with the basis services.
When the event is triggered, a basis service ensures that the registered methods are executed. The instance that triggers the
event does not know the event handler, unlike explicit method calls, where the caller has control and knows the method
called. This applies when the event is defined and when the event occurs at runtime.
If you want to receive and handle the events of a GUI control in your program, you must identify the events that the object
can trigger. The associated class for representative objects of the control can provide you with this information.
For information about the representative classes, see the online documentation for the respective controls.
Searches for ALV Grid Events

The ALV grid control has more than 25 events.
The Most Important Events of the ALV Grid
 DOUBLE_CLICK
This event is triggered after a double-click with the mouse.
 PRINT_TOP_OF_LIST, PRINT_TOP_OF_PAGE, PRINT_END_OF_PAGE, PRINT_END_OF_LIST

These events are triggered at various points during output of the print list.
 TOOLBAR
This event is triggered when the ALV grid control is created or refreshed, but can also be triggered explicitly with a
method. It allows you to change the composition of the toolbar.
 USER_COMMAND
This event is triggered when user-defined function codes are chosen. These codes are assigned to your own buttons in
the toolbar or entries in the context menu. This event allows you to implement your own functions.
For more information about other events, see the online documentation.
Event Handlers
Any class can contain handler methods for the public events of other classes. Event handler methods require the FOR
EVENT <event_name> OF <class_name> addition in the definition part. This addition specifies that this method can react
to <event_name> events of instances of the <class_name> class.
The names of event handler methods should be structured as on_<event_name>, where <event_name> is the name of the
event.
The signature of an event handler method can only contain importing parameters. These parameters are defined within the
corresponding event. The types of the parameters are also copied from the event. However, the event handler method does
not need to import all the parameters passed in the RAISE EVENT statement.

Every event has an implicit parameter, called sender, which you can also receive by listing it in the IMPORTING
addition. This parameter allows handlers of instance events to access the instance that triggered the event, for example, to
call its methods.
A static handler method is declared with CLASS-METHODS .... You do not have to instantiate the class to use static
handler methods.
The definition of an event handler method in a class means that the instances of the class and the class itself are, in
principle, capable of handling the event in question.
ALV Grid Control Events Through Mouse Operations
If the user double-clicks the data area, the double_click event is triggered in the calling program.
The export parameters contain information about the data table. Both of these parameters are structures.
The export parameters are as follows:
 ES_ROW_NO
You can find the number of the double-clicked row in the row_id field. This corresponds to the correct row number in
the internal table.
 E_COLUMN
You can find the name of the double-clicked column in the FIELDNAME field. This corresponds to the correct
column name in the internal table.
If a column has been identified as a hotspot, and the user presses the mouse button in the hotspot column of the data area,
the hotspot_click event is triggered in the calling program. The export parameters are filled in the same way as for the
double_click event.
For more information about these or other mouse operation events, see the online documentation.

Syntax Example – Handlers as Static Methods
A handler method can be a static method, for example, of a local class, or an instance method of an object.
In case of a static method, the local class can be compared with a repository that stores the methods. The difference in the
class method compared with the instance method is that you do not need to instantiate an object for the local class to use
the method.
To create a handler method for an event, first define a local class. The local class requires a public method (in the
PUBLIC SECTION) that is defined as a handler method for a particular event of a certain class. You can use the CLASS-
METHODS statement for this process.
After defining the method, you need to implement it.
The method receives the information provided by the event about the mouse position at the double-click and generates an
information message that displays the row and field of the mouse click.

Syntax Example – Handlers as Instance Methods
To generate an instance method, use the METHODS statement when defining the class.
Implement the method in the same way as the class method and then create a reference variable with a reference to your
local class. Finally, create a corresponding object.
Linking of the Representative Instance and the Handler Method
By default, an event handler is not processed when an event occurs. The event handler is only called if you register the
event at runtime. When you register events, you must decide if you want to react to the event only if it comes from a
specific instance, or whether it should be processed regardless of which instance has triggered the event.
The SET HANDLER statement links handler methods with the event triggers.
In the figure, there is the on_double_click static method of the lcl_event_handler class. This method is called if the ALV
instance, to which the go_alv_grid object refers, triggers the double_click event.
For more information about registering handler methods for events, refer to the keyword documentation for the SET
HANDLER statement.
In the figure, a static method is used for the handling. To use an instance method, the syntax is SET HANDLER
lcl_event_handler_object->on_double_click FOR go_alv_grid.
Note the different component selectors: => for static methods and -> for instance methods. The SET HANDLER
statement has linked the handler method with the ALV grid control.

Inclusion of Custom Functions for the ALV Grid
Before the standard toolbar is integrated into the ALV grid control, the representative instance triggers the toolbar event.
This happens during the execution of the set_table_for_first_display and refresh_table_display methods.
During the lifetime of the representative instance, you can trigger the toolbar event explicitly by calling the
set_toolbar_interactive method.
To add elements to the standard toolbar, you must implement a handler method for the toolbar event of the
cl_gui_alv_grid class.
Extension of the Standard Toolbar
The toolbar event has a pointer to an instance of the cl_alv_event_toolbar_set class as an exporting parameter. This
instance of a toolbar contains the public attribute mt_toolbar. This attribute is an internal table with line type stb_button.
You fill this internal table in the handler method to add further buttons or other elements.
If the user chooses an element of the menu buttonor menu type, the representative instance triggers the menu_button
event. This has a parameter e_object with type ref to cl_ctmenu. To add a menu to the toolbar, you must also implement a
handler method in which you create the menu in the same way as a context menu.
You can differentiate between multiple menus by querying the function code.

Function Handling
If the user chooses a function element that has been added to the standard toolbar, the representative instance triggers the
user_command event. This event contains the function code as its e_ucomm export parameter.
To handle the additional function, implement a handler method for the user_command event. You can differentiate
between the function elements by querying the function code.
Reaction to Button Clicks
You can display a field in the ALV Grid as button in the following ways:
 You can specify the attribute for a column in the field catalog, using the style parameter.

 You can specify the attribute for individual fields. In this case, you need both a column that will be displayed as a
button in certain lines and an internal table as a column of your data table with line type lvc_t_styl. You create an
entry in this internal table for each column of the current line that should be displayed as a button.
In the figure, a separate field (btn_text) is defined for the gs_flight structure in which a button is displayed (or not)
depending on other data. You can also use the existing fields of the data structure if they do not have F4 help.
To define the field as a button, you need an internal table with type lvc_t_styl (CT in the preceding figure). For each field
to be displayed as a button, you create an entry in the internal table in which you assign the name of the field to the
fieldname component and the constant cl_gui_alv_grid=>mc_style_button to the style component.
The name of the internal table that contains the information about the buttons is specified in the stylefname component of
the layout structure.
button_click Event Handling
When a user chooses a button in a cell, it triggers the button_click event. The event returns the number of the row and
name of the column in which the button was clicked. This allows an associated handler method to implement a context-
specific reaction.

Print List Events
The print list is automatically generated by the representative instance. This list can be extended by the calling program.
Use the events shown in the figure. By using these events, you can implement the same logical process steps as used in
the classic ABAP list layout. In the event handler methods that you want to be implemented, you can use the usual
statements for ABAP list output and their various additions such as write, skip, uline, and so on.
You can also use the subtotal_text event to define additional texts for subtotals across columns whose output has been
suppressed. For more information, see the online documentation.
Print List – Page Break for Group Change
For a page break at a control level change in the print list, you must set an indicator in the print structure to ensure that the
user can format the control level change in the print list. This print structure is controlled by the grpchgedit field of the
is_print transfer parameter, which is the lvc_s_prnt structure type.

The programmer sets this parameter. The program user then sorts in the ALV Grid or in the print list by the fields for
which the user wants group processing.
Page Break for Group Change – Runtime
In the print list display, the user calls the Define Sort Order dialog box. To call the Define Sort Orderdialog box, choose
the Sort button without selecting a column.
The figure shows the settings that the user can set in the dialog box, in the CB field.
This step only works in interactive mode and not in background processing. For background processing, you must specify
the settings for sort order and control level formatting in the it_sort parameter of the set_table_for_first_display method.
To specify these settings, assign * or UL to the GROUP field in the it_sort parameter.
Display Information for the Print List

You can set the print list using the print, reservelns,grpchgedit, and prntlstinf fields of a structure of the lvc_s_prnt global
type. To make these settings, assign a structure of this type to the is_print parameter of the set_table_for_first_display
method.
If you assign the value X to the print field, you can use the ALV grid control to print without displaying the list on screen.
The passed data table is formatted at once as an ABAP print list and sent to the print spool. Interactive screen output is not
processed.
You can use the reservelns field to define the number of rows required for the page footer. If you assign the value X to
the prntlstinf field, information about the sort order, totals, and defined filters are printed, together with data statistics, at
the start of the list.
The prnt_title field specifies the time when the grid title will be printed (0/default – before the print_top_of_list event; 1 –
after the event print_top_of_list; 2 – before the print_top_of_page event; 3 – after the print_top_of_page event).
If you assign a value X to the no_colwopt field, no column width optimization occurs. The other fields of the structure
type are not used for the ALV grid control.
Suitable Methods for ALV Tasks
By accessing the Class Builder, the Class cl_gui_alv_grid can be displayed. In the Methods tab any of the methods of this
class can be selected. Using the buttons on this page, the parameters, exceptions, or source code of the selected method
can be viewed. The Class Documentation can be found in the Application Toolbar. The class documentation contains a
Link to SAP Library.

Description of ALV Control Methods
Description of ALV Control Methods

Some ALV control methods and their descriptions are as follows:
Method Description
get_current_cell Returns the coordinates and value of the current cell
get_selected_cells Returns the coordinates and values of the selected cells
get_selected_columns Returns the names of the selected columns
get_selected_rows Returns the row numbers of the selected rows
get_subtotals Get current subtotals of the ALV Grid Control
set_toolbar_interactive Triggers the toolbar event
set_user_command Overwrites the current user command
The constructor, set_table_for_first_display, and refresh_table_display methods have been discussed earlier.
The set_toolbar_interactive method triggers the toolbar event. You can use this method to construct the toolbar again to
include your own functions.
The set_user_command method allows you to replace the standard functions of the ALV grid control with your own
functions. To replace the function, query the current function code during the before_user_command event and change it
using the set_user_command.
ALV Method Calls
Sometimes, when you implement your own functions, you need to determine the current cell (cursor position). To do so,
use the get_current_cell method.

Programming Example – Replacing the Standard Function
In the example in the figure, the on_before_user_command handler method handles the before_user_command event.
This event is triggered before a user command (standard command or custom command) is processed.
You can redefine a standard command, for example, if the detailed view is used to display dependent data.
In the handler method, check if the function code for the detailed view was entered (WHEN
cl_gui_alv_grid=>mc_fc_detail). If so, set the function code of your self-defined command (in this case, DIS_BOOK).
Replace the function code.
Context Menus
Software Ergonomics Rules for Designing Context Menus
 Restrict the context menu to a maximum of two hierarchy levels.

 Restrict the context menu to a maximum of 10 entries, however, map all available buttons.
 Use separator lines for visual structuring.

 Place object-specific functions at the top of the menu.
You can use a context menu to provide functions to the users that depend on the respective program context. Use context
menus if you need to assign these functions to the control (or even part of it) and not to the entire screen.
Context Menus – Process Flow
A context menu is displayed if a user presses the right mouse button (or Shift + F10) and the mouse pointer is positioned
over a GUI control. When a user presses the right mouse button, the ALV grid control triggers the context_menu_request
event. The mouse pointer that is the corresponding control that triggers the alert determines the context.
If the user selects a function from the context menu, the ALV grid control triggers the user_command event. By default,
the ALV grid control has a context menu that you can replace or extend.
CONTEXT_MENU_REQUEST Event

control over which the mouse pointer is positioned triggers the context_menu_request event. To display a specific context
menu, implement a handler method for the event and register this handler method at the application server (SET
HANDLER ... FOR go_alv_grid).
Static Context Menu
The easiest way to create a context menu is to load a GUI status of type context menu. You can create a context menu in
the object list of the Object Navigator. Use the context menu of the Object Navigator to create a new GUI status with type
context menu and enter the required function codes and their texts in the Menu Painter. You create a submenu by entering
text but no code for a line in the Menu Painter. A small triangle on the right indicates that there is a submenu. You can
create a maximum of three levels.

Loading and Extending of a Context Menu
To load the GUI status into the context menu, use the static method load_gui_status of class cl_ctmenu.
The parameters are assigned the following values:
 Program
The program parameter is assigned the name of the ABAP program in which the GUI status was defined. Pass the
system variable sy-cprog if the status of the interface belongs to the interface of the current program.
 Status
The status parameter is assigned the name of the predefined GUI status.
 Disable
If you want to deactivate functions in the context menu, place the relevant function codes in an internal table with
type ui_functions and pass it to the disable parameter. These functions are then grayed out when the menu is
displayed.
 Menu
The menu parameter is the reference to the object of the cl_ctmenu class into which the GUI status needs to be
loaded.
You can extend the context menu that you loaded, using the add_function method of the cl_ctmenu class.
Dynamic Context Menus
The cl_ctmenu class provides the load_gui_status static method and a range of other methods. You can use these methods
to create or adjust the context menu at runtime by calling them in the handler method. For more information, see the
documentation for the cl_ctmenu class.

Processing Functions of Context Menus
If the user chooses a function of the context menu, the user_command event is triggered. The event exports the code of the
function that the user selects using the e_ucomm parameter.
user_command Event
A function code triggered through the context menu is processed in the same way as a function code that is triggered by a
button that you define. You must define, implement, and register a corresponding handler method for the user_command
event of your ALV instance on the application server. You then use the e_ucomm function code within the handler
method to decide the function that you need to execute.


Abap Details - Sap Hub

Uploaded by

Document Information

Original Title

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

Abap Details - Sap Hub

Uploaded by

Copyright:

Available Formats

ABAP Basics

Data Types and Data Objects

 Predefined ABAP types

 Global data types

 Local data types

Predefined ABAP Types

Numeric ABAP Data Types

SAP Locking Page 1 of 146

Data Type Description Length in Bytes/Initial Length Value Range Decimals

1 ... 16 Digits: 2*Length-1

Max: +/- 1.79E+308

Max: +/- 1E+385

Max: +/- 1E+6145

The numeric ABAP data types differ in the following ways:

 Rules for storage

Predefined ABAP Types - Character Types

Character ABAP Types

Sequence of 1 … 65535 LENGTH addition can be used to specify

SAP Locking Page 2 of 146

Predefined ABAP Types - Byte Types

ABAP Byte Types

Sequence of bytes in 1 … 65535 LENGTH addition used to specify length if

Predefined Data Types

TYPE <type_name> TYPE <ABAP-Type> LENGTH <length>.

DATA <obj_name> TYPE <ABAP-Type> LENGTH <length>.

TYPE <type_name>(<length>) TYPE <ABAP-Type>.

SAP Locking Page 3 of 146

Generic ABAP Types

Predefined Generic ABAP Types

Generic Data Type Meaning Compatible ABAP Types

any Any type All

data Any data type All

Elementary data type or flat,

numeric Numeric data type I, F, P, DECFLOAT16, DECFLOAT34

decfloat Numeric data type DECFLOAT16, and DECFLOAT34

SAP Locking Page 4 of 146

clike Character data type C, N, D, T, STRING

csequence Text data type C, and STRING

Data Object Categories

Data objects can be categorized as follows:

Type Reference Internal Structure Elementary Field

At least one deep

 Flat data objects

SAP Locking Page 5 of 146

 Deep data objects

 Text field literals

Visibility of Data Objects in Procedural ABAP

SAP Locking Page 6 of 146

Visibility of Data Objects in Object-Oriented ABAP

SAP Locking Page 7 of 146

Lifetime of Data Objects

The lifetime of a data object is usually linked with its visibility.

SAP Locking Page 8 of 146

Statements and Functions in ABAP

Expressions and Inline Declarations

The following expressions can be constructed in certain operand positions:

SAP Locking Page 9 of 146

Expressions are possible in both writer and reader positions.

SAP Locking Page 10 of 146

text = ‘Hello World’.

Using an inline declaration, the code is written as follows:

DATA(text) = ‘Hello World’.

Potential Pitfalls of the Use of Expressions