BC ABAP Programming PHẦN 8 ppt

BC - ABAP Programming SAP AG
Filling an Initial Screen using SPA/GPA Parameters
1074 December 1999
Filling an Initial Screen using SPA/GPA Parameters
To fill the input fields of a called transaction with data from the calling program, you can use the
SPA/GPA technique. SPA/GPA parameters are values that the system stores in the global, user-
specific SAP memory. SAP memory allows you to pass values between programs. A user can
access the values stored in the SAP memory during one terminal session for all parallel
sessions. Each SPA/GPA parameter is identified by a 20-character code. You can maintain them
in the Repository Browser in the ABAP Workbench. The values in SPA/GPA parameters are
user-specific.
ABAP programs can access the parameters using the SET PARAMETER and GET
PARAMETER statements.
To fill one, use:
SET PARAMETER ID <pid> FIELD <f>.
This statement saves the contents of field <f> under the ID <pid> in the SAP memory. The code
<pid> can be up to 20 characters long. If there was already a value stored under <pid>, this
statement overwrites it. If the ID <pid> does not exist, double-click <pid> in the ABAP Editor to
create a new parameter object.
To read an SPA/GPA parameter, use:
GET PARAMETER ID <pid> FIELD <f>.
This statement fills the value stored under the ID <pid> into the variable <f>. If the system does
not find a value for <pid> in the SAP memory, it sets SY-SUBRC to 4, otherwise to 0.
To fill the initial screen of a program using SPA/GPA parameters, you normally only need the
SET PARAMETER statement.
The relevant fields must each be linked to an SPA/GPA parameter.
On a selection screen, you link fields to parameters using the MEMORY ID addition in the
PARAMETERS or SELECT-OPTIONS statement. If you specify an SPA/GPA parameter ID when
you declare a parameter or selection option, the corresponding input field is linked to that input
field.
On a screen, you link fields to parameters in the Screen Painter. When you define the field

attributes of an input field, you can enter the name of an SPA/GPA parameter in the
Parameter
ID
field in the screen attributes. The SET parameter and GET parameter checkboxes allow you
to specify whether the field should be filled from the corresponding SPA/GPA parameter in the
PBO event, and whether the SPA/GPA parameter should be filled with the value from the screen
in the PAI event.
When an input field is linked to an SPA/GPA parameter, it is initialized with the current value of
the parameter each time the screen is displayed. This is the reason why fields on screens in the
R/3 System often already contain values when you call them more than once.
When you call programs, you can use SPA/GPA parameters with no additional programming
overhead if, for example, you need to fill obligatory fields on the initial screen of the called
program. The system simply transfers the values from the parameters into the input fields of the
called program.
However, you can control the contents of the parameters from your program by using the SET
PARAMETER statement before the actual program call. This technique is particularly useful if
you want to skip the initial screen of the called program and that screen contains obligatory fields.
SAP AG BC - ABAP Programming
Filling an Initial Screen using SPA/GPA
Parameters
December 1999 1075
If you want to set SPA/GPA parameters before a program call, you need to know which
parameters are linked to which fields on the initial screen. A simple way of doing this is to start
the program that you want to call, place the cursor on the input fields, and choose F1 followed by
Technical info. The Parameter ID field contains the name of the corresponding SPA/GPA
parameter. Alternatively, you can look at the screen definition in the Screen Painter.

The technical information for the first input field of the booking transaction TCG2
looks like this:
Airline

Booking number
Flight number
Flight date
Technical info.
Parameter ID CAR
The SPA/GPA parameter for the input field Company has the ID CAR. Use this
method to find the IDs CON, DAY, and BOK for the other input fields.
The following executable program is connected to the logical database F1S and calls
an update transaction:
REPORT BOOKINGS NO STANDARD PAGE HEADING.
TABLES SBOOK.
BC - ABAP Programming SAP AG
Filling an Initial Screen using SPA/GPA Parameters
1076 December 1999
START-OF-SELECTION.
WRITE: 'Select a booking',
/ ' '.
SKIP.
GET SBOOK.
WRITE: SBOOK-CARRID, SBOOK-CONNID,
SBOOK-FLDATE, SBOOK-BOOKID.
HIDE: SBOOK-CARRID, SBOOK-CONNID,
SBOOK-FLDATE, SBOOK-BOOKID.
AT LINE-SELECTION.
SET PARAMETER ID: 'CAR' FIELD SBOOK-CARRID,
'CON' FIELD SBOOK-CONNID,
'DAY' FIELD SBOOK-FLDATE,
'BOK' FIELD SBOOK-BOOKID.
CALL TRANSACTION 'BOOK'.
The basic list of the program shows fields from the database table SBOOK according

