What does it do? Type adjustment in AB_SQL . A cast expression converts> the value of the operand sql_exp > to the dictionary type specified by dtype>. SQL expressions, which have a type that matches dtype> as shown below, can be used as an operand sql_exp>. The result is a representation of the source value in type dtype>. Built-in data types> in the ABAP Dictionary with the following syntax can be specified for dtype >:
Numeric types
INT1>
INT2>
INT4>
INT8>
DEC$[( len$[, decimals$] )$]>
D16N> for DECFLOAT16>
D34N> for DECFLOAT34>
FLTP>
Character-like types
CHAR$[( len )$]>
SSTRING$[( len )$]>
Byte-like types
RAW $[( len )$]>
Date types/time types
DATS>
TIMS>
DATN>
TIMN>
UTCL> for UTCLONG>
Character-like types with special semantics
NUMC$[( len )$]>
CLNT>
LANG>
Currency fields and quantity fields
CURR$[( len$[, decimals$] )$]>
CUKY>
QUAN$[( len$[, decimals$] )$]>
UNIT( 2$|3 )> len> and decimals> can be used to specify lengths and decimal places for those dictionary types that have variable lengths and decimal places. Literals> or host constants> of the ABAP type> b>, s>, i >, or int8> can be specified for len> and decimals>. If no lengths or decimal places are specified for these types, these values are taken from the result of the specified SQL expression sql_exp>. In both cases, the lengths and decimal places must meet the requirements of the following table. If the operand NULL> is cast, the length of dictionary types that have a variable length must be specified. The following table shows which combinations of built-in data types in the ABAP Dictionary can currently be cast to each other and the corresponding prerequisites. There is a special list of conversion rules> for every combination. from/to>INT1>>INT2>>INT4> >INT8>>DEC>>CURR>>QUAN>>DECFLOAT16>>DECFLOAT34>> FLTP>>CHAR>>SSTRING>>NUMC>>DATS>>TIMS>>DATN> >TIMN>>UTCLONG>>CLNT>> LANG>>UNIT>>CUKY>>RAW>> INT1>> xxxxxxxxxxzz----------- INT2>> xxxxxxxxxxzz----------- INT4>> xxxxxxxxxxzz----------- INT8>> xxxxxxxxxxzz----------- DEC>> xxxxxxxxxxzz----------- CURR>> xxxxxxxxxxzz----------- QUAN>> xxxxxxxxxxzz----------- DECFLOAT16>> xxxxxxxxxxzz----------- DECFLOAT34>> xxxxxxxxxxzz----------- DF16_DEC>> xxxx---xxx------------- DF34_DEC>> xxxx---xxx------------- FLTP>> xxxxxxxxxxzz----------- CHAR>> xxxxxxxxxxxxyyy---yycy- SSTRING>> xxxxxxxxxxxxyyy---yycy- NUMC>> xxxxxxxxxxyyyyy---y---- DATS>> xxxxxxxxxxxxyx-x------- TIMS>> xxxxxxxxxxxxy-x-x------ DATN>> -------------x-x------- TIMN>> --------------x-x------ UTCLONG>> -----------------x----- CLNT>> ----------xxy-----x---- LANG>> ----------xx-------x--- UNIT>> ----------xx--------x-- CUKY>> ----------xx---------x- RAW>> ----------------------c There are no further restrictions for combinations using x >. The following prerequisites apply to the other combinations:
For combinations with y>, the initial length cannot be less than the target length.
For combinations with z>, the target length must be sufficient to represent the value in the source.
For combinations with c>, the initial length and target length must be equal. These prerequisites are checked by the ABAP SQL parser. In the case of incompatible types, the content of the operand is converted> to the target type. Exceptions can be raised if values are not suitable. If the operand of the expression has the null value>, the result of the expression is also the null value.
Latest notes:
Specifying a cast expression always means specifying an SQL expression>. Cast expressions can only be specified for operand positions in which SQL expressions are possible.
Type modifications can be used in operand positions of AB-SQL statements to convert operands without a suitable type to an operand with a suitable type.
CAST> expressions are platform-independent with one exception: For conversions from the type FLTP> to other numeric types the result is platform-dependent.
For conversions from the type FLTP> to other types, rounding errors might occur. For conversions to character types depending on the value either the mathematical> or scientific notation> is generated and the case of the exponent character is not fixed. Converting back such a character representation to a floating data type always produces the original value.
For the missing combinations of type modifications that cannot be covered by a CAST> expression, construction operators such as CONV> can be used in host expressions>, at least for literals and host variables. There are also built-in conversion functions> for special conversions:
BINTOHEX>> and HEXTOBIN>> for conversions of byte strings to character strings and vice versa.
A cast expression cannot be evaluated in the table buffer> and always causes table buffering> to be bypassed. NON_V5_HINTS
If SQL expressions other than operands are used in a cast expression or if a data type other than FLTP> is specified as dtype>, the syntax check is performed in ABAP_STRICT_761 strict mode from ABAP_RELEASE ABAP_761 / . This mode handles the statement more strictly than the regular syntax check.
If INT8> is specified as dtype> in a cast expression, the syntax check is performed in a ABAP_STRICT_762 strict mode from ABAP_RELEASE ABAP_762 / , which handles the statement more strictly than the regular syntax check. If used, D16N> or D34N> apply ABAP_STRICT_777 strict mode of the syntax check from ABAP_RELEASE ABAP_777 / . ABAP_HINT_END
ABAP_EXAMPLE_VX5 The following SELECT> list> splits a time stamp in a packed number> into its date part and its time part. This requires multiple CAST> expressions to create a suitable type in every operand position. ABEXA 01267 ABAP_EXAMPLE_END