Open SQL

Table of Contents

Table of Contents 2

Overview 3
What is OpenSQL? 4

Client Handling 7

Operands and Expressions 8

Reads 9
■ SELECT 9
■ WITH 12
■ OPEN CURSOR 13
■ UNION 14

Write Accesses 15
Inserting Lines into Tables 16
Specifying a Database Table 16
Inserting a Single Line 17
Inserting Several Lines 18

Database Hints 19

Performance Notes 20

Exceptions 23

2
Overview

In ABAP, data in database tables can be accessed in the following ways:

■ Open SQL

Implemented by ABAP statements, this is a subset of the Structured

Query Language (SQL) comprising the DML (Data Manipulation

Language) part. The Open SQL statements use the Open SQL interface

for platform-independent access to those database tables in the

standard AS ABAP database defined in ABAP Dictionary and having

instances created in the ABAP database schema.

■ Native SQL

Database-specific SQL statements that include both DML and DDL

(Data Definition Language) statements and which can be passed to the

Native SQL interface of the database as follows:

● The methods of ADBC make it possible to execute dynamic SQL

statements on a database system and process the results. ADBC (ABAP

3
 Database Connectivity), a class-based API that enables object-oriented

access to the Native SQL interface.

● Native SQL statements can be specified in ABAP programs between the

statements EXEC SQL and ENDEXEC. Static Native SQL statements of

this kind are not checked completely by the syntax check and are

forwarded almost unchanged from the Native SQL interface to the

database of an AS ABAP.

■ The AMDP framework is used to manage and call ABAP Managed

Database Procedures. These are stored procedures or database

procedures implemented as AMDP procedures in an AMDP method of

an AMDP class and replicated to the database system from here.

Alongside access to the ABAP database schema of the standard AS ABAP

database, all access types (except for AMDP) also allow access to other

databases and other database schemas using additional database

connections.

Open SQL consists of a set of ABAP statements that perform operations on

the central database in the SAP Web AS ABAP. The results of the operations

and any error messages are independent of the database system in use.

Open SQL thus provides a uniform syntax and semantics for all of the

database systems supported by SAP. ABAP programs that only use Open SQL

statements will work in any SAP system, regardless of the database system in

4
use. Open SQL statements can only work with database tables that have

been created in the ABAP Dictionary.

In the ABAP Dictionary, you can combine columns of different database

tables to a database view (or view for short). In Open SQL statements, views

are handled in exactly the same way as database tables. Any references to

database tables in the following sections can equally apply to views.

What is OpenSQL?

Open SQL is a set of instructions for querying the database. Open SQL is the

equivalent of SQL, but simplified, which allows your program to be

compatible with all the databases that work with SAP.

Overview

Open SQL defines the subset of ABAP statements that enable direct access to
data from the standard database of the current AS ABAP. The Open SQL
statements form the DML part of SQL in ABAP, which is supported by all
database systems. The Open SQL statements are transformed to
database-specific SQL in the Open SQL interface of the database interface.
They are then passed to the database system and executed there. By default,
Open SQL statements use automatic client handling to access only the data
of the current client. To improve performance when accessing the database,
table buffering can be activated for individual database tables, views, or CDS
entities to avoid accessing the database directly each time.

5
Open SQL is closely integrated with ABAP Dictionary. In Open SQL
statements, only those database tables. views, and CDS entities can be
accessed that are defined in ABAP Dictionary. These items are specified
directly in Open SQL statements without specifying a database schema. By
default, the Open SQL interface of the database interface accesses the
associated database objects in the ABAP database schema of the standard
database.

The Open SQL interface of the database interface respects the fact the order
of the columns in the data source in the database system can differ from the
order in the definition of the data source in ABAP Dictionary. If Open SQL is
used, the order in ABAP Dictionary applies and the database interface
performs a transformation if necessary. The function SQL Trace of the
Performance Trace tool (transaction ST05) can be used to analyze the SQL
statements actually passed to the database by the database interface.

