SELECT result [target] FROM source [where]
[GROUP BY fields] [ORDER BY order].
Retrieves an extract and/or a set of data from a
database table or view (see
Relational database ). SELECT belongs to the
OPEN SQL command set.
Each SELECT command consists of a series of clauses specifying
The SELECT result clause
whether the result of the selection is a table or a single record,
which columns the result is meant to have and
whether the result is allowed to include identical lines.
The INTO target clause
specifies the target area into which the selected data is to be read.
If the target area is an internal table, the INTO clause
whether the selected data is to overwrite the contents of the
internal table or
whether the selected data is to be appended to the contents and
whether the selected data is to be placed in the internal table all
at once or in several packets.
The INTO clause can also follow the FROM clause.
You can omit the INTO clause. The system then makes the data
available in the table work area (see TABLES )
dbtab . If the SELECT clause includes a "*", the command
is processed like the identical SELECT * INTO dbtab FROM dbtab
statement. If the SELECT clause contains a list a1 ...
an , the command is executed like SELECT a1 ... an INTO
CORRESPONDING FIELDS OF dbtab FROM dbtab .
If the result of the selection is meant to be a table, the data is
usually (for further information, see
INTO -Klausel ) read line by line within a
processing loop introduced by SELECT and concluded by
ENDSELECT . For each line read, the
processing passes through the loop once. If the result of the selection
is meant to be a single record, the closing ENDSELECT is
The FROM source clause the
source (database table or view )
from which the data is to be selected. It also determines
the type of client handling,
the behavior for buffered tables and
the maximum number of lines to be read.
The WHERE where clause specifies the
conditions which the result of the selection must satisfy. It thus
determines the lines of the result table. Normally - i.e. unless a
client field is specified in the WHERE clause - only data of the
current client is selected. If you want to select across other clients,
the FROM clause must include the addition ... CLIENT
The GROUP-BY fields clause
combines groups of lines together into single lines. A group is a set
of lines which contain the same value for every database field in the
GROUP BY clause.
The ORDER-BY order clause
stipulates how the lines of the result table are to be ordered.
Each time the SELECT statement is executed, the system field
SY-DBCNT contains the number of lines read so far. After
ENDSELECT , SY-DBCNT contains the total number of lines
The return code value is set as follows:
SY-SUBRC = 0
At least one line was read.
SY_SUBRC = 4
No lines were read.
SY-SUBRC = 8
The search key was not fully qualified.
(nur bei SELECT SINGLE ). The returned single record is any line
of the solution set.
Output the passenger list for the Lufthansa flight 0400
SELECT * FROM SBOOK
CARRID = 'LH ' AND
CONNID = '0400' AND
FLDATE = '19950228'
ORDER BY PRIMARY KEY.
WRITE: / SBOOK-BOOKID, SBOOK-CUSTOMID, SBOOK-CUSTTYPE,
SBOOK-SMOKER, SBOOK-LUGGWEIGHT, SBOOK-WUNIT,
In client/server environments, storing database tables in local
buffers (see SAP buffering ) can save
considerable amounts of time because the time required to make an
access via the network is much more than that needed to access a
locally buffered table.
A SELECT command on a table for which
SAP buffering is defined in the ABAP/4
Dictionary is normally satisfied from the SAP buffer by
bypassing the database. This does not apply with
- SELECT SINGLE FOR UPDATE
- SELECT DISTINCT in the SELECT clause
- BYPASSING BUFFER in the FROM clause
- ORDER BY f1 ... fn in the
ORDER-BY clause ,
- aggregate functions in the SELECT clause
- when using IS [NOT] NULL WHERE condition
or if the generic key part is not qualified in the
WHERE-Bedingung for a generically
Authorization checks are not supported
by the SELECT statement, so you must program these yourself.
In dialog systems, the database system locking mechanism
cannot always guarantee to synchronize the simultaneous
access of several users to the same dataset. In many cases, it is
therefore advisable to use the SAP locking mechanism
Changes to data in a database are only finalized after a database
commit (see LUW ). Prior to this, any
database update can be reversed by a database rollback (see
Programming transactions ). At the lowest
isolation level (see the section on the "uncommitted read" under
Locking mechanism ), this can result in the
dataset selected by the SELECT command not really being written
to the database. While a program is selecting data, a second program
can add, change or delete lines at the same time. Then, the changes
made by the second program are reversed by rolling back the database
system. The selection of the first program thus reflects only a very
temporary state of the database. If such "phantom data" is not
acceptable for a program, you must either use the
SAP locking mechanism or at least set the
isolation level of the database system to "committed read" (see
Locking mechanism ).
In a SELECT-ENDSELECT loop, the
CONTINUE statement terminates the current
loop pass prematurely and starts the next.
If one of the statements in a SELECT ... ENDSELECT loop
results in a database commit, the cursor belonging to the SELECT
... ENDSELECT loop is lost and the processing terminates with a
runtime error. Since each screen change automatically generates a
database commit, statements such as CALL SCREEN
, CALL DIALOG ,
CALL TRANSACTION or
MESSAGE are not allowed within a SELECT
... ENDSELECT loop.
OPEN CURSOR ,
FETCH und CLOSE
© SAP AG 1996