to the user entries on the selection screen. These data are also stored in the HIDE
areas of each line.
If the user selects a line of booking data by double-clicking, the system triggers the
AT LINE-SELECTION event and takes the data stored in the HIDE area to fill them
into the SPA/GPA parameters of the initial screen of the transaction. Then it calls the
transaction. Since you do not suppress the initial screen using AND SKIP FIRST
SCREEN, the initial screen may appear as follows:
SAP AG BC - ABAP Programming
Filling an Initial Screen using SPA/GPA
Parameters
December 1999 1077
Airline
Booking number
Flight number
Flight date
LH
2402
01/20/1995
00010001
If you would use the AND SKIP FIRST SCREEN option with the CALL
TRANSACTION statement, the second screen would appear immediately, since all
obligatory fields of the first screen are filled.
BC - ABAP Programming SAP AG
ABAP Database Access
1078 December 1999
ABAP Database Access
Application
Presentation
Database

ABAP
ABAP


ABAP
ABAP
This section describes how ABAP programs communicate with the central database in the R/3
System.
Accessing the Database in the R/3 System [Page 1079]
Open SQL [Page 1082]
Native SQL [Page 1161]
Logical Databases [Page 1210]
Contexts [Page 1273]
Programming Database Changes [Page 1312]
SAP AG BC - ABAP Programming
Accessing the Database in the R/3
System
December 1999 1079
Accessing the Database in the R/3 System
Berechtigungskonzept [Page 508]
In the R/3 System, long-life data is stored in relational database tables. In a relational database
model, the real world is represented by tables. A table is a two-dimensional matrix, consisting of
lines and columns (fields). The smallest possible combination of fields that can uniquely identify
each line of the table is called the key. Each table must have at least one key, and each table
has one key that is defined as its primary key. Relationships between tables are represented by
foreign keys.
Standard SQL
SQL (Structured Query Language) is a largely standardized language for accessing relational
databases. It can be divided into three areas:

• Data Manipulation Language (DML)
Statements for reading and changing data in database tables.
• Data Definition Language (DDL)
Statements for creating and administering database tables.
• Data Control Language (DCL)
Statements for authorization and consistency checks.
Each database has a programming interface that allows you to access the database tables using
SQL statements. The SQL statements in these programming interfaces are not fully
standardized. To access a specific database system, you must refer to the documentation of that
system for a list of the SQL statements available and their correct syntax.
The Database Interface
To make the R/3 System independent of the database system with which you use it despite the
differences in the SQL syntax between various databases, each work process on an application
server has a database interface. The R/3 System communicates with the database by means of
this interface. The database interface converts all of the database requests from the R/3 System
into the correct Standard SQL statements for the database system. To do this, it uses a
database-specific component that shields the differences between database systems from the
rest of the database interface. You choose the appropriate layer when you install the R/3
System.
BC - ABAP Programming SAP AG
Accessing the Database in the R/3 System
1080 December 1999
Native SQL
Module
Native SQL
Module
Open SQL
Modules
(Table module,
buffer management)

Open SQL
Modules
(Table module,
buffer management)
Database-specific layer
Database-specific layer
Native SQL Open SQL
Standard SQL (dynamic, embedded)
R/3 System programs
Database interface
Relational database
Application programs
Application programs
ABAP Dictionary
ABAP Dictionary
There are two ways of accessing the database from a program - with Open SQL or Native SQL.
Open SQL
Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow
you to access data irrespective of the database system that the R/3 installation is using. Open
SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it
allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data.
Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other
ABAP constructions, can simplify or speed up database access. It also allows you to buffer
certain tables on the application server, saving excessive database access. In this case, the
database interface is responsible for comparing the buffer with the database. Buffers are partly
stored in the working memory of the current work process, and partly in the shared memory for
all work processes on an application server. Where an R/3 System is distributed across more
than one application server, the data in the various buffers is synchronized at set intervals by the
buffer management. When buffering the database, you must remember that data in the buffer is
not always up to date. For this reason, you should only use the buffer for data which does not

