Skip to content

ABAP Keyword Documentation →  ABAP - Release-Specific Changes →  Changes in Releases 7.5x →  Changes in Release 7.53 

ABAP SQL in Release 7.53


1. Open SQL renamed as ABAP SQL

2. Access to hierarchy data


3. Secondary connections


4. Relational expression IS INITIAL


5. Date/time functions


6. Publishing associations of common table expressions


7. Numeric literals in the SELECT list


8. Enhanced cast matrix


9. Client handling in subquery of the statement INSERT


10. Subquery as data source of MODIFY


11. USING CLIENT and session variable client


12. Null values in the table buffer


13. Restrictions removed


14. Weaker check


15. New check


16. Replacement service in program calls


17. GROUP BY addition GROUPING SETS


18. Aggregate function GROUPING


19. Stricter checks for syntax rules

Other versions: 7.31 | 7.40 | 7.54

Modification 1

Open SQL Renamed as ABAP SQL

The existing name Open SQL has been changed to ABAP SQL. This renaming reflects that some parts of ABAP SQL now only support certain database platforms, specifically SAP HANA database, and hence that it is no longer fully platform-independent.

Modification 2

Access to Hierarchy Data

In queries, both

can be specified as data sources. Accessing hierarchy data triggers the strict mode from Release 7.53.

Modification 3

Secondary Connections

On an AS ABAP with a SAP HANA database as its standard database, only those secondary connections should be used from the database table DBCON whose secondary database is also a SAP HANA database. Alongside the CONNECTION addition in , this also applies to ABAP SQL and Native SQL (ADBC and EXEC SQL).

SAP HANA Smart Data Access (SDA) should be used instead. In SDA, secondary databases are addressed from the SAP HANA database using special qualified names or by using virtual tables. If a SAP HANA database is used as a standard AS ABAP database, ABAP programs can use these names across the standard connection. This is only possible in AMDP and Native SQL. Database Shared Libraries (DBSL) are no longer required here.

Modification 4

Relational Expression IS INITIAL

The relational expression IS [NOT] INITIAL can now be used in a condition sql_cond to compare operands with their type-dependent initial value.

When used, this expression requires the strict mode from Release 7.53.

Modification 5

Date/Time Functions

ABAP SQL now supports the following new date/time functions:

  • TIMS_IS_VALID
  • TSTMP_IS_VALID
  • TSTMP_CURRENT_UTCTIMESTAMP
  • TSTMP_SECONDS_BETWEEN
  • TSTMP_ADD_SECONDS
  • TSTMP_TO_DATS
  • TSTMP_TO_TIMS
  • TSTMP_TO_DST
  • DATS_TIMS_TO_TSTMP
  • ABAP_SYSTEM_TIMEZONE
  • ABAP_USER_TIMEZONE

strict mode from Release 7.53

Modification 6

Publishing Associations of Common Table Expressions

When CDS views are accessed within a common table expression, the addition WITH ASSOCIATIONS of the statement WITH can now be used to publish associations of these views for use in path expressions of the current WITH statement. The addition REDIRECT TO can also be used to replace the target data source of the published association with a previous CTE or the current CTE.

When used, this addition requires the strict mode from Release 7.53.

Modification 7

Number Literals in the SELECT List

Until now, only those numeric literals whose value matched the value range of the type INT4 could be specified as elementary SQL expressions in the SELECT list of a query. Now numeric literals of up to 31 digits can be specified, which are interpreted as numbers of the type DEC if the value range of INT4 is exceeded.

Modification 8

Enhanced Cast Matrix

A cast expression can now be used to convert the data types INT1, INT2, INT4, and INT8 to DEC.

Modification 9

Client Handling in Subquery of the Statement INSERT

The addition USING CLIENT of the statement INSERT can now be specified in a subquery. This means that the client specified for the target table of the insert operation can be different from the client specified for the data source of the subquery.

If USING CLIENT is not specified in the subquery, the current client ID is now always applied to implicit client handling. Before Release 7.53, the client ID specified after INSERT using USING CLIENT was also used in the subquery.

The FROM clause of the subquery can now access the database table or classic view filled using the INSERT statement. This makes it possible to copy the data from one client to another.

In the subquery, using USING CLIENT or accessing the database table or classic view filled by the INSERT statement enables strict mode from Release 7.53.

Modification 10

Subquery as Data Source of MODIFY

In the ABAP SQL write statement MODIFY, a parenthesized subquery SELECT subquery_clauses can now be specified as a data source after FROM. The rows of the results set of the subquery are modified or inserted in the target table directly on the database. No data transport is required between the database and AS ABAP. When used in MODIFY, a subquery demands strict mode from Release 7.53.

Modification 11

USING CLIENT and Session Variable client

In an ABAP SQL read in which multiple queries access client-specific CDS views and the client handling method is defined using the annotation @ClientHandling.algorithm:#SESSION_VARIABLE, the session variable client (which corresponds to the ABAP-specific session variable CDS_CLIENT on the SAP HANA database) must be set to the same value in all of these queries. The runtime error SAPSQL_DIFFERENT_CLIENT_VALUES occurs if USING CLIENT is used to specify a different client ID in one of these queries. This situation can occur in the statement WITH or when using UNION.

Modification 12

Null Values in the Table Buffer

The table buffer now supports real null values. In table buffering, null values are no longer transformed to type-dependent initial values. When the buffer is accessed, the same results are produced as when the database is accessed directly. The corresponding restrictions now no longer apply. The following are some of the aspects affected:

  • Relational expressions with operands that contain null values. The result of a comparison of this type is now also unknown when the comparison is made in the buffer (except in the expression IS [NOT] NULL).
  • If used, IS [NOT] NULL no longer bypasses table buffering.
  • Accesses to buffered CDS views. When the buffer is accessed, the same results are now produced as when the database is accessed directly. Null values are often produced by outer joins or in expressions such as case distinction expressions. The restriction specifying that only those CDS views are buffered whose elements do not contain null values no longer applies.

Modification 13

Restrictions Removed

  • For certain SQL expressions and functions, an ABAP SQL read statement no longer bypasses table buffering.
  • ABAP SQL read statements no longer bypass table buffering in cases where a column is specified on the right side of comparisons or of BETWEEN in a condition that is not required to identify a single row or a generic range. The prerequisite for this is that both operands are numeric but do not have the type DF16_DEC or DF34_DEC, that both operands are character-like, or that both operands have the type RAW with the same lengths.

Modification 14

Weaker Check

ABAP SQL statements that exploit a database property not supported by all database platforms no longer produce a syntax check warning and produce a syntax warning in the extended program checks instead.

Modification 15

New Check

If the data of the internal table needs to be transported to the database in cases where the internal table is used as a data source of the ABAP SQL statement SELECT, a syntax check warning occurs that can be hidden using the pragma ##itab_db_select.

Modification 16

Replacement Service in Program Calls

The method ACTIVATE_REPLACEMENT of the class CL_OSQL_REPLACE has the new parameter FLG_SURVIVE_SUBMIT, which now also permits redirections in called programs.

Modification 17

GROUP BY Addition GROUPING SETS

In a SELECT statement, the GROUP BY addition GROUPING SETS can now be used. The addition GROUPING SETS makes it possible to group multiple grouping sets under one GROUP BY clause. This is the same as specifying UNION ALL with different GROUP BY clauses. The addition GROUPING SETS has an advantage over a UNION clause grouping because the SELECT clause only needs to be specified once.

Using GROUPING SETS triggers strict mode from Release 7.53.

Modification 18

Aggregate Function GROUPING

The aggregate function GROUPING can now be used in a SELECT statement. The grouping function GROUPING can be used to verify whether a specific column is part of the aggregation. The grouping function can be used only if the GROUP BY clause contains the addition GROUPING SETS.

Modification 19

Stricter Checks on Syntax Rules

A violation of the following rules now always produces a syntax error. In the strict modes of the syntax check, these violations already produced a syntax error. Outside the strict modes, they produced a syntax check warning and in most cases a runtime error when the program was executed.

  • When a view is accessed, its key fields must be located together at the start.
  • The additions USING CLIENT and CLIENT SPECIFIED cannot be used when a CDS entity is accessed that is associated with a CDS role.
  • Even when using path expressions, the addition CLIENT SPECIFIED can only be used for client-specific data sources.
  • When a column is specified, the actual names of the components must be used for a database table containing an include structure, and not the names of any groups defined in ABAP Dictionary.
  • An alternative column name of the SELECT list defined using AS can have a maximum of 30 characters. Alternative column names with more than 30 characters are also not allowed after ORDER BY.
  • Columns of the types LCHR and LRAW can be read in a query only if they are read together with the associated length fields.
  • The following applies when using FOR ALL ENTRIES in the SELECT statement:
  • The decimal places in the comparisons between columns of a data source and columns of the internal table of type p must match.
  • All columns of the primary key specified after ORDER BY using PRIMARY KEY must also occur in the SELECT list.
  • The pseudo component table_line can be specified only for internal tables with an elementary row type.
  • A GROUP BY grouping must be applied to columns specified after HAVING outside aggregate functions. The same applies to columns specified directly in the SELECT list when a HAVING clause is specified, but that are not specified after GROUP BY.
  • If a SELECT list is specified as *, a HAVING clause can only be used together with a GROUP BY clause.
  • If an alternative name is used after ORDER BY, this name must be unique and cannot be the same name as a column that does not have any alternative names.
  • A work area wa specified in the INTO clause has fewer components than explicit columns in the SELECT list.
  • A column specified explicitly in the SELECT list cannot be assigned to the associated component of a structured work area wa specified in the INTO clause or to a data object dobj specified in a parenthesized comma-separated list.
  • No character literals or constants can be specified on the right side of LIKE that are more than twice as long as the left side.
  • The statements UPDATE FROM or MODIFY FROM are used to access a projection view in which all fields are key fields.
  • A reference that is too general is specified in the statements INSERT FROM, UPDATE FROM, or MODIFY FROM when a writer stream is created.
  • In the statement UPDATE, a column can occur only on the left side of a single update expression.