Ansicht
Dokumentation

ABENABAP_OBJECTS_DIFF_SQL - ABAP OBJECTS DIFF SQL

ABENABAP_OBJECTS_DIFF_SQL - ABAP OBJECTS DIFF SQL

CPI1466 during Backup   General Data in Customer Master  
This documentation is copyright by SAP AG.
SAP E-Book

Syntax Revisions for Database Accesses

Cannot Use Short Forms

In ABAP Objects, you must declare work areas explicitly in each SQL statement. You can create data objects with the appropriate type with reference to the definition of the database in the ABAP Dictionary for this purpose.

In ABAP Objects, the following statements cause an error message:

SELECT ... FROM dbtab

INSERT dbtab.

UPDATE dbtab.

DELETE dbtab.

MODIFY dbtab.

Correct syntax:

DATA wa TYPE dbtab.

SELECT ... FROM dbtab INTO wa.

INSERT dbtab FROM wa.
or
INSERT INTO dbtab VALUES wa.

UPDATE dbtab FROM wa.
or
UPDATE dbtab SET ... .

DELETE dbtab FROM wa.
or
DELETE FROM dbtab WHERE ...

MODIFY dbtab FROM wa.

Cause:

Separating database names and ABAP work areas makes programs easier to read. To work with short forms, you need to declare table work areas using the TABLES, which is not allowed in ABAP objects.

Note:

This does not apply to SELECT statements in sub-queries. You cannot use the INTO clause with a sub-query. See the EXISTS construction of the WHERE and HAVING clauses of the SELECT, UPDATE, DELETE, and OPEN CURSOR statements.

Do Not Use *Work Area

The use of *work areas as an indicator for database tables or work areas in ABAP Objects is forbidden.

In ABAP Objects, the following statements cause an error message:

SELECT ... FROM *dbtab INTO ...

INSERT *dbtab.

UPDATE *dbtab.

DELETE *dbtab.

MODIFY *dbtab.

Correct syntax:

DATA wa TYPE dbtab.

SELECT ... FROM dbtab INTO wa.

INSERT dbtab FROM wa.
or
INSERT INTO dbtab VALUES wa.

UPDATE dbtab FROM wa.
or
UPDATE dbtab SET ... .

DELETE dbtab FROM wa.
or
DELETE FROM dbtab WHERE ...

MODIFY dbtab FROM wa.

Reason:

The DATA statement, used to declare appropriately typed work areas, replaced the declaration of *work areas. You can only declare *work areas using the TABLES statement, which is not supported in ABAP Objects. You can only use *work areas in the short forms of Open-SQL statements, which are also not supported.

Cannot Use READ TABLE

You cannot use READ TABLE to read data from database tables in ABAP Objects.

In ABAP Objects, the following statements cause an error message:

t100 = space.
t100-sprsl = 'D'.
t100-arbgb = 'BC'.
t100-msgnr = '100'.

READ TABLE t100.

Correct syntax:

DATA wa TYPE t100.

SELECT SINGLE * FROM t100 INTO wa WHERE sprsl = 'D'  AND
                                        arbgb = 'BC' AND
                                        msgnr = '100'.

Cause:

The Open-SQL statement SELECT has replaced READ TABLE. The latter works only with database tables whose names correspond to the naming conventions for R/2-ATAB tables (maximum of 5 characters, starting with T) and with table work areas declared using TABLES, which are not supported in ABAP Objects. Generic key values are used for accesses, which are taken from the filled area of the table work area from left to right. Instead, declare the key explicitly in the WHERE clause of the SELECT statement.

Cannot UseLOOP AT

You cannot use the LOOP AT statement to read data from database tables in ABAP Objects.

In ABAP Objects, the following statements cause an error message:

t100 = space.
t100-sprsl = 'D'.
t100-arbgb = 'BC'.
t100-msgnr = '1'.

LOOP AT t100.
  ...
ENDLOOP.

Correct syntax:

DATA wa TYPE t100.