often change. You specify whether a table can be buffered in its definition in the ABAP
Dictionary.
SAP AG BC - ABAP Programming
Accessing the Database in the R/3
System
December 1999 1081
Native SQL
Native SQL is only loosely integrated into ABAP, and allows access to all of the functions
contained in the programming interface of the respective database system. Unlike Open SQL
statements, Native SQL statements are not checked and converted, but instead are sent directly
to the database system. When you use Native SQL, the function of the database-dependent
layer is minimal. Programs that use Native SQL are specific to the database system for which
they were written. When writing R/3 applications, you should avoid using Native SQL wherever
possible. It is used, however, in some parts of the R/3 Basis System - for example, for creating or
changing table definitions in the ABAP Dictionary.
The ABAP Dictionary
The ABAP Dictionary, part of the ABAP Workbench, allows you to create and administer
database tables. Open SQL contains no statements from the DDL part of Standard SQL. Normal
application programs should not create or change their own database tables.
The ABAP Dictionary uses the DDL part of Open SQL to create and change database tables. It
also administers the ABAP Dictionary in the database. The ABAP Dictionary contains
metadescriptions of all database tables in the R/3 System. Only database tables that you create
using the ABAP Dictionary appear in the Dictionary. Open SQL statements can only access
tables that exist in the ABAP Dictionary.
Authorization and Consistency Checks
The DCL part of Standard SQL is not used in R/3 programs. The work processes within the R/3
System are logged onto the database system as users with full rights. The authorizations of
programs or users to read or change database tables is administered within the R/3 System
using the R/3 authorization concept. Equally, transactions must ensure their own data
consistency using the R/3 locking concept. For more information, refer to Programming

Database Updates [Page 1312]
BC - ABAP Programming SAP AG
Open SQL
1082 December 1999
Open SQL
Open SQL consists of a set of ABAP statements that perform operations on the central database
in the R/3 System. The results of the operations and any error messages are independent of the
database system in use. Open SQL thus provides a uniform syntax and semantics for all of the
database systems supported by SAP. ABAP programs that only use Open SQL statements will
work in any R/3 System, regardless of the database system in use. Open SQL statements can
only work with database tables that have been created in the ABAP Dictionary.
In the ABAP Dictionary, you can combine columns of different database tables to a database
view (or view for short). In Open SQL statements, views are handled in exactly the same way as
database tables. Any references to database tables in the following sections can equally apply to
views.
Overview
Open SQL contains the following keywords:
Keyword Function
SELECT Reads data from database tables
INSERT Adds lines to database tables
UPDATE Changes the contents of lines of database tables
MODIFY Inserts lines into database tables or changes the contents of existing lines
DELETE Deletes lines from database tables
OPEN CURSOR,
FETCH,
CLOSE CURSOR
Reads lines of database tables using the cursor
Return Codes
All Open SQL statements fill the following two system fields with return codes:
• SY-SUBRC

After
every Open SQL statement, the system field SY-SUBRC contains the value 0 if the
operation was successful, a value other than 0 if not.
• SY-DBCNT
After an open SQL statement, the system field SY-DBCNT contains the number of
database lines processed.
Client Handling
A single R/3 System can manage the application data for several separate areas of a business
(for example, branches). Each of these commercially separate areas in the R/3 System is called
a client, and has a number. When a user logs onto an R/3 System, they specify a client. The first
column in the structure of every database table containing application data is the client field
(MANDT, from the German word for client). It is also the first field of the table key. Only universal
system tables are client-independent, and do not contain a client name.
By default, Open SQL statements use automatic client handling. Statements that access
client-
dependent
application tables only use the data from the current client. You cannot specify a
condition for the client field in the WHERE clause of an Open SQL statement. If you do so, the
system will either return an error during the syntax check or a runtime error will occur. You
SAP AG BC - ABAP Programming
Open SQL
December 1999 1083
cannot overwrite the MANDT field of a database using Open SQL statements. If you specify a
different client in a work area, the ABAP runtime environment automatically overwrites it with the
current one before processing the Open SQL statement further.
Should you need to specify the client specifically in an Open SQL statement, use the addition
CLIENT SPECIFIED
directly after the name of the database table. This addition disables the automatic client handling
and you can use the field MANDT both in the WHERE clause and in a table work area.
Reading data [Page 1084]