Open SQL contains the following keywords:

6
Return Codes

All Open SQL statements fill the following two system fields with return

codes:

● sy-subrc

After every Open SQL statement, the system field sy-subrc contains the

value 0 if the operation was successful, a value other than 0 if not.

● sy-dbcnt

After an open SQL statement, the system field sy-dbcnt contains the

number of database lines processed.

7
Client Handling

A single SAP system can manage the application data for several separate

areas of a business (for example, branches). Each of these commercially

separate areas in the SAP system is called a client, and has a number. When

a user logs onto the SAP Web AS ABAP, they specify a client. The first column

in the structure of every database table containing application data is the

client field (MANDT, from the German word for client). It is also the first field

of the table key. Only universal system tables are client-independent, and do

not contain a client name.

By default, Open SQL statements use automatic client handling. Statements

that access client-dependent application tables only use the data from the

current client. You cannot specify a condition for the client field in the WHERE

clause of an Open SQL statement. If you do so, the system will either return

an error during the syntax check or a runtime error will occur. You cannot

overwrite the MANDT field of a database using Open SQL statements. If you

specify a different client in a work area, the ABAP runtime environment

automatically overwrites it with the current one before processing the Open

SQL statement further.

Should you need to specify the client specifically in an Open SQL statement,

use the addition

... CLIENT SPECIFIED ....

8
directly after the name of the database table. This addition disables the

automatic client handling and you can use the field MANDT both in the

WHERE clause and in a table work area.

■ When client-specific database tables or classic views are accessed, the

conditions that are passed from Open SQL to the database contain an

implicit condition for the current client in the client column.

■ In work areas that are used as data sources in write statements, clients

here are ignored and the current client is used implicitly.

■ The addition USING CLIENT can be used to switch client handling to a

different client.

■ For information about accessing client-specific CDS entities, see the

following descriptions:

● Client Handling in CDS Views

● Client Handling in CDS Table Functions

When accessing client-specific data sources, table columns cannot be

specified explicitly in conditions.

Automatic client handling can be switched off using the addition CLIENT

SPECIFIED. If client handling is switched off:

■ The client column can be specified in conditions.

■ In work areas that are used as data sources in write statements, the

specified clients are taken into account.

9
Operands and Expressions

In Open SQL statements, the following objects can be specified as operands

alongside data sources (database tables, classic views, and CDS entities) and

the following expressions can be used:

■ Elements of data sources

➢ Open SQL - Specified columns: for more details see Specified

Columns

➢ Open SQL - Specified paths: for more details see Path

expressions

■ ABAP objects

➢ Open SQL - Host variables: for more details see Host variables

➢ Open SQL - Host expressions: for more details see Host

expressions

■ Expressions and functions

➢ Open SQL - Aggregate expressions: for more details see

Aggregate Expressions

➢ Open SQL - SQL expressions: for more details see SQL

expressions

➢ Open SQL - Built-in functions: for more details see Built-in

functions

■ WHERE conditions and ON conditions

➢ Open SQL - Conditions: for more details see Conditions

10
 ■ Parameter passing to CDS entities

➢ Open SQL - Parameter passing: for more details see Parameter

passing

Reads

The Open SQL language elements for performing reads on the database are:

■ SELECT

The Open SQL statement for reading data from database tables is:

SELECT result INTO target FROM source [WHERE condition] [GROUP

BY fields] [HAVING cond] [ORDER BY fields].

The SELECT statement is divided into a series of simple clauses, each of

which has a different part to play in selecting, placing, and arranging the data

from the database.

11
12
The individual clauses and the ways in which they combine are all very

important factors in the SELECT statement. Although it is a single statement

like any other, beginning with the SELECT keyword and ending with a period,

its division into clauses, and the ways in which they combine, make it more

powerful than other statements. A single SELECT statement can perform

