ABAP

ABAP/4

Paradigm	Object-oriented, structured, imperative
Designed by	SAP AG
First appeared	1980s
Typing discipline	Static, strong, safe, nominative
OS	Cross-platform
Website	https://www.sdn.sap.com/irj/sdn/abap
Major implementations
SAP R/2, SAP R/3
Influenced by
Objective-C, COBOL, Java

ABAP (Advanced Business Application Programming, originally Allgemeiner Berichts-Aufbereitungs-Prozessor, German for "general report creation processor" .) is a very high level programming language created by the German software company SAP. It is currently positioned, alongside the more recently introduced Java, as the language for programming SAP's Web Application Server, part of its NetWeaver platform for building business applications. Its syntax is somewhat similar to COBOL.

Introduction

ABAP is one of the many application-specific fourth-generation languages (4GLs) first developed in the 1980s. It was originally the report language for SAP R/2, a platform that enabled large corporations to build mainframe business applications for materials management and financial and management accounting.

ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of "generic report preparation processor" , but was later renamed to Advanced Business Application Programming. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level(s).

The ABAP programming language was originally used by developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language is fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts, are required to create ABAP programs.

ABAP remains the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP's applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.

SAP's current development platform NetWeaver supports both ABAP and Java.

Where does the ABAP program run?

All ABAP programs reside inside the SAP database. They are not stored in separate external files like Java or C++ programs. In the database all ABAP code exists in two forms: source code, which can be viewed and edited with the ABAP Workbench tools, and generated code, a binary representation somewhat comparable with Java bytecode. ABAP programs execute under the control of the runtime system, which is part of the SAP kernel. The runtime system is responsible for processing ABAP statements, controlling the flow logic of screens and responding to events (such as a user clicking on a screen button); in this respect it can be seen as a Virtual Machine comparable with the Java VM. A key component of the ABAP runtime system is the Database Interface, which turns database-independent ABAP statements ("Open SQL") into statements understood by the underlying DBMS ("Native SQL"). The database interface handles all the communication with the relational database on behalf of ABAP programs; it also contains extra features such as buffering of stable and frequently accessed data in the local memory of the application server.

SAP Basis

The ABAP language environment, including the syntax checking, code generation and runtime system, is part of the SAP Basis component. SAP Basis is the technological platform that supports the entire range of SAP applications, now typically implemented in the framework of the SAP Web Application Server. In that sense SAP Basis can be seen as the virtual machine on which SAP applications run. Like any operating system, SAP Basis contains both low-level services (for example memory management, database communication or servicing Web requests) and high-level tools for end users and administrators. These tools can be executables ("SAP kernel") running directly on the underlying operating system, transactions developed in ABAP, or Web-based interfaces.

SAP Basis also provides a layer of abstraction between the business applications and the operating system and database. This ensures that applications do not depend directly upon a specific server or database platform and can easily be ported from one platform to another.

SAP Basis currently runs on UNIX (AIX, HP-UX, Solaris, Linux), Microsoft Windows, i5/OS on IBM System i (formerly iSeries, AS/400) and z/OS on IBM System z (formerly zSeries, S/390). Supported databases are IBM DB2, Informix, MaxDB, Oracle and Microsoft SQL Server (support for Informix was discontinued in SAP Basis release 7.00).

SAP systems and landscapes

All SAP data exists and all SAP software runs in the context of an SAP system. A system consists of a central relational database and one or more application servers ("instances") accessing the data and programs in this database. An SAP system contains at least one instance but may contain more, mostly for reasons of sizing and performance. In a system with multiple instances, load balancing mechanisms ensure that the load is spread evenly over the available application servers.

Installations of the Web Application Server (landscapes) typically consist of three systems: one for development, one for testing and quality assurance, and one for production. The landscape may contain more systems, e.g. separate systems for unit testing and pre-production testing, or it may contain fewer, e.g. only development and production, without separate QA; nevertheless three is the most common configuration. ABAP programs are created and undergo first testing in the development system. Afterwards they are distributed to the other systems in the landscape. These actions take place under control of the Change and Transport System (CTS), which is responsible for concurrency control (e.g. preventing two developers from changing the same code at the same time), version management and deployment of programs on the QA and production systems.