Changing data [Page 1135]
BC - ABAP Programming SAP AG
Reading Data
1084 December 1999
Reading Data
Sperrkonflikten [Page 1134]
The Open SQL statement for reading data from database tables is:
SELECT <result>
INTO <target>
FROM <source>
[WHERE <condition>]
[GROUP BY <fields>]
[HAVING <cond>]
[ORDER BY <fields>].
The SELECT statement is divided into a series of simple clauses, each of which has a different
part to play in selecting, placing, and arranging the data from the database.
SAP AG BC - ABAP Programming
Reading Data
December 1999 1085
FROM clause
FROM clause
WHERE clause
WHERE clause
}
GROUP BY clause
GROUP BY clause
HAVING clause
HAVING clause
SELECT clause
SELECT clause

ORDER BY clause
ORDER BY clause
ABAP program
ABAP program
INTO clause
INTO clause
Clause Description
SELECT <result> [Page
1087]
The SELECT clause defines the structure of the data you want to
read, that is, whether one line or several, which columns you
want to read, and whether identical entries are acceptable or not.
INTO <target> [Page 1094] The INTO clause determines the target area <target> into which
the selected data is to be read.
FROM <source> [Page
1101]
The FROM clause specifies the database table or view
<source> from which the data is to be selected. It can also be
placed before the INTO clause.
WHERE <cond> [Page
1108]
The WHERE clause specifies which lines are to be read by
specifying conditions for the selection.
GROUP BY <fields> [Page
1116]
The GROUP-BY clause produces a single line of results from
groups of several lines. A group is a set of lines with identical
values for each column listed in <fields>.
BC - ABAP Programming SAP AG
Reading Data

1086 December 1999
HAVING <cond> [Page
1119]
The HAVING clause sets logical conditions for the lines
combined using GROUP BY.
ORDER BY <cond> [Page
1121]
The ORDER-BY clause defines a sequence <fields> for the lines
resulting from the selection.
The individual clauses and the ways in which they combine are all very important factors in the
SELECT statement. Although it is a single statement like any other, beginning with the SELECT
keyword and ending with a period, its division into clauses, and the ways in which they combine,
make it more powerful than other statements. A single SELECT statement can perform functions
ranging from simply reading a single line to executing a very complicated database query.
You can use SELECT statements in the WHERE and HAVING clauses. These are called
subqueries [Page 1124].
You can decouple the INTO clause from the SELECT statement by reading from the database
using a cursor [Page 1128].
SAP AG BC - ABAP Programming
Defining Selections
December 1999 1087
Defining Selections
The SELECT clause defines the structure of the result set (selection) that you want to read from
the database.
Column selection
Several lines
}
Single line
Names
Names

The selection can be flat (one line) or tabular (several lines). You can specify whether to accept
or exclude duplicate entries. The SELECT clause also specifies the names of the columns to be
read. You can replace the names of the database fields with alternative names. Aggregate
functions can be applied to individual columns.
The SELECT clause can be divided into two parts for lines and columns:
SELECT <lines> <cols>
<lines> specifies whether you want to read one or more lines. <cols> defines the column
selection.
Reading a Single Line
To read a single entry from the database, use the following:
SELECT SINGLE <cols> WHERE
To ensure that the line can be uniquely identified, you must specify values for all of the fields of
the primary key of the table in the WHERE clause. If the WHERE clause does not contain all of
the key fields, the syntax check produces a warning, and the SELECT statement reads the first
entry that it finds that matches the key fields that you have specified.
The result of the selection is either an elementary field or a flat structure, depending on the
number of columns you specified in <cols>. The target area in the INTO clause must be
appropriately convertible.
If the system finds a line with the corresponding key, SY-SUBRC is set to 0, otherwise to 4.
Reading Several Lines
To read a several entries from the database, use the following:
SELECT [DISTINCT] <cols> WHERE
BC - ABAP Programming SAP AG
Defining Selections
1088 December 1999
If you do not use DISTINCT (<lines> is then empty), the system reads all of the lines that satisfy
the WHERE condition. If you use DISTINCT, the system excludes duplicate entries.
The result of the selection is a table. The target area of the INTO clause can be an internal table
with a line type appropriate for <cols>. If the target area is not an internal table, but a flat
structure, you must include an ENDSELECT statement after the SELECT statement:

SELECT [DISTINCT] <cols> WHERE

