Syntax Diagram <SAPEVENT:>

SELECT
Basic form
SELECT select clause [INTO clause] FROM from clause [WHERE cond1] [GROUP BY fiel
ds1] [HAVING cond2] [ORDER BY fields2].
In some cases, the syntax rules that apply to Unicode programs <SAPEVENT:> are d
ifferent than those for non-Unicode programs. Siehe Open SQL and Unicode <SAPEVE
NT:>.
The syntax check performed in an ABAP Objects context is stricter than in other
ABAP areas. See Short Forms Not Allowed <SAPEVENT:> and * Work Areas Not Allowed
<SAPEVENT:>.
Effect
Reads a selection and/or a summary of data from one or more database tables <SAP
EVENT:> and/or views <SAPEVENT:> (see relational database <SAPEVENT:>). SELECT i
s an Open SQL <SAPEVENT:> statement.
Each SELECT statement consists of a series of clauses, each with a differen task
:
The SELECT clause <SAPEVENT:> select clause describes
Whether the result of the selection should be a single record or a table,
Which columns should be contained in the result,
Whether identical lines may occur in the result.

The INTO clause <SAPEVENT:> INTO clause determines the target area into which th
e selected data is read. If the target area is an internal table, the INTO claus
e specifies:
Whether you want to overwrite the contents of the internal table or
Append the results to the internal table, and
Whether you want to place the data in the internal table in a single step, or in
a series of packages.

The INTO clause can also occur after the FROM clause. You may omit it if
The SELECT clause contains a "*",
The FROM clause does not contain a JOIN, and
You have declared a table work area dbtab in your program using TABLES <SAPEVENT
:>.
The data, if it exists in the database, is then made available using the table w
ork area dbtab. The statement is then processed further like the SELECT * INTO d
btab FROM dbtab statement, which has the same effect.
If the result of the selection is a table, the data is normally read line by lin
e (for further information, see INTO clause <SAPEVENT:>) in a processing loop, w
hich is introduced with SELECT and concludes with ENDSELECT <SAPEVENT:>. The loo
p is processed once for each line that is read. If you want the result of the se
lection to be a single record, there is no concluding ENDSELECT statement.
The FROM clause <SAPEVENT:> FROM clause specifies the source of the data (databa
se tables <SAPEVENT:> or views <SAPEVENT:>), from which you want to select the d
ata. It also specifies the:
Client handling
Behavior for buffered tables
The maximum number of lines to be read
The database connection, on which the SELECT command is to be executed

