Skip to content

ABAP Keyword Documentation →  ABAP - Dictionary →  Built-In Data Types in ABAP Dictionary →  Attributes of the Predefined Dictionary Types →  General Dictionary Types 

Character-Like Types and Byte-Like Types

Other versions: 7.31 | 7.40 | 7.54

Character Strings

The following built-in data types in ABAP Dictionary are available for general character strings:

  • CHAR for text fields
The built-in type CHAR, mapped to the ABAP type c, is used to describe general text fields with a maximum length of 30000 characters (only 1333 characters for table fields, view fields, and fields of CDS entities).
  • LCHR for long text fields
The built-in type LCHR, also mapped to the ABAP type c, is used to describe general text fields with lengths between 256 and 32000 characters. In database tables, the maximum length must be specified as the value of a preceding INT2 or INT4 field. There can only be one table field of type LCHR or LRAW. It must not be a key field and it must be the last table field. It cannot be used in all positions of ABAP SQL statements.
The built-in type SSTRING is mapped to the ABAP type string, but handled like the type CHAR or VARCHAR in ABAP Dictionary and by database tables. The length is restricted to a maximum of 1333, but table fields of this type can also be used as key fields by database tables and used by ABAP SQL statements in almost all positions where text fields are possible.
The built-in type STRING is mapped to the ABAP type string and also handled like a text string (CLOB) in ABAP Dictionary and by database tables. Table fields of this type cannot be used as key fields or index fields in database tables or in any positions in ABAP SQL statements. The possible length of a text string is unrestricted, but a maximum length of 256 can be specified to restrict its length when used for a table field of a database table, which is relevant for ABAP SQL access (see below).


Notes

  • In general structures, the length of a component of type CHAR is not restricted to 1333.

  • In database tables, there can be only one table field of the type LCHR and it must be the last table field. This means that the type LRAW cannot be used simultaneously in the same database table. If the statement SELECT is used to read an LCHR field, the preceding length field must also be read. In writes using ABAP SQL, the length field must be given the correct value or data may be lost.

  • LCHR is no longer recommended for new developments. The type STRING is recommended instead, however it is also not suitable for key fields of database tables or for unrestricted use in ABAP SQL. Where possible, SSTRING can be used here instead.

  • Switching existing dictionary objects from LCHR to STRING or SSTRING, on the other hand, can be critical, since all ABAP types and ABAP objects that reference dictionary objects like this are then given a deep data type. A switch from a flat data type to a deep data type usually constitutes an incompatible change and can produce syntax errors in ABAP programs.

Byte Chains

The following built-in data types in ABAP Dictionary are available for general byte chains:

  • RAW for byte fields
The built-in type RAW, mapped to the ABAP type x, is used to describe byte fields with a maximum length of 32000 characters (only 255 characters for table fields).
  • LRAW for long byte fields
The built-in type LRAW, also mapped to the ABAP type x, is used to describe byte fields with lengths between 256 and 32000 characters. In database tables, the maximum length must be specified as the value of a preceding INT2 or INT4 field. There can only be one table field of type LRAW or LCHR. It must not be a key field and it must be the last table field. It cannot be used in all positions of ABAP SQL statements.
The built-in type RAWSTRING is mapped to the ABAP type xstring and also handled like a byte string (BLOB) in ABAP Dictionary and by database tables. Table fields of this type cannot be used as key fields or index fields in database tables or in any positions in ABAP SQL statements. The possible length of a byte string is unrestricted, but a maximum length of 256 can be specified to restrict its length when used for a table field of a database table, which is relevant for ABAP SQL access (see below).


Notes

  • In general structures, the length of a component of type RAW is not restricted to 255.

  • In database tables, there can be only one table field of the type LRAW and it must be the last table field. This means that the type LCHR cannot be used simultaneously in the same database table. If the statement SELECT is used to read an LRAW field, the preceding length field must also be read. In writes using ABAP SQL, the length field must be given the correct value or data may be lost.

  • LRAW is no longer recommended for new developments. The type RAWSTRING is recommended instead, however it is also not suitable for key fields of database tables or for unrestricted use in ABAP SQL.

  • Switching existing dictionary objects from LRAW to RAWSTRING, on the other hand, can be critical, since all ABAP types and ABAP objects that reference dictionary objects like this are then given a deep data type. A switch from a flat data type to a deep data type usually constitutes an incompatible change and can produce syntax errors in ABAP programs.