ENDSELECT.
The lines are read in a loop [Page 246] one by one into the target area specified in the INTO
clause You can work with the target area within the loop.
If at least one line is read, SY-SUBRC is set to 0 after the statement (or loop) has been
processed. If no lines are read, SY-SUBRC is set to 4. The number of lines read is placed in the
system field SY-DBCNT. Within the loop, SY-DBCNT already contains the number of lines that
have already been passed to the target area.
Technically, it is possible to nest SELECT loops. However, for performance reasons, you should
avoid doing so. If you want to read interdependent data from more than one database table, you
can use a join in the FROM clause or a subquery in the WHERE clause.
Reading the Whole Line
To read all of the columns in the database table, use the following:
SELECT <lines> *
This reads all columns for the specified lines. The data type of the selected lines is a structure
with exactly the same data type as the database table in the ABAP Dictionary. The target area of
the INTO clause should be compatible with, or at least convertible into this data type. In the other
clauses, you can only address the columns under their names in the database table.
Reading individual columns can be considerably more efficient than reading all of the columns in
a table. You should therefore only read the columns that you need in your program.
Reading Single Columns
To read single columns from the database table, use the following:
SELECT <lines> <s
1
> [AS <a
1
>] <s
2
> [AS <a

2
>]
where <s
i
> are single columns. There are different ways of addressing the columns, depending
on the form of your FROM clause:
• <s
i
> specifies the component <c
i
> of the database table. This is only possible if the
corresponding name is unique. This is always the case if you only specify a single
database table in the FROM clause.
• <s
i
> specifies the full name of the required component in the form <dbtab>~<c
i
>, where
<dbtab> is the name of the database table. This is always necessary if the component
name appears in more than one database table in the FROM clause, and is only possible
if the database table <dbtab> only appears once in the FROM clause.
• <s
i
> specifies the full name of the required component in the form <tabalias>~<c
i
>,
where <tabalias> is an alias name for the database table. This is always necessary if the
table from which you want to read occurs more than once in the FROM clause. You
must define the alias name <tabalias> in the FROM clause.
SAP AG BC - ABAP Programming

Defining Selections
December 1999 1089
In the SELECT clause, you can use the AS addition to specify an alias name <a
i
> for each
column <s
i
>. The alias column name is used instead of the real name in the INTO and ORDER
BY clauses. This allows you for example, to read the contents of a column <s
i
> into a
component <a
i
> of a structure when you use the INTO CORRESPONDING FIELDS OF addition.
The data type of a column is the Dictionary type of the corresponding underlying domain in the
ABAP Dictionary. You must choose the data types of the target fields in the INTO clause so that
the Dictionary types can easily be converted. For a table of Dictionary types and their
corresponding ABAP data types, refer to Data Types in the ABAP Dictionary [Page 105].
Reading Aggregate Data for Columns
To read aggregate data for a column in the database, use the following:
SELECT <lines> <agg>( [DISTINCT] <s
1
> ) [AS <a
1
>]
<agg>( [DISTINCT] <s
2
> ) [AS <a
2
>]

where <s
i
> are the same field labels as above. The expression <agg> represents one of the
following aggregate functions:
• MAX: returns the maximum value of the column <s
i
>
• MIN: returns the minimum value of the column <s
i
>
• AVG: returns the average value of the column <s
i
>
• SUM: returns the sum value of the column <s
i
>
• COUNT: counts values or lines as follows:
•
••
• COUNT( DISTINCT <s
i
> ) returns the number of different values in the column
<s
i
>.
•
••
• COUNT( * ) returns the total number of lines in the selection.
You can exclude duplicate values from the calculation using the DISTINCT option. The spaces
between the parentheses and the arguments of the aggregate expressions must not be left out.

