Get Example source ABAP code based on a different SAP table
ARTICLE
Syntax Revisions for Database Accesses ABAP Code Snippet ARTICLE
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. ABAP Code Snippet ABAP Code Snippet ARTICLE
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. ABAP Code Snippet ABAP Code Snippet ARTICLE
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:
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. ABAP Code Snippet ABAP Code Snippet ARTICLE
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:
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. ABAP Code Snippet ABAP Code Snippet ARTICLE
Do Not Use REFRESH FROM The REFRESH FROM statement for reading data from database tables is not allowed in ABAP Objects.
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. ABAP Code Snippet ABAP Code Snippet ARTICLE
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. ABAP Code Snippet ABAP Code Snippet ARTICLE
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). ABAP Code Snippet ABAP Code Snippet ARTICLE
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. ABAP Code Snippet