Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 

ABAP Query

Former Member
0 Kudos

Hi Experts,

What is meant by ABAP Query and which occasion we should prefer this.

Anybody have Step by step approach of ABAP Query.

For every Useful Inputs higher points will be rewarded.

Thanks in Advance,



Former Member
0 Kudos



Basic form

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

In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Short Forms Not Allowed and * Work Areas Not Allowed.


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, and

The maximum number of lines that you want to read.

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:


The result table contains at least one record.


The result table is empty.


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.


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.


Displaying the passenger list for Lufthansa flight 0400 on 2/28/1995:





CONNID = '0400' AND

FLDATE = '19950228'









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.


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:



- 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.

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

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.

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).

In a SELECT - ENDSELECT loop, the CONTINUE statement terminates the current loop pass and starts the next.

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.

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.

Also check....

0 Kudos

Hi Ramesh,

Thanks for the input.

But iam not asking about SQL query i have asked about ABAP Query.

Can u please give me an idea about that.

Thanks in Advance,


0 Kudos

Please refer to

Please only open one thread per question in the correct forum.


Rich Heilman