functions ranging from simply reading a single line to executing a very

complicated database query.

You can use SELECT statements in the WHERE and HAVINGclauses. These are

called subqueries .

You can decouple the INTO clause from the SELECT statement by reading

from the database using a cursor .

On certain database systems, this can result in lock conflicts , even with pure

read access; these can be prevented by using database commits.

13
 ■ WITH

The Open SQL keyword WITH introduces the definition of common table
expressions (CTE for short) to be used in a final main query. WITH can be
used as a standalone statement (as shown here) or after the statement
OPEN CURSOR.

Each common table expression creates a tabular results set in a subquery,

which can be used in the subsequent queries of the WITH statement as data
source data_source. The WITH statement consists of the following parts:

■ A comma-separated list with at least one definition of a common table

expression
● Each common table expression has a unique name +cte1, +cte2, ... .
The names cte can have a maximum of 30 characters, and can contain
letters, numbers, and underscores. They must start with either a letter
or an underscore. Also, the name must be prefixed with the character
+. The initial + character is part of the name, but cannot stand alone
and must not be followed by a number.
● An optional name list ( name1, name2, ... ) for the columns of the
results set of the common table expression can be specified directly
after the name (see below).
● A parenthesized subquery SELECT subquery_clauses follows the AS.
This subquery creates the tabular results set of the common table
expression. The language element UNION can be used to combine the
results sets of multiple subqueries. In this case, special rules
query_clauses apply for specifying clauses.

14
 ■ A closing main query SELECT mainquery_clauses, which can contain
the same clauses and additions (apart from FOR ALL ENTRIES) as a
standalone SELECT statement, and works in the same way:
● The results set of the main query is assigned to ABAP data objects
according to the INTO clause.
● As described in SELECT, a single- or multirow results set is created and,
depending on the target area specified in the INTO clause, a SELECT
loop is either opened or not.
● A SELECT loop must close with the ENDWITH statement. For WITH ...
SELECT, ENDWITH has exactly the same meaning as ENDSELECT for a
standalone SELECT loop.
● In the main query, each of the previously defined common table
expressions +cte1, +cte2, and so on, can be used as the data source
data_source.

The language element UNION can be used to combine the results sets of
multiple main queries. In this case, additional rules query_clauses apply for
specifying clauses.

A common table expression defined in the WITH statement can be used after
its definition in the subquery of another common table expression and in the
main query as the data source data_source. It cannot be used in its own
subquery or in the subqueries of preceding definitions. A common table
expression is only known within the current WITH statement.

Each common table expression defined in a WITH statement must be used at

least once within the WITH statement, either in another common table
expression or in the main query. This means that the main query must
access at least one common table expression.

15
The name +cte of a common table expression is valid across the full WITH
statement. The character + is omitted from the name of the substructure
only when a substructure is created as a data source for a common table
expression in the INTO clause.

The results set of a common table expression never has a client column.
Even if the client column of a client-specific data source is added explicitly in
the subquery to its SELECT list, it does not behave as such in the results set.
For this reason, in a query of the WITH statement that uses a common table
expression as a data source, the addition CLIENT SPECIFIED cannot be
specified.

■ OPEN CURSOR

➢ FETCH NEXT CURSOR

➢ CLOSE CURSOR

Effect

The Open SQL statement OPEN CURSOR opens a database cursor for the
result set of the main query defined after FOR and links a cursor variable
dbcur with this database cursor. The results set of the main query can be
read with the statement FETCH.

The main query is specified after FOR as follows:

■ The main query is specified using language element SELECT, and its
clauses and additions mainquery_clauses define the result set.

■ The language element UNION can be used to combine the result sets
of multiple queries. In this case, special rules query_clauses apply for

16
 specifying clauses.

■ Finally, the optional additions UP TO, OFFSET, and abap_options can

be specified.

■ Optional common table expressions can be defined in the main query

