How to know which field failed read statement?

[teja_va]

Hi,

If we read an internal table with multiple keys and the statement fails to read, how can we know which key failed the statement.

Ex: READ TABLE itab INTO wa_tab

WITH KEY key_1 = X

key_2 = Y

key_3 = Z.

The itab consists of key_1 'X', key_2 'Y' but there is no key_3 'Z'. Hence 3rd key failed the statement.

I know we can look at itab manually comparing the field value (or) we can also know by reading the 3 keys individually.

What if there are 100 keys that cannot be checked manually (or) can't check with 100 Read statements.

Is there any way to know this?

Thanks.

[teja_va]

Hi,

If we read an internal table with multiple keys and the statement fails to read, how can we know which key failed the statement.

Ex: READ TABLE itab INTO wa_tab

WITH KEY key_1 = X

key_2 = Y

key_3 = Z.

The itab consists of key_1 'X', key_2 'Y' but there is no key_3 'Z'. Hence 3rd key failed the statement.

I know we can look at itab manually comparing the field value (or) we can also know by reading the 3 keys individually.

What if there are 100 keys that cannot be checked manually (or) can't check with 100 Read statements.

Is there any way to know this?

Thanks.

[Sandra_Rossi]

No. All manually. But you could create a tool to analyze the correspondence between the contents of the internal table and the values of your key fields.

[Tomas_Buryanek]

If you use table expression, then exception cx_sy_itab_line_not_found will tell you which key failed.

But it will not tell you which component of the key failed.

I am afraid there is no easy way to know which specific component failed in comparison/read.

[Maciej_DomagaBa]

IF your table is SORTED by your key fields - meaning:

- the table is declared as "sorted table";

- or: the table is declared as "standard table" but then its data has been sorted by a "sort" statement - and in this case you perform your "read table" with "binary search" addition

THEN:

when the "read table" statement returns SY-SUBRC <> 0 (meaning: matching record not found) then also SY-TABIX is set by the system to an index in your table where such matching record SHOULD BE LOCATED if it existed (this location is known because the table is sorted).

Now you can read the contents of a record which is located under SY-TABIX (if there is one) and compare: which key fields in that record do not match the values you have requested in the first "read table" statement. You can compare these fields in the same sequence as the sequence of fields you have spcified in the first "read table" statement. The first field that does not match is the one you are looking for.

regards