Académique Documents
Professionnel Documents
Culture Documents
The FROM clause determines the database tables from which the data specified in the SELECT clause is read. You can specify either a single table or more than one table, linked using inner or outer joins. The names of database tables may be specified statically or dynamically, and you can use alias names. You can also use the FROM clause to bypass the SAP buffer and restrict the number of lines to be read from the database.
"Database table" can equally mean an ABAP Dictionary view. A view links two or more database tables in the ABAP Dictionary, providing a static join that is available systemwide. You can specify the name of a view wherever the name of a database table may occur in the FROM clause. The FROM clause has two parts - one for specifying database tables, and one for other additions: SELECT... FROM <tables> <options>... In <tables>, you specify the names of database tables and define joins. <options> allows you to specify further additions that control the database access.
The database table <dbtab> must exist in the ABAP Dictionary. The AS addition allows you to specify an alternative name <alias> that you can then use in the SELECT; FROM, WHERE, and GROUP BY clauses. This can eliminate ambiguity when you use more than one database table, especially when you use a single database table more than once in a join. Once you have defined an alias, you may no longer use the real name of the database table
The syntax of the <cond> condition is like that of the WHERE clause, although individual comparisons can only be linked using AND. Furthermore, each comparison must contain a column from the right-hand table <dbtab>. It does not matter on which side of the comparison it occurs. For the column names in the comparison, you can use the same names that occur in the SELECT clause, to differentiate columns from different database tables that have the same names. The comparisons in the condition <cond> can appear in the WHERE clause instead of the ON clause, since both clauses are applied equally to the temporary table containing all of the lines resulting from the join. However, each join must contain at least one comparison in the condition <cond>.
In the left outer join, more restrictions apply to the condition <cond> than in the inner join. In addition to the above restrictions: EQ or = is the only permitted relational operator. There must be at least one comparison between columns from <tab> and <dbtab>. The WHERE clause may not contain any comparisons with columns from <dbtab>. All comparisons using columns from <dbtab> must appear in the condition <cond>.
Client Handling
As already mentioned, you can switch off the automatic client handling in Open SQL statements using a special addition. In the SELECT statement, the addition comes after the options in the FROM clause: SELECT... FROM <tables> CLIENT SPECIFIED. .. If you use this addition, you can then address the client fields in the individual clauses of the SELECT statement.
Examples
SELECT * INTO wa FROM scarr UP TO 4 ROWS. WRITE: / wa-carrid, wa-carrname. ENDSELECT. The output is:
The system reads four lines from the database table SCARR.
Specifying a database table dynamically: REPORT demo_select_dynamic_database. DATA wa TYPE scarr. DATA name(10) TYPE c VALUE 'SCARR'. SELECT INTO FROM WHERE * wa (name) CLIENT SPECIFIED mandt = '000'.
WRITE: / wa-carrid, wa-carrname. ENDSELECT. A condition for the MANDT field is allowed, since the example uses the CLIENT SPECIFIED option. If NAME had contained the value scarr instead of SCARR, a runtime error would have occurred.
Inner join: REPORT demo_select_inner_join. DATA: BEGIN OF carrid connid fldate wa, TYPE spfli-carrid, TYPE spfli-connid, TYPE sflight-fldate,
bookid TYPE sbook-bookid, END OF wa, itab LIKE SORTED TABLE OF wa WITH UNIQUE KEY carrid connid fldate bookid. SELECT INTO FROM p~carrid p~connid f~fldate b~bookid CORRESPONDING FIELDS OF TABLE itab ( ( spfli AS p INNER JOIN sflight AS f ON p~carrid p~connid INNER JOIN sbook AS b ON b~carrid b~connid b~fldate WHERE p~cityfrom = 'FRANKFURT' AND p~cityto = 'NEW YORK' AND f~seatsmax > f~seatsocc.
= = = = =
LOOP AT itab INTO wa. AT NEW fldate. WRITE: / wa-carrid, wa-connid, wa-fldate. ENDAT. WRITE / wa-bookid. ENDLOOP. This example links the columns CARRID, CONNID, FLDATE, and BOOKID of the table SPFLI, SFLIGHT, and SBOOK, and creates a list of booking numbers for all flights from Frankfurt to New York that are not fully booked. An alias name is assigned to each table.
Left outer join: REPORT demo_select_left_outer_join. DATA: BEGIN OF wa, carrid TYPE scarr-carrid, carrname TYPE scarr-carrname, connid TYPE spfli-connid, END OF wa, itab LIKE SORTED TABLE OF wa WITH NON-UNIQUE KEY carrid. SELECT s~carrid s~carrname p~connid INTO CORRESPONDING FIELDS OF TABLE itab FROM scarr AS s LEFT OUTER JOIN spfli AS p ON s~carrid = p~carrid AND p~cityfrom = 'FRANKFURT'. LOOP AT itab INTO wa. WRITE: / wa-carrid, wa-carrname, wa-connid. ENDLOOP. The output might look like this:
The example links the columns CARRID, CARRNAME, and CONNID of the tables SCARR and SPFLI using the condition in the left outer join that the airline must fly from Frankfurt. All other airlines have a null value in the CONNID column in the selection. If the left outer join is replaced with an inner join, the list looks like this:
Only lines that fulfill the ON condition are included in the selection.