The Web Application Server consists of three layers: the database layer, the application layer and the presentation layer. These layers may run on the same or on different physical machines. The database layer contains the relational database and the database software. The application layer contains the instance or instances of the system. All application processes, including the business transactions and the ABAP development, run on the application layer. The presentation layer handles the interaction with users of the system. Online access to ABAP application servers can go via a proprietary graphical interface, the SAPGUI, or via a Web browser.

Transactions

A transaction in SAP terminology is the execution of a program. The normal way of executing ABAP code in the SAP system is by entering a transaction code (for instance, VA01 is the transaction code for "Create Sales Order"). Transactions can be called via system-defined or user-specific, role-based menus. They can also be started by entering the transaction code directly into a command field, which is present in every SAP screen. Transactions can also be invoked programmatically by means of the ABAP statements CALL TRANSACTION and LEAVE TO TRANSACTION.

The term "transaction" must not be misunderstood here; in the context just described, a transaction simply means calling and executing an ABAP program. In application programming, "transaction" often refers to an indivisible operation on data, which is either committed as a whole or undone (rolled back) as a whole. This concept exists in SAP and is called as LUW (Logical Unit of Work). In the course of one transaction (program execution), there can be different LUWs.

Types of ABAP programs

As in other programming languages, an ABAP program is either an executable unit or a library, which provides reusable code to other programs and is not independently executable.

ABAP distinguishes two types of executable programs:

• Reports
• Module pools

Reports follow a relatively simple programming model whereby a user optionally enters a set of parameters (e.g. a selection over a subset of data) and the program then uses the input parameters to produce a report in the form of an interactive list. The term "report" can be somewhat misleading in that reports can also be designed to modify data; the reason why these programs are called reports is the "list-oriented" nature of the output they produce.

Module pools define more complex patterns of user interaction using a collection of screens. The term “screen” refers to the actual, physical image that the user sees. Each screen also has a “flow logic”, which refers to the ABAP code implicitly invoked by the screens. Each screen has its own flow logic, which is divided into a "PBO" (Process Before Output) and "PAI" (Process After Input) section. In SAP documentation the term “dynpro” (dynamic program) refers to the combination of the screen and its flow logic.

The non-executable program types are:

• INCLUDE modules
• Subroutine pools
• Function groups
• Object classes
• Interfaces
• Type pools

An INCLUDE module gets included at generation time into the caling unit; it is often used to subdivide very large programs. Subroutine pools contain ABAP subroutines (blocks of code enclosed by FORM/ENDFORM statements and invoked with PERFORM). Function groups are libraries of self-contained function modules (enclosed by FUNCTION/ENDFUNCTION and invoked with CALL FUNCTIION). Object classes and interfaces are similar to Java classes and interfaces; the first define a set of methods and attributes, the second contain "empty" method definitions, for which any class implementing the interface must provide explicit code. Type pools define collections of data types and constants.

ABAP Workbench

The ABAP Workbench contains different tools for editing programs. The most important of these are (transaction codes are shown in parentheses):

• ABAP Editor for writing and editing reports, module pools, includes and subroutine pools (SE38)
• ABAP Dictionary for processing database table definitions and retrieving global types (SE11)
• Menu Painter for designing the user interface (menu bar, standard toolbar, application toolbar, function key assignment) (SE41)
• Screen Painter for designing screens and flow logic (SE51)
• Function Builder for function modules (SE37)
• Class Builder for ABAP Objects classes and interfaces (SE24)

The ABAP Workbench (transaction SE80) provides a single integrated interface into these various tools.

ABAP Dictionary

The ABAP Dictionary contains all metadata about the data in the SAP system. It is closely linked with the ABAP Workbench in that any reference to data (e.g. a table, view, data type, etc.) will be obtained from the dictionary. Developers use the ABAP Dictionary transactions (directly or through the SE80 ABAP Workbench) to display and maintain this metadata.

When a dictionary object is changed, a program that references the changed object will automatically reference the new version the next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference changed dictionary objects.

A brief description of the most important types of dictionary objects follows:

• Tables are data containers that exist in the underlying relational database. In the majority of cases there ia a 1-to-1 relationship between the definition of a table in the ABAP Dictionary and the definition of that same table in the database (same name, same columns). These tables are known as "transparent". There are two types of non-transparent tables: "pooled" tables exist as independent entities in the ABAP Dictionary but they are grouped together in large physical tables ("pools") at the database level. Pooled tables are often small tables holding for example configuration data. "Clustered" tables are physically grouped in "clusters" based on their primary keys; for instance, assume that a clustered table H contains "header" data about sales invoices, whereas another clustered table D holds the invoice line items. Each row of H would then be physically grouped with the related rows from D inside a "cluster table" in the database. This type of clustering, which is designed to improve performance, also exists as native functionality in some, though not all, relational database systems.
• Indexes provide acelerated access to table data for often used selection conditions. Every SAP table has a "primary index", which is created implicitly along with the table and is used to enforce primary key uniqueness. Additional indexes (unique or non-unique) may be defined; these are called "secondary indexes".
• Views have the same purpose as in the underlying database: they define subsets of columns (and/or rows) from one or - using a join condition - several tables.
• Structures are complex data types consisting of multiple fields (comparable to struct in C/C++).
• Data elements provide the semantic content for a table or structure field. For example, dozens of tables and structures might contain a field giving the price (of a finished product, raw material, resource, ...). All these fields could have the same data element "PRICE".
• Domains define the structural characteristics of a data element. For example, the data element PRICE could have an assigned domain that defines the price as a numeric field with 2 decimals. Domains can also carry semantic content in providing a list of possible values. For example, a domain "BOOLEAN" could define a field of type "character" with length 1 and case-insensitive, but would also restrict the possible values to "T" (true) or "F" (false).
• Search helps (successors to the now obsolete "matchcodes") provide advanced search strategies when a user wants to see the possible values for a data field. The ABAP runtime provides an implicit assistance (by listing all values for the field, e.g. all existing customer numbers) but search helps can be used to extend this functionality, e.g. by providing customer searches by geographical locaton, credit rating, etc.)
• Lock objects implement application-level locking when changing data.

ABAP syntax

This brief description of the ABAP syntax begins inevitably with the ubiquitous "Hello World" program.

"Helloworld"

REPORT TEST.
WRITE 'Hello World'.

This example contains two statements: REPORT and WRITE. The program displays a list on the screen. In this case, the list consists of the single line "Hello World". The REPORT statmlent indicates that this program is a report. An alternative statement, PROGRAM, would be used for a module pool.

Formatting rules

The basic formatting rules of ABAP are simple:

• Every ABAP statement must end in a period
• Tokens within a statement must be separated by at least one space
• An end of line is equivalent to a space
• Statements and keywords are not case-sensitive

The "Hello World" program could be legally rewritten as follows:

REPORT tESt. WRITE
      'Hello World' .

To ensure that code is readable, the ABAP editor provides a "Pretty Printer" function, which takes care of proper indentation. The Pretty Printer also offers a choice between several models of case standardization (all upper case, all lower case, upper case for statements/keywords, upper case for variable names).

If a text literal in an ABAP statement extends across more than one line, then a ‘&’ character must be used to combine a succession of text literals into a single one. Example:

USERPROMPT = 'Please double-click on a line in the output list ' &
             'to see the complete details of the transaction.'.

The rule that tokens must be separated by at least one space extends even to operators, parentheses and other symbols. For example the following code is incorrect:

X=(A+B)-(C+1).

The variable names (X, A, B, C), the numeric constant 1, the operators "=", "+" and "-" and the parentheses must all be white-space delimited. The correct code is:

X = ( A + B ) - ( C + 1 ).

Chained statements

Consecutive statements with an identical first (leftmost) part can be combined into a chain statement using the chain operator ":" (colon). The common part of the statements is written to the left of the colon, the differing parts are written to the right of the colon and separated by commas. The colon operator is attached directly to the preceding token, without a preceding space (the same applies to the commas in the token list on the right, as can be seen in the examples below).

Chaining is very often used in WRITE statements. WRITE accepts just one argument, so if for instance you wanted to display three fields from a structure called FLIGHTINFO, you would have to code:

WRITE FLIGHTINFO-CITYFROM.
WRITE FLIGHTINFO-CITYTO.
WRITE FLIGHTINFO-AIRPTO.

Chaining the statements results in a more readable and more intuitive form:

WRITE: FLIGHTINFO-CITYFROM, FLIGHTINFO-CITYTO, FLIGHTINFO-AIRPTO.

In a chain statement, the first part (before the colon) is not limited to the statement name alone. The entire common part of the consecutive statements can be placed before the colon. Example:

REPLACE 'A' WITH 'B' INTO LASTNAME.
REPLACE 'A' WITH 'B' INTO FIRSTNAME.
REPLACE 'A' WITH 'B' INTO CITYNAME.

