SELECT

Basic form

SELECT select clause [INTO clause] FROM from clause [WHERE cond1] [GROUP BY fields1] [HAVING cond2] [ORDER BY fields2].

In some cases, the syntax rules that apply to Unicode programs are different than those for non-Unicode programs. Siehe Open SQL and Unicode.

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Short Forms Not Allowed and * Work Areas Not Allowed.

Effect

Reads a selection and/or a summary of data from one or more database tables and/or views (see relational database). SELECT is an Open SQL statement.

Each SELECT statement consists of a series of clauses, each with a differen task:

The SELECT clause 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 INTO clause determines the target area into which the selected data is read. If the target area is an internal table, the INTO clause 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.
  

The data, if it exists in the database, is then made available using the table work area dbtab. The statement is then processed further like the SELECT * INTO dbtab FROM dbtab statement, which has the same effect.

If the result of the selection is a table, the data is normally read line by line (for further information, see INTO clause) in a processing loop, which is introduced with SELECT and concludes with ENDSELECT. The loop is processed once for each line that is read. If you want the result of the selection to be a single record, there is no concluding ENDSELECT statement.

The FROM clause FROM clause specifies the source of the data (database tables or views), from which you want to select the data. 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 cond1 specifies the conditions that the result of the selection must satisfy. By default, only data from the current client is selected (without you having to specify the client field specifically in the WHERE clause). If you want to select data from several clients, you must use the ... CLIENT SPECIFIED addition in the FROM clause.

The GROUP BY clause fields1 combines groups of lines into single lines 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 cond2 specifies conditions for the combined lines of the result table.

The ORDER BY clause 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 number of records read.

The Return Code 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 single line with the result 0 if there are no records in the database table that meet 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) can lead 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 locally-buffered table.

Notes

1. A SELECT statement on a table for which SAP buffering has been declared in the ABAP Dictionary usually reads data from the SAP buffer without accessing the database. This does not apply when you use:
   - JOIN in the FROM clause or subqueries in the WHERE clause, for example,
   - SELECT SINGLE FOR UPDATE or
   - 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 you use IS [NOT] NULL in the WHERE condition,
   or when the table has generic buffering and the appropriate section of the key is not specified in the WHERE condition.
   
   
   
2. The SELECT statement does not perform its own authorization checks. You should write your own at program level.
   
   
   
3. Proper synchronization of simultaneous access by several users to the same set of data cannot be assured by the database lock mechanism. In many cases, you will need to use the SAP locking mechanism.
   
   
   
4. Changes to data in the database are not made permanent until a database commit (see LUW) occurs. Up to this point, you can undo any changes using a databse rollback (see Programming Transactions). At the lowest isolation level (see lock mechanism ), the "Uncommitted Read", it can sometimes 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 adding data to, changing data in, or deleting data from the database at the same time. If the second program then executes a rollback, the first program has selected 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 or change the isolation level of the database system to at least "Committed Read" (see locking mechanism).
   
   
   
5. In a SELECT - ENDSELECT loop, the CONTINUE statement terminates the current loop pass and starts the next.
   
   
   
6. If a SELECT - ENDSELECT loop contains a statement that triggers a database commit, the cursor belonging to the loop is lost and a program termination and runtime error occur. Remote Function Calls and changes of screen always lead to a database commit. The following statements are consequently not allowed wihtin a SELECT-ENDSELECT loop: CALL FUNCTION ... STARTING NEW TASK , CALL FUNCTION ... DESTINATION , CALL FUNCTION ... IN BACKGROUND TASK, CALL SCREEN, CALL DIALOG, CALL TRANSACTION, and MESSAGE.
   
   
   
7. On some database systems (for example DB2/390)
   locking conflicts can be caused even by read access. You can prevent this problem from occurring using regular database commits.
   
   
   

Related

OPEN CURSOR, FETCH and CLOSECURSOR

Additional help

Reading Data