SELECT * FROM t100 INTO wa WHERE sprsl = 'D'  AND
                                 arbgb = 'BC' AND
                                 msgnr LIKE '1%'.
  ...
ENDSELECT.

Cause:

The Open-SQL and SELECT statements have replaced LOOP AT. The latter only works with database tables, whose name corresponds to R/2-ATAB naming conventions (no more than five places, beginning with T) or with table work areas declared using theTABLES statement, which is not allowed in ABAP Objects. Access is by generic key values, which are taken from the filled part of the table work area from left to right. For this reason, you should declare keys explicitly in the WHERE clause of the SELECT statement instead.

Do Not Use REFRESH FROM

The REFRESH FROM statement for reading data from database tables is not allowed in ABAP Objects.

Error message in ABAP Objects for:

t100 = space.
t100-sprsl = 'D'.
t100-arbgb = 'BC'.
t100-msgnr = '1'.

REFRESH itab FROM TABLE t100.

Correct syntax:

DATA wa TYPE t100.

SELECT * FROM t100 INTO TABLE itab WHERE sprsl = 'D'  AND
                                         arbgb = 'BC' AND
                                         msgnr LIKE '1%'.

Reason:

The statement is replaced with the Open SQL statement SELECT. It only works with database tables whose name satisfies the naming conventions for R/2-ATAB tables (maximum five places and a T in the first position) and with table work areas declared with TABLES that are not allowed in ABAP objects. Generic key values are used for the accesses that are taken from the left-justified reserved part of the table work area. Instead, the key should be defined explicitly in the WHERE clause of the SELECT statement.

Cannot Use VERSION Addition

The VERSION addition in the Open-SQL statements DELETE and MODIFY (and of course in the obsolete statements READ TABLE and LOOP AT) is not allowed in ABAP Objects.

In ABAP Objects, the following statements cause an error message:

DELETE dbtab VERSION vers.
MODIFY dbtab VERSION vers.

Correct syntax:

vers = 'T' && vers.

DELETE (vers) FROM dbtab.
MODIFY (vers) FROM dbtab.

Reason:

The VERSION addition only works with database tables whose name satisfies the naming convention for R/2-ATAB tables. Dynamically defining the database table with bracketed field names replaces the VERSION addition.

Wrong Logical Operators in the WHERE Clause

The logical operators >< , =< and => are not allowed in ABAP Objects.

Error message in ABAP Objects for:

... >< ... =< ... => ...

Correct syntax:

... <> ... <= ... >= ...

Reason:

These operators for not equal, less than or equal and greater than or equal are superfluous. They have the same function as <> , <= and >= (or NE, LE and GE).

Subroutine Calls Not Allowed in EXEC SQL

Using the PERFORMING addition in the EXEC SQL statement to use a subroutine to process data line by line that you have read using Native SQL is not allowed in ABAP Objects. The EXIT FROM SQL statement, previously used within such subroutines, is also forbidden.

In ABAP Objects, the following syntax causes an error message:

EXEC SQL PERFORMING form.
  select ... into :wa from dbtab where ...
ENDEXEC.

FORM form.
  ...
  EXIT FROM SQL.
  ...
ENDFORM.

Correct syntax:

EXEC SQL.
  open c1 for
  select ... from dbtab where ...
ENDEXEC.

DO.
  EXEC SQL.
    fetch next c1 into :wa
  ENDEXEC.
  IF sy-subrc <> 0.
    EXIT.
  ENDIF.
  ...
ENDDO.

EXEC SQL.
  close c1
ENDEXEC.

Reason:

You should not call subroutines of the main program in local classes and you cannot call them in them from global classes. The called subroutine has no interface, working instead with the global data of the main program. The EXIT FROM SQL statement ends the SQL processing without reference to the actual SQL statement.






CPI1466 during Backup   PERFORM Short Reference  
This documentation is copyright by SAP AG.

Length: 11677 Date: 20240425 Time: 151138     sap01-206 ( 169 ms )