could be rewritten in chained form as:

REPLACE 'A' WITH 'B' INTO: LASTNAME, FIRSTNAME, CITYNAME.

Comments

ABAP has 2 ways of defining text as a comment:

• An asterisk (*) in the leftmost column of a line makes the entire line a comment
• A double quotation mark («"») anywhere on a line makes the rest of that line a comment

Example

***************************************
** Program: BOOKINGS                 **
** Author: Joe Byte, 07-Jul-2007     **
***************************************

REPORT BOOKINGS.

* Read flight bookings from the database
SELECT * FROM FLIGHTINFO
  WHERE CLASS = 'Y'       "Y = economy
  OR    CLASS = 'C'.      "C = business
(...)

Data types and variables

ABAP provides a set of built-in data types. In addition, every structure, table, view or data element defined in the ABAP Dictionary can be used to type a variable. Also, object classes and interfaces can be used as types.

File:Data types.gif

Data and Types

The built-in data types are:

Type	Description
I	Integer (4-bytes)
P	Packed decimal
F	Floating point
N	Character numeric
C	Character
D	Date
T	Time
X	Hexadecimal (raw byte)
STRING	Variable-length string
XSTRING	Variable-length raw byte array

Date variables or constants (type D) contain the number of days since January 1, AD 1. Time variables or constants (type T) contain the number of seconds since midnight. A special characteristic of both types is that they can be accessed both as integers and as character strings (with internal format "YYYYMMDD" for dates and "hhmmss" for times), which makes date/time handling very easy. For example, the code snippet below calculates the last day of the previous month (note: SY-DATUM is a system-defined variable containing the current date):

DATA LAST_EOM    TYPE D.  "last end-of-month date

* Start from today's date
  LAST_EOM = SY-DATUM.
* Set characters 6 and 7 (0-relative) of the YYMMDD string to "01",
* giving the first day of the current month
  LAST_EOM+6(2) = '01'.
* Subtract one day
  LAST_EOM = LAST_EOM - 1. 

  WRITE: 'Last day of previous month was', LAST_EOM.

All ABAP variables must be explicitly declared in order to be used. Normally all declarations are placed at the top of the code module (program, subroutine, function) before the first executable statement; this placement is a convention and not an enforced syntax rule. The declaration consists of the name, type, length (where applicable), additional modifiers (e.g. the number of implied decimals for a packed decimal field) and optionally an initial value:

* Primitive types:
DATA: COUNTER      TYPE I,
      VALIDITY     TYPE I VALUE 60,
      TAXRATE(3)   TYPE P DECIMALS 1,
      LASTNAME(20) TYPE C,
      DESCRIPTION  TYPE STRING.

* Dictionary types:
DATA: ORIGIN       TYPE COUNTRY.

* Internal table:
DATA: T_FLIGHTS    TYPE TABLE OF FLIGHTINFO,
      T_LOOKUP     TYPE HASHED TABLE OF FLT_LOOKUP.

* Objects:
DATA: BOOKING      TYPE REF TO CL_FLT_BOOKING.

Notice the use of the colon to chain together consecutive DATA statements.

ABAP Objects

The ABAP language supports object-oriented programming, through a feature known as "ABAP Objects" . This helps to simplify applications and make them more controllable.

ABAP Objects is fully compatible with the existing language, so one can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs. Syntax checking is stronger in ABAP Objects programs, and some syntactical forms (usually older ones) of certain statements are not permitted.

ABAP statements – an overview

In contrast with languages like C/C++ or Java, which define a limited set of language-specific statements and provide most functionality via libraries, ABAP contains an extensive body of built-in statements. These statements often support many options, which explains why ABAP programs look "verbose", especially when compared with programs written in C, C++ or Java.

This section lists some of the most important statements in the language, subdivided by function. Both the statements listed here and the subdivision used are fairly arbitrary and by no means exhaustive.

Declarative statements

These statements define data types or declare data objects which are used by the other statements in a program or routine. The collected declarative statements in a program or routine make up its declaration part.

Examples of declarative keywords:

TYPES, DATA, CONSTANTS, PARAMETERS, TABLES

Modularization statements

These statements define the processing blocks in an ABAP program.

The modularization statements can be further divided into event statements and defining statements:

Event statements

These are used to define the beginning of event processing blocks. There are no special statements to mark the end of such blocks - they end when the next processing block is introduced.

Examples of event keywords are:

AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND

Defining statements

These statements delineate callable code units such as subroutines, function modules and methods. The statement marking the end of the unit has the name of the opening statement prefixed with "END".

Examples of defining keywords:

FORM ..... ENDFORM, FUNCTION ... ENDFUNCTION,
MODULE ... ENDMODULE, METHOD ... ENDMETHOD

Control statements

These statements control the flow of the program within a processing block.

Statements controlling conditional execution are:

IF ... ELSEIF ... ELSE ... ENDIF
CASE ... ENDCASE
CHECK

The CHECK statement verifies a condition and exits the current processing block (e.g. loop or subroutine) if the condition is not satisfied.

Several statements exist to define a loop:

DO ... ENDDO
WHILE ... ENDWHILE
LOOP ... ENDLOOP

DO/ENDDO defines an unconditional loop. An exit condition (typically in the form "IF <condition>. EXIT. ENDIF.") must be provided inside the body of the loop. A variant (DO <n> TIMES) sets as exit condition the number of times the loop body is executed. WHILE/ENDWHILE defines a conditional loop. The condition is tested at the beginning of the loop. LOOP/ENDLOOP loops over the lines of an internal table. The loop ends after processing the last line of the internal table.

Call statements

These statements call processing blocks defined using the corresponding modularization statements. The blocks can either be in the same ABAP program or in a different program.

Examples of call keywords:

PERFORM, CALL METHOD, CALL TRANSACTION, CALL SCREEN, SUBMIT, LEAVE TO transaction

Operational statements

These statements retrieve or modify the contents of variables.

A first group of operational statements assign or change a variable:

MOVE, ADD, SUBTRACT, DIVIDE

These statements, whose syntax originates in COBOL, can be written in a shorter form that uses operators rather than keywords:

MOVE LASTNAME TO RECIPIENT.
* is equivalent to
RECIPIENT = LASTNAME.

ADD TAX TO PRICE.
* is equivalent to
PRICE = PRICE + TAX.

Examples of operational statements on character strings:

SEARCH, REPLACE, CONCATENATE, CONDENSE

Database access statements (Open SQL):

SELECT, INSERT, UPDATE, DELETE, MODIFY

Statements working on internal tables (notice that some "SQL" statements can also be used here):

READ TABLE, INSERT, UPDATE, DELETE, MODIFY, SORT, DELETE ADJACENT DUPLICATES, REFRESH

Formatting statements

These statements produce or format output. They appear mainly in reports, less so in module pools. Examples are:

WRITE, FORMAT, SKIP, ULINE, MESSAGE, NEW-PAGE

Internal tables in ABAP

Internal tables are an extremely important feature of the ABAP language and merit to be explained at some length. Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, each line having the same structure. In ABAP, internal tables fulfil the function of arrays. Internal tables are used whenever there is a need to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.

An internal table would be defined as a vector of structs in C++ or a vector of objects in Java. The main difference with these languages is that ABAP provides a collection of statements to easily access and manipulate the contents of internal tables. It should be noted that ABAP does not support arrays; the only way to define a multi-element data object is to use an internal table.

Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects. A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary.

Internal tables as data types

Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.

Line type

The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.

Line Type can also refer to an ABAP Object's reference pointer value. If two ABAP Objects are not related, they do not have the same line type. The line type is stored in the value of the reference pointer and can be viewed in the debugger. If one object attempts to access another unrelated object's components, you will receive an error specifying that the line types do not match.

Key

The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key is UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries with the same key. The uniqueness depends on the table access method.

If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. An internal table which has a line type that is itself an internal table, has an empty key.

The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.

Later versions of ABAP permit the definition of secondary keys.

Table type

The table type determines how will access individual table entries. Internal tables can be divided into three types:

Standard tables have an internal linear index. (Think of index as "record number". It is not to be confused with a database index, for example). From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.

Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.

Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.

Generic internal tables

Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures. You cannot use them to declare data objects.

Internal tables as dynamic data objects

Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.

Choosing a table type

The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.

Standard tables

This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.

Sorted tables

This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table

Hashed tables

This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data..

See also

• ERP software
• asXML

External links

• SAP Help Portal
• ABAP in the SAP Developer Network
• ABAP eLearning
• ABAP Objects
• ABAP at Curlie
• SAP Spanish Forums
• SAP ABAP Tutorial