Kontakt

Ansicht
Dokumentation

ABENDDIC_CHARACTER_BYTE_TYPES - DDIC CHARACTER BYTE TYPES

ABENDDIC_CHARACTER_BYTE_TYPES - DDIC CHARACTER BYTE TYPES

BAL Application Log Documentation   PERFORM Short Reference  
This documentation is copyright by SAP AG.
SAP E-Book

- Character-Like Types and Byte-Like Types

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 DDIC 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 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 DDIC 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 DDIC database tables and used by 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 DDIC database tables. Table fields of this type cannot be used as key fields or index fields in DDIC database tables or in any positions in statements. The possible length of a text string is unrestricted, but a maximum length of at least 256 can be specified to restrict its length when used for a table field of a DDIC database table, which is relevant for access (see below).

Notes

  • In general DDIC structures, the length of a component of type CHAR is not restricted to 1333.
  • In DDIC 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 , 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 DDIC database tables or for unrestricted use in . 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 DDIC 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 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 DDIC database tables. Table fields of this type cannot be used as key fields or index fields in DDIC database tables or in any positions in 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 DDIC database table, which is relevant for access (see below).

Notes

  • In general DDIC structures, the length of a component of type RAW is not restricted to 255.
  • In DDIC 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 , 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 DDIC database tables or for unrestricted use in .
  • 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 DDIC 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 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 . 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 , the work area or the line type of the internal table must be compatible with the database structure.
  • If DDIC structures, DDIC database tables, or DDIC 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 DDIC database tables than for other data types. If not all data is needed at once (and to bypass any memory limits on the ), 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 the SELECT list if the addition DISTINCT is specified (CDS view entity, )

  • For columns merged using UNION (currently only available in )

  • 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

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

  • There are no access restrictions to database fields with the data types CHAR and RAW in .
  • Database fields with the data types STRING and RAWSTRING plus LCHR and LRAW cannot be used in the following operand positions:

  • In the SELECT list when the addition FOR ALL ENTRIES is used In the strict mode from Release, this produces a syntax error. Otherwise, the extended program check produces a syntax warning that can be hidden by a pragma.

  • 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.






Fill RESBD Structure from EBP Component Structure   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
This documentation is copyright by SAP AG.

Length: 19169 Date: 20240424 Time: 115450     sap01-206 ( 232 ms )