Skip to Content

READ statement comparing CHAR and NUMC fields

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.
Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • Best Answer
    Posted on Oct 29, 2019 at 07:42 PM

    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 -▶ N: "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."

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Oct 29, 2019 at 07:21 PM

    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

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Nov 06, 2019 at 01:28 PM

    Thanks for the answers.

    /Glenn

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.