Strings are dynamic
data objects of variable length. There are text strings of the
data type and byte strings of the
xstring data type, in which you can store character or byte strings.
In contrast to text and byte fields of a fixed length
x data types), the length of strings automatically
adapts to the content. Other data types, such as
t, are also treated as text fields in many operand positions. Strings are deep data objects that are internally managed by references. For this, the following additional memory is required:
- Strings whose length is less than approximately 30 characters or 60 bytes require between approximately 10 and 40 bytes of additional memory, depending on the string length.
- For longer strings, the additional memory requirement is approximately 50 bytes, irrespective of the string length.
In the case of assignments between strings, sharing takes effect. This means that only the internal reference is copied first. Sharing is canceled if the source or target object is accessed for modification.
Use Strings for Character and Byte String Processing
Use strings rather than fixed length fields for the internal storage and processing of character and byte strings.
Strings are more flexible than fields of a fixed length and usually help you save memory space, because no unnecessary space is occupied by blanks or zeros, and because sharing is implemented for assignments. Furthermore, closing blanks are always significant in text strings. Text fields simply ignore closing blanks in many operand positions (but not in all), which may be quite confusing at times.
In the following cases, fields of a fixed length should be used instead of strings:
- The length of the field is critical, for example, for templates or for interfaces to screen fields.
- Despite sharing, the additional administration work outweighs the benefits which can often be the case for very short strings. If it is obvious that a certain length is never exceeded, you can also use short fields of a fixed length.
- Structures that only contain character-type components are supposed to be treated like a single text field. This is not possible for structures that contain text strings.
The following source code shows an internal table for storing an HTML page whose line type is a text field with a fixed length of 255.
DATA html_table TYPE TABLE OF html_line.
APPEND '<HTML>' TO html_table.
APPEND '<BODY>' TO html_table.
APPEND '</BODY>' TO html_table.
APPEND '</HTML>' TO html_table.
The following source code shows the above example but uses text strings. The memory space gained should outweigh the additional administration effort considerably. As an alternative to using an internal table, you can also concatenate the HTML page in a single text string; however, this impairs the legibility, for example, in the ABAP Debugger.
APPEND `<HTML>` TO html_table.
APPEND `<BODY>` TO html_table.
APPEND `</BODY>` TO html_table.
APPEND `</HTML>` TO html_table.