The arithmetic operators AVG and SUM only work with numeric fields.
The data type of aggregate functions using MAX, MIN, or SUM is the Dictionary type of the
corresponding column. Aggregate expressions with the function AVG have the Dictionary type
FLTP, and those with COUNT have the Dictionary type INT4. The target field should have the
corresponding type. When you calculate average values, it is a good idea to use the ABAP type
F. However, remember that the database system may use different approximations to ABAP.
When you calculate a sum, ensure that the target field is large enough.
Unlike ABAP, database systems recognize null values in database fields. A null value means
that a field has no contents, and it is not included in calculations. The result of the calculation is
only null if all of the lines in the selection contain the null value in the corresponding field. In
ABAP, the null value is interpreted as zero (depending on the data type of the field).
In the AS addition, you can define an alternative column name <a
i
> for each aggregate
expression. The alias column name is used instead of the real name in the INTO and ORDER
BY clauses. This is the only way of sorting by an aggregate expression in the ORDER BY
clause.
If the list in the SELECT clause (excepting aggregate expressions) contains one or more field
names, the field names must also be listed in the GROUP BY clause. The aggregate functions
do not then apply to all of the selected lines, but to the individual groups of lines.
BC - ABAP Programming SAP AG
Defining Selections
1090 December 1999
Specifying Columns Dynamically
You can also specify <cols> dynamically as follows:
SELECT <lines> (<itab>)
The parentheses must include the name of an internal table <itab> that is either empty or
contains <s
1
> <s

2
> to specify the columns or aggregate expressions to be read. For this
purpose, the line type of <itab> must be a type C field with a maximum length of 72. If the internal
table is empty, the system reads all columns.
Examples
Reading certain columns of a single line:
DATA WA TYPE SPFLI.
SELECT SINGLE CARRID CONNID CITYFROM CITYTO
INTO CORRESPONDING FIELDS OF WA
FROM SPFLI
WHERE CARRID EQ 'LH' AND CONNID EQ '0400'.
IF SY-SUBRC EQ 0.
WRITE: / WA-CARRID, WA-CONNID, WA-CITYFROM, WA-CITYTO.
ENDIF.
The output is:
SINGLE in the SELECT clause means that the statement reads a single entry from
the database table SPFLI where the primary key fields CARRID and CONNID have
the values specified in the WHERE clause. The columns specified in the SELECT
clause are transferred to the identically-named components of the structure WA.

Reading particular columns of more than one line:
DATA: ITAB TYPE STANDARD TABLE OF SPFLI,
WA LIKE LINE OF ITAB.
SELECT CARRID CONNID CITYFROM CITYTO
INTO CORRESPONDING FIELDS OF TABLE ITAB
FROM SPFLI
WHERE CARRID EQ 'LH'.
IF SY-SUBRC EQ 0.
LOOP AT ITAB INTO WA.
WRITE: / WA-CARRID, WA-CONNID, WA-CITYFROM, WA-CITYTO.

ENDLOOP.
ENDIF.
The output is:
SAP AG BC - ABAP Programming
Defining Selections
December 1999 1091
Since there are no lines specified in the SELECT clause, the statement reads all of
the lines from the database table SPFLI that satisfy the condition in the WHERE
clause. The columns specified in the SELECT clause are transferred to the
identically-named components of the internal table ITAB.

Reading all columns of more than one line:
DATA WA TYPE SPFLI.
SELECT *
INTO CORRESPONDING FIELDS OF WA
FROM SPFLI
WHERE CARRID EQ 'LH'.
WRITE: / SY-DBCNT,
WA-CARRID, WA-CONNID, WA-CITYFROM, WA-CITYTO.
ENDSELECT.
The output is:
Since there are no lines specified in the SELECT clause, the statement reads all of
the lines from the database table SPFLI that satisfy the condition in the WHERE
clause. All of the columns in the table are transferred to the identically-named
components of the flat structure WA. This is why you must conclude the SELECT
loop with the ENDSELECT statement.

Aggregate functions
Suppose a database table TEST, consisting of two columns and 10 lines:
COL_1 COL_2

13
21
35
47
52
63
71
89
94
10 3
BC - ABAP Programming SAP AG
Defining Selections
1092 December 1999
The following coding demonstrates the aggregate functions:
DATA RESULT TYPE P DECIMALS 2.
SELECT <agg>( [DISTINCT] COL_2 )
INTO RESULT
FROM TEST.
WRITE RESULT.
The following table shows the results of this program extract according to different
combinations of aggregate expressions <agg> and the DISTINCT option.
Aggregate expression DISTINCT Result
MAX no 9.00
MAX yes 9.00
MIN no 1.00
MIN yes 1.00
AVG no 3.80
AVG yes 4.43
SUM no 38.00
SUM yes 31.00

COUNT yes 7.00
COUNT( * ) 10.00