Notes on Strings

The following points must be remembered when using built-in data types for text strings or byte strings:

  • The types STRING and RAWSTRING for LOBs have a variable length. A maximum length can be specified, but there is no upper limit. If a maximum length is specified, this represents the actual restriction if used for a table field of a database table.
  • The type SSTRING also has a variable length, but this is restricted upwards by the maximum length that can be specified. The greatest maximum length is 1333. The benefit of using SSTRING, and not CHAR, is that it is assigned to the ABAP type string. Its advantage over STRING is that it can also be used for key fields in databases and in any places in ABAP SQL in which the type CHAR is also possible.
  • The maximum possible length for the types STRING and RAWSTRING and the mandatory maximum length for SSTRING must not be exceeded in writes performed on database fields of these types using ABAP SQL. If it is exceeded, an exception of the class CX_SY_OPEN_SQL_DB is raised. Truncations of strings when read to a target field, however, are ignored.
  • In ABAP programs, maximum lengths defined in ABAP Dictionary for the types STRING, RAWSTRING, and SSTRING are ignored by the assigned ABAP types string and xstring. As a result, writing a string that is too long to a database can raise an exception. If required, the ABAP program itself must handle the length restrictions on strings.
  • The maximum length of data types based on STRING, RAWSTRING, and SSTRING can be identified in an ABAP program using the built-in function dbmaxlen.
  • Trailing blanks are saved in table fields of the type STRING but not in table fields of the type SSTRING. This is particularly significant when short strings are used as key fields of database fields, since trailing blanks cannot be used as distinguishing characteristics here.
  • LOBs of the types STRING and RAWSTRING are usually handled as deep data objects in which only one LOB locator is saved within the data record. This locator references the actual string data. Database fields of the type SSTRING are usually saved as flat fields. An empty long string can also be saved using the null value. The actual handling, however, depends on the individual database system and is not important for ABAP programs.
  • If a work area or an internal table is used to access table fields of the types SSTRING, STRING, or RAWSTRING in ABAP SQL, the work area or the row type of the internal table must be compatible with the database structure.
  • If structures, database tables, or views that have strings as components are used for typings in ABAP, it must be remembered that these objects are deep structures. This means, for example, that they cannot be used in the TABLES statement (obsolete for database accesses) or for typing the obsolete table parameters of procedures.
  • Access may be slower for long strings (LOBs) in database tables than for other data types. If not all data is needed at once (and to bypass any memory limits on the AS Instance), streaming and locators can be used to access long strings.

Use in ABAP CDS

The following restrictions apply in CDS DDL with respect to character-like types and byte-like types:

  • The data types STRING and RAWSTRING plus LCHR and LRAW cannot be used in the following cases:
  • In CAST expressions
  • In CASE expressions
  • For columns merged using UNION
  • The data types LCHR and LRAW cannot be used in the following case:
  • The data type RAW can only be used in a small number of operand positions.


Note

The obsolete data type VARC cannot be used in ABAP CDS.

Use in ABAP SQL

The following restrictions apply when accessing database fields with character-like and byte-like types in ABAP SQL:

  • There are no access restrictions to database fields with the data types CHAR and RAW in ABAP SQL.
  • Database fields with the data types STRING and RAWSTRING plus LCHR and LRAW cannot be used in the following operand positions:
  • The data type SSTRING can be used without restrictions, except in the coalesce function and in CASE expressions.


Note

The same restrictions apply to the obsolete data type VARC as to STRING and RAWSTRING plus LCHR and LRAW.

Handling in Dynpros

When a field with character-like dictionary type is used from a dynpro, lowercase letters are transformed to uppercase letters by default. This behavior can be overridden in Screen Painter. Furthermore, lowercase letters can be preserved for data elements in the semantic attributes of a domain.