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 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.

Cannot Use an Asterisk To Indicate a Work Area

You cannot declare a *work area as a database table or work area in ABAP Objects.

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

SELECT ... FROM *dbtab INTO ...

INSERT *dbtab.

UPDATE *dbtab.

DELETE *dbtab.

MODIFY *dbtab.

Cause:

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.

Cannot 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 error message for:

DELETE dbtab VERSION vers.
MODIFY dbtab VERSION vers.

Correct syntax:

CONCATENATE 'T' vers INTO 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, an error message occurs on:

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 from local classes, and cannot call 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.