by using the language element WITH. When defining and using
common table expressions, the same applies as when using WITH to
introduce a standalone statement.

The following can be specified for the cursor:

■ A host variable dbcur declared using a specific predefined data type:

cursor. The name of this host variable must be prefixed with the
escape character @. A database cursor dbcur that has already been
opened cannot be opened again.

■ An inline declaration of a corresponding host variable dbcur. The

declaration operator DATA must be prefixed with the escape character
@.

A line of the result set is always assigned to an opened database cursor as a

cursor position. After the statement OPEN CURSOR, the database cursor is
positioned in front of the first line of the results set.

In a single program, a maximum of 17 database cursors can be open

simultaneously across the Open SQL interface. If more than 17 database
cursors are opened, the runtime error DBSQL_TOO_MANY_OPEN_CURSOR
occurs. An open database cursor can be closed using the statement CLOSE
CURSOR. Here, any open database cursors are closed by database commits

17
or database rollbacks, if these occur after the first use of the cursor in a
FETCH statement.

If a cursor variable dbcur of an open database cursor is assigned to another

cursor variable or passed as a parameter, the latter is associated with the
same database cursor at the same position. A cursor variable of an open
database cursor can also be passed to procedures that have been called
externally, to enable the database cursor to be accessed from there.

■ UNION

Effect

The Open SQL language element UNION joins the result sets of two queries.
The rows of the result set of the query after UNION are inserted into the
result set of the query before UNION. The syntax forms show where UNION
can be used:

1. For creating the result set of the main query of a standalone statement,
which is introduced using WITH or SELECT.

2. For creating the result set of the main query after OPEN CURSOR.

3. For creating the results set of a parenthesized subquery in an SQL

condition, of the definition of a common table expression after WITH,
or of an INSERT statement.

In all syntax forms, it is possible to specify the same clauses and additions
query_clauses for SELECT statements of queries before and after UNION for

18
defining result sets. A query on the right side of UNION can be enclosed in
parentheses ( ). A pair of parentheses can include multiple unions. The
queries joined with UNION are evaluated from left to right. Specific
statements can be prioritized using parentheses.

In the case of a standalone SELECT or WITH statement and after OPEN

CURSOR, the ORDER BY and the abap_options after the last query or after
the position of the last closing bracket are listed and affect the union result
set. In the case of standalone statements, the INTO clause is to be listed as
the last clause and before the additions abap_options. The following special
features apply here:

■ ORDER BY clause
● The addition ORDER BY PRIMARY KEY is not allowed.
● Columns of the union results set specified after ORDER BY must occur
with the same name in all relevant SELECT statements. The names
must be specified directly and cannot be specified with the column
selector ~ after a column name.
■ INTO clause
● If the addition CORRESPONDING or an inline declaration @DATA(...) is
used in the INTO clause, the column names of all results sets defined
in the query_clauses from left to right must match.
● The union result set is always multirow. If an assignment is made to a
non-table-like target are (meaning a SELECT statement without the
addition INTO|APPENDING ... TABLE), a loop closed using ENDSELECT
or ENDWITH is always opened.
■ Restricting the Results Set

19
 ● The additions UP TO and OFFSET are not currently allowed with
UNION.

Write Accesses

Writes include inserting, modifying, and deleting content in database tables.

All writes can be made as individual accesses or as mass access. If multiple

rows of a database table are to be changed, mass access using internal

tables generally gives better performance than individual accesses.

■ INSERT

■ UPDATE

■ MODIFY

■ DELETE

Open SQL contains a set of statements that allow you to change data in the

database. You can insert, change and delete entries in database tables.

However, you must remember that Open SQL statements do not check

authorization or the consistency of data in the database. The following

statements are purely technical means of programming database updates.

They are to be used with care, and, outside the SAP transaction concept ,

only to be used in exceptional cases. The SAP transaction concept addresses

the question of database update programming in the SAP System. It

