READ statement comparing CHAR and NUMC fields

[glenn_karlsson2]

Hi,

We are doing an upgrade + unicode conversion project and during testing of a Z-program we noticed a difference due to a SAP standard domain (KOTABNR) that changed data type from NUMC to CHAR. Field is 3 characters long.

The element are used in a Z-table as field COND_TAB. The Z-table that are read into the program as an internal table defined with the same structure as the Z-table. The developer of this program have, for some reason, defined a CHAR4 variable in the program used in a READ statement towards that internal table.

So, the internal table have a field defined as NUMC3 containing the value 304. We are doing a READ statement with operand as 'A304'. So basically like this.

READ TABLE Zxxxx INTO wa WITH KEY COND_TAB = 'A304'.

And in our not yet upgraded production system (where COND_TAB is a NUMC3-field) this READ statement get subrc = 0.

In our upgraded test system the field COND_TAB is now a CHAR3 field after SAP changed KOTABNR domain.

The same READ statement now results in subrc = 4.

So, doing a READ statement using a CHAR4 operand (with value 'A304') get a hit when matched towards a NUMC3 field with value '304', but not a CHAR3 field with the same value '304'.

I did a little test (the program below) in our upgraded system to see if this was due to the upgrade itself but found that it wasn't. The system behaves exactly the same with respect to the CHAR/NUMC-issue even if both versions are tested on the upgraded 740 system.

Can someone explain to me the rational behind this behaviour? Why is A304 equal to 304 when 304 is in a NUMC3 field but not in a CHAR3 field?

best regards,

Glenn

REPORT zxxx.

DATA: lv_var TYPE char4.

lv_var = 'A304'.

** Case 1 - Reading a NUMC3 table field with a CHAR4 operator

TYPES: BEGIN OF ty_test1,
         field1 TYPE char4,
         field2 TYPE numc3,
       END OF ty_test1.

DATA: lt_table1 TYPE TABLE OF ty_test1,
     wa1 TYPE ty_test1.
FIELD-SYMBOLS: <fs1> TYPE ty_test1.

wa1-field1 = 'XXXX'.
wa1-field2 = '304'.
APPEND wa1 TO lt_table1.

READ TABLE lt_table1 ASSIGNING <fs1>
  WITH KEY field2 = lv_var.

IF sy-subrc EQ 0.
  WRITE: /1 'Field symbol 1 assigned'.
ELSE.
  WRITE: /1 'Field symbol 1 not assigned'.
ENDIF.

** Case 2 - Reading a CHAR3 table field with a CHAR4 operator

TYPES: BEGIN OF ty_test2,
         field1 TYPE char4,
         field2 TYPE CHAR3,
       END OF ty_test2.

DATA: lt_table2 TYPE TABLE OF ty_test2,
      wa2 TYPE ty_test2.

FIELD-SYMBOLS: <fs2> TYPE ty_test2.

wa2-field1 = 'XXXX'.
wa2-field2 = '304'.
APPEND wa2 TO lt_table2.

READ TABLE lt_table2 ASSIGNING <fs2>
  WITH KEY field2 = lv_var.

IF sy-subrc EQ 0.
  WRITE: /1 'Field symbol 2 assigned'.
ELSE.
  WRITE: /1 'Field symbol 2 not assigned'.
ENDIF.

[michael_koehler2]

Hi Glenn,

Not sure, but I assume this has something to do with the direction the lv_var is interpreted when compared to a NUMC vs. a CHAR field.

In the 1st case, it seems to compare 3 numbers from right to left, ignoring the non-NUM (and 4th) character. That way it gives you a hit. Not really clean, but a hit nevertheless.

In the second case, the CHAR fields are compared from left to right; which of course gives you a miss.

Hope that comes close. If anyone knows better, please share!
Mike

[Sandra_Rossi]

It's explained in the ABAP documentation:

READ TABLE - free_key: "If necessary, the content of the operands is converted to the data type of the components before the comparison"

The conversion of CHAR 4 ("A304") to NUMC 3 ("304") is explained here:

Conversion Rules for Elementary Data Objects -▶ Source Field Type c -▶ Character-Like Target Fields ...: "The characters in the source field that represent digits are passed right-justified to the target field. Other characters are ignored. If the target field is longer than the number of digits in the source field, it is padded on the left with the character "0". If the target field is shorter, the characters are cut off on the left."

[glenn_karlsson2]

Thanks for the answers.

/Glenn