In ABAP Objects, the following statements cause an error message:
DATA: field-name TYPE ...,
1name TYPE ...
Correct syntax:
DATA: field_name TYPE ...,
name1 TYPE ...
Cause:
You cannot use special characters in names, because they often have a particular meaning in the system. The new naming conventions correspond to those for other programming languages.
In ABAP Objects, the following syntax causes an error message:
TABLES dbtab.
Correct syntax:
DATA wa TYPE dbtab.
Reason:
The semantics of the TABLES statement is ambiguous.
Explicit work areas should be defined for database accesses instead of implicit table work areas.
Common interface work areas for passing data between programs and
procedures are not supported in ABAP Objects.
In classes, only the components that a user can see are used as interface, that is, visible attributes and the interface parameters of methods and events.
The data transport between ABAP programs and
logical databases or
dynpros via global table work areas is not allowed in ABAP Objects and is replaced with other concepts.
In ABAP Objects, the following statement causes an error message:
NODES struc.
Correct syntax:
DATA wa TYPE struc.
Cause:
ABAP Objects does not support the old method of working with
logical databases. Data transports between ABAP programs and logical databases using global work areas is not possible in ABAP Objects.
In ABAP Objects, the following syntax causes an error message:
DATA BEGIN OF COMMON PART c,
...
DATA END OF COMMON PART.
Reason:
Common interface work areas for data transfer between programs and
procedures are not supported in ABAP Objects.
In classes only the components visible to a user are used as interfaces, that is, visible attributes and the interface parameters of methods and events.
In ABAP Objects, the following statement causes an error message:
DATA f LIKE dbtab.
Correct syntax:
DATA f TYPE dbtab.
Cause:
The TYPE addition should be the only construction that allows a reference to data types, while the LIKE addition should only be used for data objects. The
Repository objects in the ABAP
Dictionary are data types, not data objects. Outside the ABAP Objects context, the LIKE reference to database tables and
flat structures in the ABAP Dictionary is still allowed for compatibility reasons.
In ABAP Objects, the following statement causes an error message:
TYPES: t1,
t2 TYPE p.
Correct syntax:
TYPES: t1(1) TYPE c,
t2(8) TYPE p DECIMALS 0.
Cause:
Complete type definitions are a prerequisite for considering incompletely defined types
as generic types later. In the DATA statement, short forms are completed as before.
In ABAP Objects, the following statement causes an error message:
DATA: f1(8) TYPE d, f2(4) TYPE i.
Correct syntax:
DATA: f1 TYPE d, f2 TYPE i.
Cause:
The inbuilt elementary data types D, F, I, and T already have predefined, unmodifiable lengths. Entering a different length is not allowed. Entering the predefined length is superfluous.
Error message in ABAP objects for:
TYPES: BEGIN OF line,
col1 TYPE i.
MOVE 'X' TO a.
TYPES: col2 TYPE i,
END OF line.
Correct syntax:
TYPES: BEGIN OF line,
col1 TYPE i,
col2 TYPE i,
END OF line.
MOVE 'X' TO a.
Reason:
The definition of a structure between BEGIN OF
and END OF is an entire block in which only the components of the structure may be declared.
In ABAP Objects, the following statements cause an error message:
DATA: BEGIN OF struc,
'Text Literal',
space(10) [TYPE c],
text(10) TYPE c VALUE 'Text Field',
END OF struc.
Correct syntax:
DATA: BEGIN OF struc,
text1(12) TYPE c VALUE 'Text Literal',
blanks(10) TYPE c VALUE IS INITIAL,
text2(10) TYPE c VALUE 'Text Field',
END OF struc.
Cause:
You should be able to address each component in a structure explicitly. If you declare
literals, or the special name space in the structure definition,
nameless text fields are included as components. For literals, the initial and value correspond to the
content of the literal. For space, the system creates
a text field filled with spaces. These anonymous text fields cannot be addressed explicitly in programs.
In particular, structures never contain components with the name space.
You can only access anonymous components using the structure name and offset/length addressing. You
can easily replace these nameless components with named components. Named components increase the function
of anonymous components by allowing them to be accessed explicitly, without limiting their role as, for example, as filler fields.
In ABAP Objects, the following statements cause a syntax error:
METHOD|FUNCTION|FORM ...
DATA f TYPE ... NON-LOCAL.
...
ENDMETHOD|ENDFUNCTION|ENDFORM.
Correct syntax:
DATA f TYPE ...
METHOD|FUNCTION|FORM ...
...
ENDMETHOD|ENDFUNCTION|ENDFORM.
Cause:
The undocumented addition NON-LOCAL changes the attributes of a class or the local data objects of a
procedure into global data objects of the
main program. However, global data objects can only be defined in the main program, by their very nature. In particular,
class pools cannot contain global data objects; NON-LOCAL allows developers to get round this rule.
Error message in methods if the following syntax is used:
METHOD ...
...
FIELD-GROUPS fg.
...
ENDMETHOD.
Reason:
An extract dataset currently exists only as a global object of the
main program. Therefore the field groups
can only be defined globally in the main program. However, the definition of the field group structure,
which is generated at runtime by the statement INSERT ... INTO fg, can also be executed in methods.
Error message in ABAP Objects if the following syntax is used:
FIELDS f.
Correct syntax:
New pseudo comment for the extended program check.
Reason:
FIELDS no longer has any operational significance but is merely used as a note for the extended program check.
In ABAP Objects, the following statements cause an error message:
METHOD ...
STATICS s ...
...
ENDMETHOD.
Reason:
The STATICS statement in a method corresponds
to a CLASS-DATA statement, where the visibility of the declared data objects is limited to the method. This is a potential source of misunderstanding in instance methods.