discusses the difference between a database LUW and an SAP LUW, and

explains about SAP transactions and the SAP locking concept.

20
Inserting Lines into Tables

The Open SQL statement for inserting data into a database table is:

INSERT INTO target lines.

It allows you to insert one or more lines into the database table target. You

may specify the database table targeteither statically or dynamically.

Specifying a Database Table

To specify the database table statically, enter the following for target:

INSERT INTO dbtab [CLIENT SPECIFIED] lines.

where dbtab is the name of a database table defined in the ABAP Dictionary.

To specify the database table dynamically, enter the following for target:

INSERT INTO (name) [CLIENT SPECIFIED] lines.

where the field name contains the name of a database table defined in the

ABAP Dictionary.

You can use the CLIENT SPECIFIED addition to disable automatic client

handling.

21
Inserting a Single Line

To insert a single line into a database table, use the following:

INSERT INTO target VALUES wa.

The contents of the work area wa are written to the database table dbtab. It

is a good idea to define the work area with reference to the structure of the

database table.

You can also insert single lines using the following shortened form of the

INSERT statement:

INSERT target FROM wa.

Using FROM instead of VALUE allows you to omit the INTOclause. Shorter still

is:

INSERT dbtab.

In this case, the contents of the table work area dbtabare inserted into the

database table with the same name. You must declare this table work area

using the TABLES statement. In this case, it is not possible to specify the

name of the database table dynamically. Table work areas with the same

name as the database table (necessary before Release 4.0) should no longer

be used for the sake of clarity.

22
Inserting Several Lines

To insert several lines into a database table, use the following:

INSERT target FROM TABLE itab [ACCEPTING DUPLICATE KEYS].

This writes all lines of the internal table itabto the database table in one

single operation. If one or more lines cannot be inserted because the

database already contains a line with the same primary key, a runtime error

occurs. You can prevent the runtime error occurring by using the addition

ACCEPTING DUPLICATE KEYS.

Whenever you want to insert more than one line into a database table, it is

more efficient to work with an internal table than to insert the lines one by

one.

Notes

■ When making writes, always pay attention to data consistency. The

LUW concept is designed for this purpose. In application programs of

an AS ABAP, the implicit database LUWs are normally not sufficient for

consistent data storage. Instead, explicit SAP LUWs need to be

programmed, which normally contain multiple database LUWs.

■ When making writes to a database table for which a database cursor is

open in a SELECT loop or opened by using OPEN CURSOR, the results

23
 set is database-specific and undefined. Avoid this kind of parallel

access if possible.

■ Write access to tables or classic views with replacement objects is still

performed on the database table or the classic view and lead to a

syntax warning.

■ Once a global temporary table is filled using Open SQL, this table must

be emptied again explicitly before the next implicit database commit

using the Open SQL statement DELETE FROM without WHERE or using

an explicit database commit or database rollback. If not, the runtime

error COMMIT_GTT_ERROR is produced.

Database Hints

Syntax

... %_HINTS db @dbhint1

[db @dbhint2

... ] ...

Effect

The addition %_HINTS can be used to specify database hints at the following

positions in Open SQL statements:

■ After the clauses of SELECT statements in main and subqueries.

■ After the WHERE condition of the statements UPDATE and DELETE.

24
One or more database hints can be specified after %_HINTS as a

blank-separated list in flat, character-like data objects dbhint1, dbhint2, ... .

The name of host variables should be prefixed with the escape character @.

The addition db must be used before each database hint to specify the

database system for which the hint is intended. The following table shows

the possible additions and the corresponding database system:

A database system can be specified more than once if there are several

database hints for this system. The possible database hints are

database-specific and may depend on the release of the database system.

They can be found in the documentation of the respective database system.

An empty hint is ignored.

Performance Notes

The performance of a program is often determined by the efficiency of its

database reads. In a client/server environment, each database read places a

load on both the database system and the connection between the database

25
system and the application server. This load must be kept as low as possible

if programs are to demonstrate a good level of performance.

Generally speaking, the following rules must be followed. The overall

performance of a program is related to the data being edited, any

evaluations required, and the database system itself, which means that a

different combination of rules and priorities can apply from case to case.

■ Keep the number of hits low

The set of rows selected should be kept as small as possible by using specific

conditions to restrict the set to those rows actually needed. Superfluous rows

should never be transported from the database system to the application

server and then evaluated there.

■ Keep the data volume low

The volume of data transported should always be restricted to the columns

required. The columns can be specified explicitly or an appropriate view can

be used. Furthermore, aggregate expressions can be combined with

appropriately grouped data or SQL expressions to reduce the volume of

data, since here the data is aggregated before the transport in the database

system.

■ Keep the number of reads low

To keep the number of database reads low, mass operations should always

be used instead of single operations. More specifically, Open SQL statements

26
should not be used within loops. Instead, joins, views, or subqueries can be

used when reading multiple database tables.

■ Use local buffers

The same data should be not be read more than once. Saving database

tables to the local buffer in table buffering (and also saving prepared data in

Shared Objects) can produce significant time savings, since it takes much

longer for the application server to read the database system than a locally

buffered table. Database tables should always be buffered if they are read

frequently and modified rarely. If the same data is to be sorted multiple

times in different orders, the data should be sorted in the ABAP program.

■ Efficient search using indexes

In all cases where secondary indexes of database tables improve selection

performance, these indexes should be created and used.

Bad Example

This example uses a SELECT statement in a SELECT loop to add values from a

different database table to the work area here. An internal table is filled with

the work area, row by row.

SELECT carrid, CAST( ' ' AS CHAR( 20 ) ) AS carrname,

connid, cityfrom, cityto

FROM spfli

27
 ORDER BY carrid, connid, cityfrom, cityto

INTO @DATA(wa).

SELECT SINGLE carrname

FROM scarr

WHERE carrid = @wa-carrid

INTO (@wa-carrname).

DATA itab LIKE TABLE OF wa WITH EMPTY KEY.

itab = VALUE #( BASE itab ( wa ) ).

ENDSELECT.

Good Example

This example uses a join expression to fill an internal table directly. The result

is the same as in the previous example. The program

DEMO_OPEN_SQL_PERFO compares the runtimes of both access methods.

The "good" example is generally far quicker than the "bad" example.

SELECT p~carrid, c~carrname, p~connid, p~cityfrom, p~cityto

FROM spfli AS p

LEFT OUTER JOIN scarr AS c

ON p~carrid = c~carrid

28
 ORDER BY p~carrid, p~connid, p~cityfrom, p~cityto

INTO TABLE @DATA(itab).

Exceptions

Handleable Exceptions

CX_SY_OPEN_SQL_DB

■ Cause: A general database error occurred.

Runtime error: DBIF_RSQL_SQL_ERROR

■ Cause: Error in module RSQL of the database interface.

Runtime error: DBIF_RSQL_INVALID_RSQL

■ Cause: No data found for the specified key.

Runtime error: DBIF_RSQL_KEY_NOT_FOUND

■ Cause: Unexpected end of data when accessing a table.

Runtime error: DBIF_RSQL_END_OF_DATA

■ Cause: The key for a table was not completely specified.

Runtime error: DBIF_RSQL_KEY_NOT_SPECIFIED

29
 ■ Cause: An invalid database cursor was used.

Runtime error: DBIF_RSQL_INVALID_CURSOR

■ Cause: An attempt was made to access a closed database cursor.

Runtime error: SAPSQL_SQLS_INVALID_CURSOR

CX_SY_DYNAMIC_OSQL_ERROR

■ CX_SY_DYNAMIC_OSQL_SEMANTICS

● Cause: The database column whose values are to be aggregated does

not have a numeric type.

Runtime error: SAPSQL_HAVING_AVG_TYPE

● Cause: The database column whose values are to be aggregated does

not have a numeric type.

Runtime error: SAPSQL_HAVING_SUM_TYPE

● Cause: Search pattern not specified in a character literal.

Runtime error: SAPSQL_LIKE_VAL_TYPE

● Cause: A token cannot be interpreted as a literal or in the current

context of valid variable names.

Runtime error: SAPSQL_WHERE_ILLEGAL_VALUE and

SAPSQL_SET_ILLEGAL_VALUE

● Cause: A table name is too long.

Runtime error: SAPSQL_TABNAME_TOO_LONG

● Runtime error: A field name is too long.

Runtime error: SAPSQL_FIELDNAME_TOO_LONG

30
 ● Cause: No table exists with the specified name.

Runtime error: SAPSQL_INVALID_TABLENAME

● Cause: A field name is ambiguous.

Runtime error: SAPSQL_AMBIGUOUS_FIELDNAME

● Cause: No column exists with the specified name.

Runtime error: SAPSQL_INVALID_FIELDNAME

● Cause: The specified table is not declared as a table or view in ABAP

Dictionary.

Runtime error: SAPSQL_NO_DBTAB_OR_VIEW

● Cause: An attempt was made to select the sum of a non-numeric field.

Runtime error: SAPSQL_FIELDLIST_SUM_TYPE

● Cause: An attempt was made to select the average of a non-numeric

field.

Runtime error: SAPSQL_FIELDLIST_AVG_TYPE

● Cause: An attempt was made to create an aggregate function using a

LOB column.

Runtime error: SAPSQL_AGGREGATE_LOB

● Cause: An attempt was made to sort the values of a LOB column.

Runtime error: SAPSQL_ORDER_BY_LOB

● Cause: An attempt was made to use the addition DISTINCT on a LOB

column.

Runtime error: SAPSQL_DISTINCT_AND_LOB

● Cause: An alias is too long.

Runtime error: SAPSQL_ALIASNAME_TOO_LONG

31
 ● Cause: An attempt was made to sort the values of a LOB column.

Runtime error: SAPSQL_GROUP_BY_LOB

● Cause: An attempt was made to use a LOB column in a logical

expression.

Runtime error: SAPSQL_BOUND_LONG_STRING

● Cause: A pattern specified with LIKE is too long.

Runtime error: SAPSQL_LIKE_PATTERN_TOO_LONG and

SAPSQL_LIKE_PATTERN_TOO_LONG

● Cause: An attempt was made to select from a non-transparent table

using the addition DISTINCT.

Runtime error: SAPSQL_ILLEGAL_DISTINCT

● Cause: A field, whose value is to be changed with + or -, has a

non-numeric type

Runtime error: SAPSQL_SET_PLUS_MINUS_TYPE

● Cause: LIKE is used with the addition ESCAPE on a pooled table.

Runtime error: SAPSQL_ESCAPE_WITH_POOLTABLE

● Cause: A pooled table or cluster table is to be read using a secondary

database connection.

Runtime error: SAPSQL_CONNECTION_ILL_TABTYPE

■ CX_SY_DYNAMIC_OSQL_SYNTAX

● Cause: An error occurred while parsing a dynamic entry.

Runtime error: SAPSQL_PARSE_ERROR

32
 ● Cause: The keyword AND is missing after the lower comparison value

of BETWEEN.

Runtime error: SAPSQL_BETWEEN_MISSING_AND

● Cause: The logical expression has incorrect parentheses.

Runtime error: SAPSQL_HAVING_PARENTHESES

● Cause: An unknown aggregate function was found.

Runtime error: SAPSQL_ILLEGAL_AGGREGATE

● Cause: The operator IS NULL is not followed by the keyword NULL.

Runtime error: SAPSQL_ILLEGAL_IS_NULL

● Cause: The operator IN has incorrect parentheses.