Specifying Columns Dynamically
DATA: ITAB TYPE STANDARD TABLE OF SPFLI,
WA LIKE LINE OF ITAB.
DATA: LINE(72) TYPE C,
LIST LIKE TABLE OF LINE(72).
LINE = ' CITYFROM CITYTO '.
APPEND LINE TO LIST.
SELECT DISTINCT (LIST)
INTO CORRESPONDING FIELDS OF TABLE ITAB
FROM SPFLI.
IF SY-SUBRC EQ 0.
LOOP AT ITAB INTO WA.
WRITE: / WA-CITYFROM, WA-CITYTO.
ENDLOOP.
ENDIF.
The output is:
SAP AG BC - ABAP Programming
Defining Selections
December 1999 1093
The internal table ITAB contains the columns of the database table SPFLI to be read.
The DISTINCT addition in the SELECT clause means that the statement only reads
those lines that have different contents in both of these columns. The result is a list
of possible routes.
BC - ABAP Programming SAP AG
Specifying a Target Area
1094 December 1999
Specifying a Target Area

The INTO clause defines the target area into which the selection from the SELECT clause is
written. Suitable target areas are variables [Page 124] whose data type is compatible with or
convertible into that of the selection in the SELECT clause.
The SELECT clause determines the data type of the target area as follows:
• The <lines> specification in the SELECT clause determines the depth of the target area,
that is, whether it is a flat or a tabular structure.
• The <cols> specification in the SELECT clause determines the structure (line type) of the
target area.
}
Target area
Target area
Structure
Structure
Depth
Depth
ABAP
ABAP
Selection
Selection
If you select a single line, the target area must be flat. If you select more than one line, the target
area may be either tabular or flat. If the target area is flat, you need to use a SELECT loop.
When you select all of the columns, the target area must either be a structure or convertible into
one. When you select individual columns, the target area can be a component of a structure or a
single field.
The elementary data types in the selection in the SELECT clause are Dictionary types. These
Dictionary types must be able to be converted into the ABAP data types of the corresponding
elementary components of the target area. For a table of data types, refer to Data Types in the
ABAP Dictionary [Page 105].
SAP AG BC - ABAP Programming
Specifying a Target Area

December 1999 1095
Specifying a Flat Work Area
You can specify a flat work area regardless of whether you are reading from a single line or from
several. To read data into one, use the following in the INTO clause:
SELECT INTO [CORRESPONDING FIELDS OF] <wa>
The target area must be at least as large as the line to be read into it. However, this is the only
restriction on its data type. You should base your choice of data type on the specifications in the
SELECT clause such that the columns that you have read can be addressed in <wa>.
If you specify an asterisk (*) in the SELECT clause (select all columns), the data is transferred
into the work area from left to right according to the structure of the database table. The
structure of <wa> is irrelevant in this case. In order to enable you to address the values in the
individual columns after the SELECT statement, the work area should have the same structure
as the database table.
If you specified individual columns or aggregate expressions in the SELECT clause, the columns
are transferred into the work area from left to right according to the structure of the work area.
When you read the data into <wa>, its previous contents are overwritten. However, the
components of <wa> that are not affected by the SELECT statement retain their previous values.
If the work area is structured, you can use the CORRESPONDING FIELDS addition. This
transfers only the contents of fields whose names are identical in the database table and the
work area. This includes any alias column names that you specified in the selection. Working
with the CORRESPONDING FIELDS option of the INTO clause does not limit the amount of data
read from the database, but only the amount of data that is read from the resulting set into the
ABAP program. The only way of restricting the number of columns read is in the SELECT clause.
If you use the asterisk (*) option to read all of the columns of a single database table <dbtab> in
the SELECT clause, the INTO clause may be empty. The SELECT statement then writes the
data by default into the table work area with the same name <dbtab> as the database table itself.
You
must declare this table work area using the TABLES [Page 131] statement. Before Release
4.0, this was necessary before you could read data from a database table at all, and was
frequently used as an implicit work area. Nowadays, table work areas are still useful as interface

