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 with 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 and Native SQL
9. INSERT and UPDATE of the system table TRDIR
10. Selection table and target table with FOR ALL ENTRIES
11. New exception for pooled tables and cluster tables
12. Strings in 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 addition 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 with the addition VERSION
In the case of the additions 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 VERSION addition. In
Unicode there will be 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 you use DISTINCT in the
SELECT clause with pooled tables and cluster tables this always statically causes a syntax
error if you are accessing individual columns. This combination was not recognized dynamically and the
DISTINCT addition was simply not executed. Now the handleable exception CX_SY_DYNAMIC_OSQL_SEMANTICS is raised, if you use the statement dynamically.
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
Exceptions that can be handled in Native and Open SQL
In 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 with 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 allows you to use statements in the form SELECT ... INTO itab FOR ALL ENTRIES IN itab.
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 Ausnahme CX_SY_DYNAMIC_OSQL_SEMANTICS.
Modification 12
Strings in the database
With Open SQL you can now store character strings and binary data in database columns as strings.
Modification 13
WHERE condition optional in DELETE statement
In the DELETE FROM dbtab
statement, the WHERE condition is no longer required. A DELETE statement without a WHERE condition deletes all rows of a table.