The SCN wiki will not be available for new content submission starting September 4th 6PM CET until September 7th 6PM CET. Please plan your SCN wiki tasks accordingly.
Field symbols are placeholders or symbolic names for other fields. They do not physically reserve space for a field, but point to its contents. A field symbol cam point to any data object. The data object to which a field symbol points is assigned to it after it has been declared in the program. Whenever you address a field symbol in a program, you are addressing the field that is assigned to the field symbol. After successful assignment, there is no difference in ABAP whether you reference the field symbol or the field itself. You must assign a field to each field symbol before you can address the latter in programs. Field symbols are similar to dereferenced pointers in C (that is, pointers to which the content operator * is applied). However, the only real equivalent of pointers in ABAP, that is, variables that contain a memory address (reference) and that can be used without the contents operator, are reference variables in ABAP Objects.
All operations programmed with field symbols are applied to the field assigned to it. For example, a MOVE statement between two field symbols moves the contents of the field assigned to the first field symbol to the field assigned to the second field symbol. The field symbols themselves point to the same fields after the MOVE statement as they did before.
You can create field symbols either without or with type specifications. If you do not specify a type, the field symbol inherits all of the technical attributes of the field assigned to it. If you do specify a type, the system checks the compatibility of the field symbol and the field you are assigning to it during the ASSIGN statement.
Field symbols provide greater flexibility when you address data objects:
- If you want to process sections of fields, you can specify the offset and length of the field dynamically.
- You can assign one field symbol to another, which allows you to address parts of fields.
- Assignments to field symbols may extend beyond field boundaries. This allows you to address regular sequences of fields in memory efficiently.
- You can also force a field symbol to take different technical attributes from those of the field assigned to it.
Declaring Field Symbols
To declare a field symbol, use the statement
FIELD-SYMBOLS <FS> [<type>|STRUCTURE <s> DEFAULT <wa>].
For field symbols, the angle brackets are part of the syntax. They identify field symbols in the program code.
If you do not specify any additions, the field symbol <FS> can have data objects of any type assigned to it. When you assign a data object, the field symbol inherits its technical attributes. The data type of the assigned data object becomes the actual data type of the field symbol.
Note: it is possible to assign reference variables and structured data objects to untyped field symbols. However, the static field symbol is only a pointer to the field in memory, and does not have the complex type attributes of a reference or structured field until runtime. You can only use the field symbol to address the whole field (for example, in a MOVE statement). Specific statements such as CREATE OBJECT <FS> or LOOP AT <FS> are not possible.
Typing Field Symbols
The <type> addition allows you to specify the type of a field symbol. When you assign a data object to a field symbol, the system checks whether the type of the data object you are trying to assign is compatible with that of the field symbol. If the types are not compatible or convertible, the system reacts with a syntax or runtime error. If however, you want to assign the type of the field symbol to the data object by means of CASTING, you must do so explicitly using the ASSIGN statement. The system then treats the assigned data object as if it had the same type as the field symbol.
You specify the type of a field symbol using the same semantics as for formal parameters in procedures. For <type> you can enter either TYPE <t> or LIKE <f>. You can specify the type either generically or in full. If you specify a generic type, the type of the field symbol is either partially specified or not specified at all. Any attributes that are not specified are inherited from the corresponding data object in the ASSIGN statement. If you specify the type fully, all of the technical attributes of the field symbol are determined when you define it. You can then only assign data objects to it that has exactly the same data type.
You should always specify a type for each field symbol. If you cannot avoid defining a generic field symbol, make this clear by using an appropriate generic type declaration.
Generic Type Specification
Check for data object
No type specification
All types of data object are accepted. The field symbol adopts all of the attributes of the data object.
TYPE C, N, P, or X
Only data objects with type C, N, P, or X are accepted. The field symbol adopts the field length and DECIMALS specification (type P) of the data object.
The system checks whether the data object is a standard internal table. This is a shortened form of TYPE STANDARD TABLE (see below).
TYPE ANY TABLE
The system checks whether the data object is an internal table. The field symbol inherits all of the attributes (line type, table type, key) from the data object.
TYPE INDEX TABLE
The system checks whether the data object is an index table (standard or sorted table). The field symbol inherits all of the attributes (line type, table type, key) from the data object.
TYPE STANDARD TABLE
The system checks whether the data object is a standard internal table. The field symbol inherits all of the remaining attributes (line type, key) from the data object.
TYPE SORTED TABLE
The system checks whether the actual parameter is a sorted internal table. The field symbol inherits all of the remaining attributes (line type, key) from the data object.
TYPE HASHED TABLE
The system checks whether the actual parameter is a hashed internal table. The field symbol inherits all of the remaining attributes (line type, key) from the data object.
TYPES: BEGIN OF line,
DATA: wa TYPE line,
itab TYPE HASHED TABLE OF line WITH UNIQUE KEY col1,
key(4) TYPE c VALUE 'COL1'.
FIELD-SYMBOLS <fs> TYPE ANY TABLE.
ASSIGN itab TO <fs>.
READ TABLE <fs> WITH TABLE KEY (key) = 'X' INTO wa.
The internal table ITAB is assigned to the generic field symbol <FS>, after which it is possible to address the table key of the field symbol dynamically. However, the static address
READ TABLE <fs> WITH TABLE KEY col1 = 'X' INTO wa.
is not possible syntactically, since the field symbol does not adopt the key of table ITAB until runtime. In the program, the type specification ANY TABLE only indicates that <FS> is a table. If the type had been ANY (or no type had been specified at all), even the specific internal table statement READ TABLE <FS> would not have been possible.
Assigning Field Symbols
Instead of using the names of data objects, you can also assign field symbols to field symbols in all variants of the ASSIGN statement.
ASSIGN <FS1>[+<o>][(<l>)] TO <FS2>. in a static ASSIGN and:
ASSIGN [TABLE FIELD] (<f>) TO <FS2>. in a dynamic ASSIGN,
where the field <f> contains the name of a field symbol <FS1>. <FS1> and <FS2> may be identical. Note that the same code in Unicode system will produce different results than in non-Unicode systems:
DATA: BEGIN OF s,
a TYPE c VALUE '1',
b TYPE c VALUE '2',
c TYPE c VALUE '3',
d TYPE c VALUE '4',
e TYPE c VALUE '5',
f TYPE c VALUE '6',
g TYPE c VALUE '7',
h TYPE c VALUE '8',
END OF s.
DATA off TYPE i.
FIELD-SYMBOLS <fs> TYPE ANY.(assignment)
assign s-a to <fs>.
DO 4 TIMES.
off = sy-index - 1.
IF <fs> IS ASSIGNED.
ASSIGN <fs>+off(1) TO <fs>.
IF <fs> IS ASSIGNED.
Attaching a structure to a field symbol
The STRUCTURE addition forces a structured view of the data objects that you assign to a field symbol.
field-symbols <fs> structure <s> default <f>.
The structure <s> is either a structured local data object in the program, or a flat structure from the ABAP Dictionary. <f> is a data object that must be assigned to the field symbol as a starting field. However, this assignment can be changed later using the ASSIGN statement.
The STRUCTURE is obsolete; you should no longer use it. Field symbols defined using the STRUCTURE addition are a mixture of typed field symbols and a utility for casting to either local or ABAP Dictionary data types. If you want to define the type of a field symbol, include the TYPE addition in a FIELD-SYMBOLS statement. If you want to use casting, include the CASTING addition in an ASSIGN statement.
Basic Forms of the ASSIGN Statement
The ASSIGN statement has the following basic forms:
If you already know the name of the field that you want to assign to the field symbol when you write a program, use the static ASSIGN statement:
assign <f> to <fs>.
When you assign the data object, the system checks whether the technical attributes of the data object <f> correspond to any type specifications for the field symbol <FS>. The field symbol adopts any generic attributes of <f> that are not contained in its own type specification. After the assignment, it points to <f> in memory.
FIELD-SYMBOLS: <f1> TYPE ANY, <f2> TYPE i.
DATA: text(20) TYPE c VALUE 'Hello, how are you?',
num TYPE i VALUE 5,
BEGIN OF line1,
col1 TYPE f VALUE '1.1e+10',
col2 TYPE i VALUE '1234',
END OF line1,
line2 LIKE line1.
ASSIGN text TO <f1>.
ASSIGN num TO <f2>.
DESCRIBE FIELD <f1> LENGTH <f2>.
WRITE: / <f1>, 'has length', num.
ASSIGN line1 TO <f1>.
ASSIGN line2-col2 TO <f2>.
MOVE <f1> TO line2.
ASSIGN 'LINE2-COL2 =' TO <f1>.
WRITE: / <f1>, <f2>.
Static ASSIGN with Offset Specification
In a static assign statement, you can use positive offset and length specifications to assign a part of field to a field symbol.
ASSIGN <f>[+<o>][(<l>)] TO <FS>.
When you assign parts of fields to a field symbol, the following special conditions apply:
- The system does not check whether the selected part lies inside the field <f>. Both offset <o> and length <l> can be larger than the length of <f>. You can address memory beyond the boundary of <f>, but not beyond the data areas for field symbols.
- If you do not specify the length <l>, the system automatically uses the length of the field <f>. If <o> is greater than zero, <FS> always points to an area beyond the limits of <f>.
- If <o> is smaller than the length of <f>, you can enter an asterisk for <l> to prevent <FS> from referring to an address beyond the limits of <f>.
If you do not know the name of the field that you want to assign to the field symbol when you write a program, you can use a dynamic ASSIGN statement:
ASSIGN (<f>) TO <FS>.
This statement assigns the field whose name is contained in the field <f> to the field symbol <FS>. You cannot use offset and length in a dynamic ASSIGN.
If the search is successful and a field can be assigned to the field symbol, SY-SUBRC is set to 0. Otherwise, it is set to 4, and the field symbol remains unchanged. For security reasons, you should always check the value of SY-SUBRC after a dynamic ASSIGN to prevent the field symbol pointing to the wrong area.
Searching for the field in this way slows down the program. You should therefore only use the dynamic ASSIGN statement when absolutely necessary. If you know when you create the program that you want to assign a table work area to the field symbol, you can also use the following variant of the dynamic ASSIGN statement:
ASSIGN TABLE FIELD (<f>) TO <FS>.
The system then only searches within the table work areas in the main program of the current program group for the data object that is to be assigned to the field symbol. This addition is forbidden in ABAP Objects, since the latter does not support table work areas.
Suppose we have three programs. The main program:
sbook-fldate = sy-datum.
PERFORM form1 IN PROGRAM demo_form1.
The other two programs are:
*& Form form1
PERFORM form2 IN PROGRAM demo_form2.
*& Form form2
DATA name(20) TYPE c VALUE 'SBOOK-FLDATE'.
FIELD-SYMBOLS <fs> TYPE ANY.
ASSIGN (name) TO <fs>.
IF sy-subrc EQ 0.
WRITE / <fs>.
The program group in the internal session now consists of the programs DEMO, MYFORMS1 and MYFORMS2. The field symbol <FS> is defined in MYFORMS2. After the dynamic ASSIGN statement, it points to the component FLDATE of the table work area SBOOK declared in the main program DEMO.
DATA: name1(20) TYPE c VALUE 'SBOOK-FLDATE',
name2(20) TYPE c VALUE 'NAME1'.
FIELD-SYMBOLS <fs> TYPE ANY.
ASSIGN TABLE FIELD (name1) TO <fs>.
WRITE: / 'SY-SUBRC:', sy-subrc.
ASSIGN TABLE FIELD (name2) TO <fs>.
WRITE: / 'SY-SUBRC:', sy-subrc.
The output is:
In the first ASSIGN statement, the system finds the component FLDATE of the table work area SBOOK and SY-SUBRC is set to 0. In the second ASSIGN statement, the system does not find the field NAME1 because it is declared by the DATA statement and not by the TABLES statement. In this case, SY-SUBRC is set to 4.
Casting Data Objects
When you assign a data object to a field symbol you can cast to any data type. This means that any area of memory can be considered to have a assumed a given type. You can then address parts of fields symbolically without having to use offset/length addressing.
Use the CASTING addition to the ASSIGN statement. This allows you to assign a data object to a field symbol where the type of the data object is incompatible with that of the field symbol. There are two types of CASTING: casting with an implicit type declaration and casting with an explicit type declaration.
Casting with an Implicit Type Declaration
Provided the field symbol is either fully typed or has one of the generic built-in ABAP types - C, N, P, or X - you can use the following statement:
ASSIGN ... TO <FS> CASTING.
When the system accesses the field symbol, the content of the assigned data object is interpreted as if it had the same type as the field symbol. The length and alignment of the data object must be compatible with the field symbol type. Otherwise the system returns a runtime error. If the type of either the field symbol or the data object is - or contains - a string, reference type, or internal table, the type and position of these components must match exactly. Otherwise, a runtime error occurs.
TYPES: BEGIN OF t_date,
year(4) TYPE n,
month(2) TYPE n,
day(2) TYPE n,
END OF t_date.
FIELD-SYMBOLS <fs> TYPE t_date.
ASSIGN sy-datum TO <fs> CASTING.
WRITE / sy-datum.
WRITE: / <fs>-year , / <fs>-month, / <fs>-day.
The output looks something like this: 1999/05/19
In this example, the field symbol <fs> is fully typed using the local program type t_date . The SY-DATUM field can be treated like a structure as a result of the CASTING addition to the ASSIGN statement. This would not be possible without the CASTING addition, since SY-DATUM is incompatible with the field symbol type.
Casting with an Explicit Type Declaration
If the field symbol is neither fully typed nor generically typed, use the following form of the ASSIGN statement:
ASSIGN ... TO <FS> CASTING TYPE <type>|LIKE <obj> [DECIMALS <d>].
When the system accesses the field symbol, the content of the assigned data object is interpreted as if it had the type declared in the statement. After the TYPE addition, you can declare the name of a data object enclosed in parentheses. The content of this data object indicates the data type at runtime.
You cannot enter a type unless an explicit cast to the data object is logical. For example, there is no point casting a standard table to a sorted table, or an object reference to a data reference. Thus, you cannot declare table kinds (such as SORTED TABLE) or reference types (using REF TO) after the TYPE addition. If the data type is - or contains - a string, reference type, or internal table, these components must occur in the assigned data object. Otherwise, the system returns a syntax or runtime error.
The data type declared in the TYPE or LIKE addition must be compatible with the generic type of the field symbol. The generic type can be left as it is or specialized. However, you cannot reset known technical attributes of the field symbol. For example, if the field symbol has the completely generic type ANY, you can declare another permitted generic type. If the field symbol has the generic type C, N, P, or X, you can only specify the length and the number of decimal places. You cannot make an explicit type declaration for a fully typed field symbol, since, if the field symbol is fully typed already, you cannot specialize it further. The system checks this statically if possible, or at runtime if not.
TYPES: BEGIN OF t_date,
year(4) TYPE n,
month(2) TYPE n,
day(2) TYPE n,
END OF t_date.
FIELD-SYMBOLS: <fs> TYPE ANY,
<f> TYPE n.
ASSIGN sy-datum TO <fs> CASTING TYPE t_date.
WRITE / sy-datum.
ASSIGN COMPONENT sy-index OF STRUCTURE <fs> TO <f>.
IF sy-subrc <> 0.
WRITE / <f>.
The output looks something like this:
Definition of Field Groups
A field group combines related fields together into a meaningful unit. It provides you with a pre-selection, so that you do not have to search through all fields of a data source just to produce a simple list.
This means that the end-user only has access to precisely those fields assigned to a field group. Fields must be assigned to a field group before they can be used in queries.
Pre-assigning Field Groups
If you made your entries in the dialog box Title and Database, then field groups are prepared.
If the InfoSet is created using a single table or using a table join, then the following dialog box appears:
You can choose here which fields should be assigned to field groups.
If the InfoSet is created using a logical database then the following applies:
Where the logical database contains a maximum of four nodes, exactly one field group will be created for each node. If the logical database contains more than four nodes then you can determine first, in a dialog, for which nodes a field group should be prepared. For this, the structure tree of the logical database is displayed in a dialog box. Each node, that should have a field group prepared for it, can be selected here with a checkbox.
The prepared field groups have the same long texts as the corresponding nodes. They are empty, meaning that no fields have been assigned to them.
The logical database F1S consists of three hierarchically-arranged tables. Three field groups are generated in advance accordingly:
The predefined and perhaps preassigned field groups can be changed in any way you like. Long text can be changed. Field groups can be deleted or taken up afresh. You are recommended, however, to use and keep the preset 1:1 relationship between field groups and tables, or nodes.
The technology of retrieving predefined content has already been previously realized in the framework of InfoSet maintenance using the InfoSet generator for HR InfoSets (logical databases PNP, PCH and PAP). The existing generation shows a generalization of this technology. The InfoSet generator for HR InfoSets, however, still remains active, meaning that if InfoSets are created using logical databases PNP, PCH, or PAP, then this generator is used for retrieving the predefined content.
There are two different generators for InfoSet with this. You can also use additional generators some can either be used generally for all InfoSets and others just for certain data sources. For an InfoSet with a data retrieval program, a field group is created with all fields of the data structure.
Creating a New Field Group
To create a field group, proceed as follows:
- Choose the symbol Create from the function toolbar (or function Edit ? Field Group ? Create Field Group). A window appears where you can define single or multiple new field groups.
- Enter an abbreviation and a long text for each field group. The abbreviation for a field group can consist of any character that you want. The abbreviation only serves a technical purpose within an InfoSet when fields are being assigned to field groups.
- Choose Continue.
Assigning Fields to a Field Group
You can assign fields of different tables to one field group. In this way, you can treat fields of linked additional tables, additional structures and additional fields in the same way as true logical database fields.
To assign a field to a field group, proceed as follows:
- Click on the field you want to select in the data source.
- Use drag & drop to move the field into the field group of your choice. Or;
- Click on the field and on the field group of your choice.
- Choose the function Add fields to field groups or the relevant function from the context menu.If you want to change the assignment of a field to a field group, click on the field to be changed and move it into the field group you want by using drag & drop, or double-click on the field and use the value help to change the field group in the screen in the bottom right-hand corner.
Double-clicking on a field in the data source or in a field group displays all the technical information for this field in the lower right part of the screen. You can change long texts and headers as and when necessary here.
The assignment between the field and the long text is not always unique, for example when several fields refer to the same data element. Therefore, you can overwrite all the field texts and should in any case always do this in the interests of the end-user.
There is a field header for every field. With fields defined in the ABAP Dictionary, the header text is used. The field headers are needed to determine the column headers for queries. With fields defined in the ABAP Dictionary, you may want to replace the field header with a different text.
Headers can contain up to 30 characters. But they should not contain more characters the field's output length, seeing as these will then be cut off during subsequent display of the query. A ruler is displayed above the header input fields allowing you to see how long your header can be. The output length of the field is also displayed.
If you have currency amount fields or quantity fields in an InfoSet, it is not necessary to include the associated currency or unit fields. The query takes care of the assignment between currency amount and currency fields, or quantity and unit fields it.
You can use the functions Find or Find next to search for a text or technical name in both trees.
Client fields of client-specific tables are not included in the selection offered in the field groups, since cross-client reading is not supported by the query. If the value of the client field is required in special cases, an additional field has to be used. The client field can be accessed in the coding of an additional field, even if the client field is not part of the selection offered.
Deleting Field Groups/Fields from Field Groups
Deleting fields from a field group or an entire field group is easy if you have just created the InfoSet or, at least, not yet used it to define queries.
To delete a field group, place the cursor on the field group in the tree and call Delete field group. Deleting this field group means that the field assignments for this field group are lost.
To delete a single field from a field group, click on the field and choose Delete field.
In the left-hand tree you can select more then one field (with the control or shift button) and remove fields from the field group over the context menu.
If you want to change an InfoSet for which queries have already been defined, you must avoid inconsistencies between the InfoSet and existing queries. Adding individual fields or even entire field groups to the InfoSet of no significance for existing queries. Deleting individual fields or entire field groups means that queries requiring access to them can no longer be processed correctly. Therefore, you can only delete those fields and field groups that are not used in queries.
You can also determine in which queries a field is used. To do this, double-click on the field and choose the function Environment ? Directories ? Queries for field or choose Queries for field in the lower right-hand box. ABAP Query then displays all the user groups and queries that process the selected field.
If you still want to delete either a field from a field group or an entire field group, you must first delete or change all the queries affected by this. Otherwise, the system responds with an error message and refers you to the queries concerned.