SAP NEWS-740 SP05-ABAP SQL Get Example source ABAP code based on a different SAP table
SAP Help
AB_SQL in ABAP Release 7.40, SP05 ITOC
ABAP_MODIFICATION_NN Comma-Separated Lists> In AB_SQL , all operands in lists can now be separated by commas and this is also the recommended way of separating them from ABAP_RELEASE 7.40, SP05. Until now, comma-separated lists could only be used when single target fields were specified in parentheses after
INTO>> in SELECT> and when data objects were specified in parentheses after WHERE>>. Comma-separated lists are now also possible in programs of ABAP language version ABAP_STANDARD > where the program property fixed point arithmetic>> is activated: The following restrictions apply in the statement SELECT>> When columns, aggregation expressions or SQL expressions are specified in the SELECT> list>. When columns are specified after GROUP BY> > When columns are specified after ORDER BY> > In the statement UPDATE>> When change expressions are specified after SET>> This makes blank-separated lists obsolete>. If one of these lists is separated by commas, the syntax check is performed in a strict mode>, which handles the statement more strictly than the regular syntax check. The constraint that blanks were forbidden after the opening parenthesis in comma-separated lists after INTO> and IN> if more than one comma occurs (if more than one data object is specified) no longer applies from SP05. ABAP_MODIFICATION_NN Escape Character for Host Variables> ABAP data objects used in AB-SQL statements (usually variables) are now interpreted as host variables>, as in statically embedded Native SQL>. From ABAP_RELEASE 7.40, SP05, host variables can and should be prefixed with the escape character @>. Host variables without the escape character are obsolete> . If the escape character is used in front of a name of an AB-SQL statement, the syntax check is performed in a strict mode>, which handles the statement more strictly than the regular syntax check. The escape character can only be used in programs of language version ABAP_STANDARD >, in which the program property fixed point arithmetic>> is activated. Using the escape character requires a strict syntax check of the complete statement. During this check, any errors that would normally only be displayed as syntax warnings are reported as syntax errors. ABAP_MODIFICATION_NN SQL Expressions> From ABAP_RELEASE 7.40, SP05, SQL expressions> can be specified in a comma-separated SELECT> list >. The result of an expression of this type (whose operands can be the names of columns or host variables) is determined by the database system and passed to AS ABAP in the appropriate column of the result set. SQL expressions can only be used in programs of language version ABAP_STANDARD >, in which the program property fixed point arithmetic>> is activated. When SQL expressions are used, the syntax check is performed in a strict mode>, which handles the statement more strictly than the regular syntax check. ABAP_MODIFICATION_NN Switching Implicit Client Handling> The new addition USING CLIENT clnt>> , which can be specified in all AB_SQL statements as an alternative to CLIENT SPECIFIED> >, switches implicit client handling > to the client> specified in clnt>. When the addition USING CLIENT> is used, the syntax check is performed in a strict mode>, which handles the statement more strictly than the regular syntax check. ABAP_MODIFICATION_NN Rule Changes for Joins> The following previous constraints on joins> have been lifted: From ABAP_RELEASE 7.40, SP05, it is no longer the case that all comparisons of the ON> condition must contain a column from a database table or view on the right side as an operand. From ABAP_RELEASE 7.40, SP05, the right side of a join expression is no longer restricted to single tables or views. The right side can itself be a (parenthesized) join expression whose result set is then evaluated. In ABAP_RELEASE 7.40, SP05 and higher, RIGHT OUTER JOIN> can be used in addition to LEFT OUTER JOIN>. From ABAP_RELEASE 7.40, SP05, fields from the right side in the WHERE > condition of the current SELECT> statement can be specified in LEFT OUTER JOIN>. Fields from the left side can be specified in RIGHT OUTER JOIN>. In SELECT> statements that exploit the rule changes above, the syntax check is performed in a strict mode>, which handles the statement more strictly than the regular syntax check. ABAP_MODIFICATION_NN Evaluating INTO CORRESPONDING>> If all required components are known statically, the assignment of the fields in the addition CORRESPONDING> after INTO>> is now determined when the program is generated and is not delayed until runtime. The addition INTO CORRESPONDING> now also modifies the actual SELECT> list> that is passed to the database and hence also the SELECT> statement. If one or more names match, all the columns for which there are no name matches are removed from the SELECT> list implicitly. If there are no name matches, none of the columns are removed from the result set. If * > is specified for the SELECT> list>, a list of columns may be updated implicitly. ABAP_MODIFICATION_NN Access to CDS Entities> SELECT>> can be used to access CDS entities>. Potential CDS entities are currently CDS views> defined in the ABAP CDS> DDL using DEFINE VIEW>>. Implicit client handling> is performed for client-dependent> CDS views. If this handling is disabled using the addition CLIENT SPECIFIED>>, the client column is part of the result set, even though the column is not an element of the CDS view. The new addition CLIENT SPECIFIED>> of statement TYPES> can be used to declare a suitable target area. New additions for CLIENT SPECIFIED> > after FROM>> make it possible to address the column in the SELECT> statement. If (as recommended) the name of the CDS entity> is used for accesses and not the name of the ABAP_CDS_MNG_VIEW >, the syntax check is performed in a strict mode>, which subjects the statement to stricter checks than in the regular syntax check. ABAP_MODIFICATION_NN Strict Mode in the Syntax Check> If one of the new features specified above is used in an AB-SQL statement, the syntax check is performed in a strict mode>, which handles the statement more strictly than the regular syntax check. ABAP_MODIFICATION_NN Stricter Checks on Syntax Rules> In ABAP_RELEASE 7.40, SP02>, a new SQL parser was introduced for AB_SQL . These parser performs stricter checks on some rules than the old parser. More specifically, the same parser is now used for statically specified AB_SQL and for the content of dynamic tokens. In ABAP_RELEASE 7.40, SP02 >, this parser will initially only be used for the statement SELECT>>. From ABAP_RELEASE 7.40, SP05, the new parser will be used for all AB-SQL statements. One consequence of this is that any following syntax constructs that have always contained errors now produce syntax errors or runtime errors. Corrections for the WHERE> Condition All corrections in ABAP_RELEASE 7.40, SP02 > that apply to the WHERE> condition> now also apply to the statements DELETE>>, OPEN CURSOR>>, and UPDATE>> from ABAP_RELEASE 7.40, SP05. Example> From ABAP_RELEASE 7.40 SP05, syntax errors for: DELETE FROM spfli WHERE NOT NOT carrid = 'LH'.> Corrections for dynamic tokens All corrections in ABAP_RELEASE 7.40, SP02 > that apply to dynamic tokens now also apply to all AB-SQL statements from ABAP_RELEASE 7.40, SP05. Example> From ABAP_RELEASE 7.40 SP05, exception for: DELETE FROM (`SPFLI .`) WHERE (`. CARRID = 'LH'`).> Correction for OPEN CURSOR> The addition WITH HOLD> of the statement OPEN CURSOR>> can be used only in reads performed on the standard database. If the addition CONNECTION>> is specified at the same time, a runtime error was produced before ABAP_RELEASE 7.40 SP05 (and not a syntax error), if the database table was specified dynamically. This gap was closed in ABAP_RELEASE 7.40 SP05. Example> From ABAP_RELEASE 7.40 SP05, syntax errors for: OPEN CURSOR WITH HOLD cursor FOR SELECT * FROM ('SPFLI') CONNECTION con.> ABAP_MODIFICATION_NN Specifying Dynamic Tokens> From ABAP_RELEASE 7.40, SP05 and higher, internal tables, which are specified as dynamic tokens can also have secondary keys in modifying AB-SQL statements>.