SAP DDIC CHARACTER BYTE TYPES Get Example source ABAP code based on a different SAP tableSAP Help
ABAP_DDIC - Character-Like Types and Byte-Like Types ITOC
Character Strings The following built-in dictionary data types 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. For table fields, view fields, and fields of CDS entities, the maximum length is 1333 characters. 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 AB-SQL statements. SSTRING for short text strings The built-in type SSTRING is mapped to the ABAP type string . It is handled like the type CHAR or VARCHAR in ABAP Dictionary and by DDIC database tables. The length is restricted to a maximum of 1333. Table fields of this type can be used as key fields by DDIC database tables and used by AB-SQL statements in almost all positions where text fields are possible. STRING for text strings The built-in dictionary type STRING is mapped to the ABAP type string. It is 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. They cannot be used in all positions in AB-SQL 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 AB_SQL access (see below). Latest 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 AB_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 DDIC database tables or for unrestricted use in AB_SQL . Where possible, SSTRING can be used here instead. Switching existing dictionary objects from LCHR to STRING or SSTRING 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 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. For table fields, the maximum length is 255 characters. 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 AB-SQL statements. RAWSTRING for byte strings The built-in type RAWSTRING is mapped to the ABAP type xstring and it is 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. They cannot be used in all positions in AB-SQL statements. The possible length of a byte 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. This is relevant for AB_SQL access (see below). Latest 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 AB_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, RAWSTRING is also not suitable for key fields of DDIC database tables or for unrestricted use in AB_SQL . Switching existing dictionary objects from LRAW to RAWSTRING 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 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 AB_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 AB_SQL . If it is exceeded, an exception of the class CX_SY_OPEN_SQL_DB is raised. If a string is truncated when read to a target field, no exception is raised. 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 AB_SQL , 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 ABAP_ASINSTANCE , streaming and locators can be used to access long strings. Use in ABAP CDS 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, ABAP_CDS_V1_VIEW ) In CAST expressions (CDS view entity, ABAP_CDS_V1_VIEW ) In comparison expressions cds_cond ( CDS view entity , ABAP_CDS_V1_VIEW ) In string functions (CDS view entity, ABAP_CDS_V1_VIEW ) In CASE expressions (CDS view entity, ABAP_CDS_V1_VIEW ) In aggregate expressions (CDS view entity, ABAP_CDS_V1_VIEW ) For columns merged using UNION: In ABAP_CDS_V1_VIEWS , these data types are generally not supported. In CDS view entities, these data types are not supported if UNION is specified without the addition ALL. UNION ALL, by contrast, supports all data types without any restriction. After GROUP BY (CDS view entity, ABAP_CDS_V1_VIEW ) After SIBLINGS ORDER BY in the statement DEFINE HIERARCHY The data types LCHR and LRAW cannot be used in the following case: For typings The data type RAW can only be used in a small number of operand positions, where this is documented. Latest notes: VARC cannot be used in ABAP CDS. Use in AB_SQL There are no access restrictions to database fields with the data types CHAR and RAW in AB_SQL . Database fields with the data types STRING and RAWSTRING plus LCHR and LRAW cannot be used in the following operand positions: As arguments of aggregate functions and SQL expressions. In the SELECT list when the addition DISTINCT is used. In the SELECT list when the addition FOR ALL ENTRIES is used. In SQL conditions except IS $[NOT$] NULL. In the GROUP BY clause. In the ORDER BY clause. After SIBLINGS ORDER BY in the hierarchy generator. The data type SSTRING can be used without restrictions, except in the coalesce function and in CASE expressions. Latest notes: VARC as to STRING and RAWSTRING plus LCHR and LRAW. Handling in Dynpros 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 properties of a domain.