The WHERE clause <SAPEVENT:> cond1 specifies the conditions that the result of t
he selection must satisfy. By default, only data from the current client is sele
cted (without you having to specify the client field specifically in the WHERE c
lause). If you want to select data from several clients, you must use the ... CL
IENT SPECIFIED addition in the FROM clause.
The GROUP BY clause <SAPEVENT:> fields1 combines groups of lines into single lin
es of the result table. A group is a set of records with the same value of each
database field listed in the GROUP BY clause.
The HAVING clause <SAPEVENT:> cond2 specifies conditions for the combined lines
of the result table.
The ORDER BY clause <SAPEVENT:> fields2 specifies how the records in the result
table should be arranged.
The system field SY-DBCNT contains the number of lines read so far ecah time the
SELECT statement is executed. After ENDSELECT, SY-DBCNT contains the total numb
er of records read.
The Return Code <SAPEVENT:> is set as follows:
SY-SUBRC = 0:
The result table contains at least one record.
SY-SUBRC = 4:
The result table is empty.
SY-SUBRC = 8:
Applies only to SELECT SINGLE FOR UPDATE: You did not specify all of the primary
key fields in the WHERE condition. The result table is empty.
Note
The SELECT COUNT( * ) FROM ... statement returns a result table containing a sin
gle line with the result 0 if there are no records in the database table that me
et the selection criteria. In an exception to the above rule, SY-SUBRC is set to
4 in this case, and SY-DBCNT to zero.
Example
Displaying the passenger list for Lufthansa flight 0400 on 2/28/1995:
DATA: WA_SBOOK TYPE SBOOK.
SELECT * FROM SBOOK INTO WA_SBOOK
WHERE
CARRID = 'LH ' AND
CONNID = '0400' AND
FLDATE = '19950228'
ORDER BY PRIMARY KEY.
WRITE: / WA_SBOOK-BOOKID, WA_SBOOK-CUSTOMID,
WA_SBOOK-CUSTTYPE, WA_SBOOK-SMOKER,
WA_SBOOK-LUGGWEIGHT, WA_SBOOK-WUNIT,
WA_SBOOK-INVOICE.
ENDSELECT.
Note
Performance:
Storing database tables in a local buffer (see SAP buffering <SAPEVENT:>) can le
ad to considerable time savings in a client/server environment, since the access
time across the network is considerably higher than that required to access a l
ocally-buffered table.
Notes
A SELECT statement on a table for which SAP buffering <SAPEVENT:> has been decla
red in the ABAP Dictionary usually reads data from the SAP buffer without access
ing the database. This does not apply when you use:
- JOIN <SAPEVENT:> in the FROM clause or subqueries <SAPEVENT:> in the WHERE cla
use, for example,
- SELECT SINGLE FOR UPDATE or
- SELECT DISTINCT in the SELECT clause <SAPEVENT:>,
- BYPASSING BUFFER in the FROM clause <SAPEVENT:>,
- ORDER BY f1 ... fn in the ORDER BY clause <SAPEVENT:>,
- Aggregate functions in the SELECT clause <SAPEVENT:>,
- When you use IS [NOT] NULL in the WHERE condition <SAPEVENT:>,
or when the table has generic buffering and the appropriate section of the key i
s not specified in the WHERE condition <SAPEVENT:>.

The SELECT statement does not perform its own authorization checks <SAPEVENT:>.
You should write your own at program level.

Proper synchronization of simultaneous access by several users to the same set o

f data cannot be assured by the database lock mechanism <SAPEVENT:>. In many cas
es, you will need to use the SAP locking mechanism <SAPEVENT:>.

Changes to data in the database are not made permanent until a database commit (
see LUW <SAPEVENT:>) occurs. Up to this point, you can undo any changes using a
databse rollback (see Programming Transactions <SAPEVENT:>). At the lowest isola
tion level (see lock mechanism <SAPEVENT:> ), the "Uncommitted Read", it can som
etimes be the case that data selected by a SELECT statement was never written to
the database. While a program is selecting data, a second program could be addi
ng data to, changing data in, or deleting data from the database at the same tim
e. If the second program then executes a rollback, the first program has selecte
d a set of data that may only represent a temporary state from the database. If
this kind of "phantom data" is unacceptable in the context of your application,
you must either use the SAP locking mechanism <SAPEVENT:> or change the isolatio
n level of the database system to at least "Committed Read" (see locking mechani
sm <SAPEVENT:>).

In a SELECT - ENDSELECT loop, the CONTINUE <SAPEVENT:> statement terminates the

current loop pass and starts the next.

If a SELECT - ENDSELECT loop contains a statement that triggers a database commi

t, the cursor belonging to the loop is lost and a program termination and runtim
e error occur. Remote Function Calls and changes of screen always lead to a data
base commit. The following statements are consequently not allowed wihtin a SELE
CT-ENDSELECT loop: CALL FUNCTION ... STARTING NEW TASK <SAPEVENT:>, CALL FUNCTI
ON ... DESTINATION <SAPEVENT:>, CALL FUNCTION ... IN BACKGROUND TASK <SAPEVENT
:>, CALL SCREEN <SAPEVENT:>, CALL DIALOG <SAPEVENT:>, CALL TRANSACTION <SAPEVENT
:>, and MESSAGE <SAPEVENT:>.

On some database systems (for example DB2/390)

locking conflicts <SAPEVENT:> can be caused even by read access. You can prevent
this problem from occurring using regular database commits.

Related
OPEN CURSOR <SAPEVENT:>, FETCH <SAPEVENT:> and CLOSECURSOR <SAPEVENT:>
Additional help
Reading Data <SAPEVENT:>