work areas, but should no longer be used as the work area in the SELECT statement. Like
internal tables without header lines, having different names for the source and target areas
makes programs clearer.
Specifying Internal Tables
When you read several lines of a database table, you can place them in an internal table. To do
this, use the following in the INTO clause:
SELECT INTO|APPENDING [CORRESPONDING FIELDS OF] TABLE <itab>
[PACKAGE SIZE <n>]
The same applies to the line type of <itab>, the way in which the data for a line of the database
table are assigned to a table line, and the CORRESPONDING FIELDS addition as for flat work
areas (see above).
The internal table is filled with all of the lines of the selection. When you use INTO, all existing
lines in the table are deleted. When you use APPENDING; the new lines are added to the
existing internal table <itab>. With APPENDING, the system adds the lines to the internal table
appropriately for the table type. Fields in the internal table not affected by the selection are filled
with initial values.
BC - ABAP Programming SAP AG
Specifying a Target Area
1096 December 1999
If you use the PACKAGE SIZE addition, the lines of the selection are not written into the internal
table at once, but in packets. You can define packets of <n> lines that are written one after the
other into the internal table. If you use INTO, each packet replaces the preceding one. If you use
APPENDING, the packets are inserted one after the other. This is only possible in a loop that
ends with ENDSELECT. Outside the SELECT loop, the contents of the internal table are
undetermined. You must process the selected lines within the loop.
Specifying Single Fields
If you specify single columns of the database table or aggregate expressions in the SELECT
clause, you can read the data into single fields for a single entry or for multiple entries in a
SELECT loop. To read data into single fields, use the following in the INTO clause:
SELECT INTO (<f

1
>, <f
2
>, ).
You must specify as many individual fields <f
i
> as are specified in the field list of the SELECT
clause. The fields in the SELECT clause are assigned, from left to right, to the fields in the list in
the INTO clause.
You do not have to use a field list in the INTO clause when you specify individual fields in the
SELECT clause - you can also use the CORRESPONDING FIELDS addition to read the data
into a flat work area or an internal table instead. In that case, the target area does not need to
contain the same number of elements as the list in the SELECT clause.
Examples
Flat structure as target area
DATA WA TYPE SPFLI.
SELECT *
INTO WA
FROM SPFLI.
WRITE: / WA-CARRID
ENDSELECT.
This example uses a flat structure with the same data type as the database table
SPFLI as the target area in a SELECT loop. Within the loop, it is possible to address
the contents of the individual columns.
DATA SPFLI TYPE SPFLI.
SELECT *
FROM SPFLI.
WRITE: / SPFLI-CARRID
ENDSELECT.
This example declares a structure SPFLI with the same name as the database table

you want to read. This structure is used implicitly as the target area in the SELECT
loop. Since the names are the same, it is possible to overlook the fact that you are
working with an ABAP data object here and not the database table itself.
SAP AG BC - ABAP Programming
Specifying a Target Area
December 1999 1097

Internal table as target area
DATA: BEGIN OF WA,
CARRID TYPE SPFLI-CARRID,
CONNID TYPE SPFLI-CONNID,
CITYFROM TYPE SPFLI-CITYFROM,
CITYTO TYPE SPFLI-CITYTO,
END OF WA,
ITAB LIKE SORTED TABLE OF WA
WITH NON-UNIQUE KEY CITYFROM CITYTO.
SELECT CARRID CONNID CITYFROM CITYTO
INTO CORRESPONDING FIELDS OF TABLE ITAB
FROM SPFLI.
IF SY-SUBRC EQ 0.
WRITE: / SY-DBCNT, 'Connections'.
SKIP.
LOOP AT ITAB INTO WA.
WRITE: / WA-CARRID, WA-CONNID, WA-CITYFROM, WA-CITYTO.
ENDLOOP.
ENDIF.
The output is:
The target area is a sorted table ITAB containing four fields with the same names
and data types as the database table SPFLI. The program uses the
CORRESPONDING FIELDS addition to place the columns from the SELECT clause

into the corresponding fields of the internal table. Because ITAB is a sorted table, the
data is inserted into the table sorted by the table key of ITAB.

Reading packets into an internal table
DATA: WA TYPE SPFLI,
ITAB TYPE SORTED TABLE OF SPFLI
WITH UNIQUE KEY CARRID CONNID.
BC - ABAP Programming SAP AG
Specifying a Target Area
1098 December 1999
SELECT CARRID CONNID
FROM SPFLI
INTO CORRESPONDING FIELDS OF TABLE ITAB
PACKAGE SIZE 3.
LOOP AT ITAB INTO WA.
WRITE: / WA-CARRID, WA-CONNID.
ENDLOOP.
SKIP 1.
ENDSELECT.
The output is:
The example reads packets of three lines each into the sorted table ITAB. In each
pass of the SELECT loop, the internal table has a different sorted content.
If you were to use APPENDING instead of INTO, the list would look like this: