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
