ABAP Keyword Documentation → ABAP Programming Guidelines → Robust ABAP → Assignments, Calculations, and Other Types of Data Access
Avoiding Invalid Values
Other versions: 7.31 | 7.40 | 7.54
Background
For performance reasons, the ABAP runtime environment does not check whether the target field contains
a valid value after each and every assignment. In particular for target fields of data types n,
d, and t, the conversion rules allow any alphanumeric values as the result of an assignment. However, only the following values are valid:
- For type
n: numbers only
- For type
d: a calendar date in the format "YYYYMMDD"
- For type
t: a time in the format "HHMMSS"
Note the following unfortunate situation: The initial value of the data type d
(00000000) is itself an invalid date; when the number 0 is converted to data type d, this initial value
is generated, not the zero point of date calculations, which is the value 00010101. In date calculations,
all numbers with a value of 1 or above are interpreted as the number of days since 01.01.0001. Therefore,
if the date 01.01.0001 is converted to a number, you get a value of 0, but if 0 is converted to a date, you do not get 01.01.0001.
You can force a check on valid values by using the EXACT addition for the MOVE statement.
Rule
Only assign valid values
In assignments and calculations, you fill data objects with data types n, d, and t with valid values only.
Details
Statements that work with variables with types n, d,
or t can only be guaranteed to behave correctly if values are valid. Since
the initial value for variables of type d is itself not a valid value, you must always use the addition VALUE to set a suitable start value.
Note that in arithmetic calculations with date fields, if an assignment to a target field with data
type d has 0 as a result value, this is an invalid initial value and may require special treatment.
If you do not have control over the filling of data objects of these critical data types, and a program can cope with any performance losses, we recommend checking that the content of the data objects is valid before using them.
Note
We recommend that you use time stamps, which force valid values, to achieve maximum security handling
of date/time fields and calculations based on these fields. Use the CONVERT DATE
and CONVERT TIME STAMP statements to convert values. For calculations, use
the CL_ABAP_TSTMP class. You can use the EXACT addition for the MOVE
statement to ensure that fields with types n, d,
or t are only filled with valid values. Note that the initial value for MOVE EXACT is interpreted as valid and the value "00010101" as invalid.
Bad Example
The following source code shows a case where the conversion rules in ABAP can lead to problems if not thought through. The literals can be transferred to the date fields, without triggering an exception, to give the values 07092009 und 16092009. Unfortunately, these are interpreted as 09.20.0709 and 09.20.1609, which are invalid dates. During the calculation, they are both converted to the value 0 and the result is 0. Looking at the dates, you would expect the result to be 9.
date2 TYPE d,
result TYPE i.
date1 = '07092009'.
date2 = '16092009'.
result = date2 - date1.
Good Example
The following source code shows a date calculation that does give the expected result of 9, thanks to valid values in the date fields.
date2 TYPE d,
result TYPE i.
date1 = '20090907'.
date2 = '20090916'.
result = date2 - date1.
The following source code shows how you can force valid values for the date fields before the calculation, if they are filled in the same program.
MOVE EXACT '07092009' TO date1.
MOVE EXACT '16092009' TO date2.
result = date2 - date1.
CATCH cx_sy_conversion_no_date.
...
ENDTRY.
The following source code shows how you can check whether the date fields are valid before the calculation, if they are not filled in the same program.
IF date1 <> 0 AND date2 <> 0.
result = date2 - date1.
ELSE.
...
ENDIF.
An assignment using MOVE EXACT from date1 and
date2 to help variables of type d would not result
in a error, because no check is performed when the types are compatible. You would have to insert text fields as help variables:
DATA cdate2 TYPE c LENGTH 8.
cdate1 = date1.
cdate2 = date2.
TRY.
MOVE EXACT cdate1 TO date1.
MOVE EXACT cdate2 TO date2.
result = date2 - date1.
CATCH cx_sy_conversion_no_date.
...
ENDTRY.