ABAP Keyword Documentation → ABAP - Release-Specific Changes → Changes in Release 6.10
SQL and Updates in Release 6.10
1. COMMIT WORK in local updates
2. Additional syntax checks
3. Type check in the addition VERSION
4. Dynamic SQL
5. Automatic client handling
6. Use of DISTINCT in pooled tables and cluster tables
7. Database changes using read-only views
8. Handleable exceptions in Open SQL and Native SQL
9. INSERT and UPDATE of the system table TRDIR
10. Selection table and target table in FOR ALL ENTRIES
11. New exception for pooled tables and cluster tables
12. Strings on the database
13. WHERE condition optional in DELETE statement
Other versions: 7.31 | 7.40 | 7.54
Modification 1
COMMIT WORK in Local Updates
As in the asynchronous update, the system now also sets the system field SY-ONCOM = V in the local update.
Therefore the system recognizes a COMMIT WORK
in the function module, which carries out the local update, and this leads to an exception that cannot be handled (runtime error)
Modification 2
Additional Syntax Checks
Additional syntax checks have been introduced for the following constructs:
WHERE conditions are only permitted if the source table is transparent.
GROUP BY is now also only possible with transparent tables.
INTO CORRESPONDING is now only possible when moving data to structured work areas or internal tables.
ESCAPE in WHERE conditions for SELECT, DELETE, and UPDATE of pooled tables
Modification 3
Type Check in the Addition VERSION
In the case of the statements MODIFY,
DELETE,
READ TABLE, and LOOP AT only fields of types C, N, D, T, and
flat structures of the same types are permitted for the addition VERSION. In
Unicode programs, there is a syntax error or a warning.
Modification 4
Dynamic SQL
Dynamic specifications are now possible for the following language constructions:
WHERE,
HAVING, FROM, and SET.
WHERE for DELETE and UPDATE
SET for UPDATE.
HAVING clause
FROM
for SELECT ... FROM for joins, ON conditions, and
table aliases
Modification 5
Automatic Client Handling
The client specification is now carried out in the database interface. Previously the system changed
the client field in an internal table or work area, as soon as the user carried out an
INSERT or UPDATE
on the database table. Now the system enters the current client in the database table, while the client in the work area or internal table remains unchanged.
Modification 6
Use of DISTINCT in Pooled Tables and Cluster Tables
If DISTINCT is used in the
SELECT clause with pooled tables and cluster tables, this always produces (statically) a
syntax error if individual columns are accessed. This combination was not recognized dynamically and
the addition DISTINCT was simply not executed. In dynamic cases, the handleable exception CX_SY_DYNAMIC_OSQL_SEMANTICS is now raised.
Modification 7
Database Changes Using Read-Only Views
Previously, an attempt to change database tables using read-only views simply caused a runtime error. In the case of static recognition, a syntax error is now triggered.
Modification 8
Handleable Exceptions in Native SQL and Open SQL
In statically embedded Native
SQL, all runtime errors of the database interface have now been assigned exception classes, so that
the exceptions between TRY ... ENDTRY can be handled. In addition, the opening of too many
cursors and connections can be caught.
In Open SQL, exceptions that occur when the source
code is being parsed can now be handled using TRY
... ENDTRY. In addition, the runtime errors DUPLICATE KEY, SQL ERROR, STATEMENT TOO LARGE, LOBLENGTH EXCEEDED, CONVERSION ERROR
and INVALID CURSOR have been assigned exception classes.
Modification 9
INSERT and UPDATE of the System Table TRDIR
Previously, the instructions INSERT
TRDIR and UPDATE TRDIR
were valid. In the case of UPDATE TRDIR, the attributes could be changed by the runtime synchronization
without registration. Both statements now cause a syntax error. Only
MODIFY TRDIR and MODIFY TRDIR FROM wa are still permitted, because there the runtime synchronization is switched on.
Modification 10
Selection Table and Target Table in FOR ALL ENTRIES
The table of selection conditions for FOR ALL
ENTRIES and the target table of the SELECT
statement can be the same. This makes the form SELECT ... INTO itab FOR ALL ENTRIES IN itab possible.
Modification 11
New Exception for Pooled Tables and Cluster Tables
If pooled tables or cluster tables are used in subqueries, joins, aggregate functions, or with GROUP BY, this raises the exception CX_SY_DYNAMIC_OSQL_SEMANTICS.
Modification 12
Strings on the Database
It is now possible to edit character strings and binary data saved to database columns as strings in Open SQL.
Modification 13
WHERE Condition Optional in DELETE Statement
In the statement DELETE FROM dbtab,
the WHERE condition is no longer required. A DELETE statement without a WHERE condition deletes all rows of a table.