Runtime error: SAPSQL_IN_ILLEGAL_LIST

● Cause: The logical expression contains a text field literal that does not

have a closing quotation mark.

Runtime error: SAPSQL_LIKE_QUOTES

● Cause: The logical expression ends unexpectedly.

Runtime error: SAPSQL_MISSING_LOG_CONDITION

● Cause: The Escape character is missing after the addition ESCAPE.

Runtime error: SAPSQL_WHERE_MISSING_ESCAPE

● Cause: An operator is missing in the logical expression.

Runtime error: SAPSQL_WHERE_MISSING_OPERATOR

● Cause: A literal or name of an ABAP variable is missing in the logical

expression.

Runtime error: SAPSQL_WHERE_MISSING_VALUE

33
 ● Cause: The logical expression has incorrect parentheses.

Runtime error: SAPSQL_WHERE_PARENTHESES

● Cause: The logical expression contains a text field literal that does not

have a closing quotation mark.

Runtime error: SAPSQL_WHERE_QUOTES

● Cause: An unknown operator is used in the logical expression.

Runtime error: SAPSQL_WHERE_UNKNOWN_OPERATOR

● Cause: An alias is missing.

Runtime error: SAPSQL_MISSING_ALIAS

● Cause: A column from the right side of a LEFT OUTER JOIN is used in a

WHERE condition.

Runtime error: SAPSQL_ACCESS_TO_RHS_TABLE

● Cause: Syntax error when the addition CREATING was specified

dynamically.

Runtime error: SAPSQL_NO_LOB_COLUMN

Runtime error: SAPSQL_FOR_ALL_COLUMNS

Runtime error: SAPSQL_TWICE_DEFINITION

Runtime error: SAPSQL_UNION_POSSIBLE

Runtime error: SAPSQL_MISSING_FOR_COLUMNS

Runtime error: SAPSQL_OTHER_ONLY_AT_THE_END

The following exceptions can only occur when using the statement UPDATE:

34
 ■ Cause: An attempt was made to change a database field using an

operator other than + or -.

Runtime error: SAPSQL_SET_NOT_PLUS_MINUS

■ Cause: An unknown operator was used in the statement SET.

Runtime error: SAPSQL_SET_UNKNOWN_OPERATOR

■ Cause: A literal or name of an ABAP variable is missing in the statement

SET.

Runtime error: SAPSQL_SET_MISSING_VALUE

■ Cause: The statement SET contains a text field literal, for which there is

no closing quotation mark..

Runtime error: SAPSQL_SET_QUOTES

CX_SY_SQL_UNSUPPORTED_FEATURE

■ Cause: A database feature is used that is not supported by the current

database system.

Runtime error: SAPSQL_UNSUPPORTED_FEATURE

Non-Handleable Exceptions

35
 ■ Cause: Invalid call of the database interface.

Runtime error: DBIF_RSQL_INVALID_REQUEST

■ Cause: Insufficient memory is available for the statement.

Runtime error: DBIF_RSQL_NO_MEMORY

■ Cause: Data area passed is too short for access to the table.

Runtime error: DBIF_RSQL_BUFFER_TOO_SHORT

■ Cause: The structure of a table is inconsistent with the dictionary.

Runtime error: DBIF_RSQL_DDIC_INCONSISTENT

■ Cause: The sort order specified for a table is not possible.

Runtime error: DBIF_RSQL_SORT_ORDER

■ Cause: Error when accessing the buffer of a table.

Runtime error: DBIF_RSQL_BUFFER_ERROR

■ Cause: A table is not known or does not exist.

Runtime error: DBIF_RSQL_TABLE_UNKNOWN

■ Cause: Internal error when accessing a table.

Runtime error: DBIF_RSQL_INTERNAL_ERROR

36
 ■ Cause: Unexpected return code when accessing a table.

Runtime error: DBIF_RSQL_UNEXPECTED_CODE

37