‎2020 Sep 01 12:52 PM
Hello Experts!
TRY.
ls_tor_item_pred = lt_tor_item_pred[ KEY btd_id
COMPONENTS
btd_id = <ls_tor_item_dlv_tmp>-orig_btd_id
btd_tco = <ls_tor_item_dlv_tmp>-orig_btd_tco
parent_key = <ls_tor_item_dlv_tmp>-key
root_key = <ls_tor_item_dlv_tmp>-root_key
].
CATCH cx_sy_itab_line_not_found.
ENDTRY.
READ TABLE lt_tor_item_pred INTO ls_tor_item_pred WITH KEY btd_id
COMPONENTS
btd_id = <ls_tor_item_dlv_tmp>-orig_btd_id btd_tco = <ls_tor_item_dlv_tmp>-orig_btd_tco parent_key = <ls_tor_item_dlv_tmp>-key
root_key = <ls_tor_item_dlv_tmp>-root_key.
The error which occurs is the following:The component "PARENT_KEY" is not in key "BTD_ID" of table "LT_TOR_ITEM_PRED" or the key is not known statically.The structures secondary keys are:BTD_IDBTD_KEYPARENT_KEYPREDEC_STATUSROOT_KEY<br>
Any idea about why I get an error message within the compiler y using the table expression?
Kind regards,
Pascal
‎2020 Sep 01 1:14 PM
We already had the almost same discussion 😉
1) Your table expression to read a record of the table, is using a search with a specified table key and it always requires the FULL key to be given.
You have to provide all key values with this method, no part of the key can be left out and no further non-key attributes can be included!
ls_tor_item_pred = lt_tor_item_pred[ KEY btd_id COMPONENTS
btd_id = <ls_tor_item_dlv_tmp>-orig_btd_id
btd_tco = <ls_tor_item_dlv_tmp>-orig_btd_tco
parent_key = <ls_tor_item_dlv_tmp>-key
root_key = <ls_tor_item_dlv_tmp>-root_key ].
" equivalent READ TABLE statement (this will also throw the same error as above in your case)
READ TABLE lt_tor_item_pred INTO ls_tor_item_pred WITH TABLE KEY btd_id COMPONENTS
btd_id = <ls_tor_item_dlv_tmp>-orig_btd_id
btd_tco = <ls_tor_item_dlv_tmp>-orig_btd_tco
parent_key = <ls_tor_item_dlv_tmp>-key
root_key = <ls_tor_item_dlv_tmp>-root_key.
2) Your READ TABLE statement is using, a free search key WITH a forced binary search on a complete/partial primary/secondary key. This statement does not have a corresponding table expression.
>> Unlike the statement READ TABLE with a free key specified, no binary searches can be forced for a table expression and it is not possible to specify explicit table key for optimizing searches using secondary keys.
READ TABLE lt_tor_item_pred INTO ls_tor_item_pred WITH KEY btd_id COMPONENTS
btd_id = <ls_tor_item_dlv_tmp>-orig_btd_id
btd_tco = <ls_tor_item_dlv_tmp>-orig_btd_tco
parent_key = <ls_tor_item_dlv_tmp>-key
root_key = <ls_tor_item_dlv_tmp>-root_key.
" no equivalent for table expressions3) Free search key vs. Specified search key
See the following examples to understand the differences in READ TABLE statements. Please be aware, that when a free key overlaps with some or all of the primary table key, the search optimizations are performed when sorted tables and hashed tables are read.
" Free search key (without forcing binary search)
READ TABLE itab WITH KEY comp1 = operand1 ASSIGNING <fs>.
ASSIGN itab[ comp1 = operand1 ] TO <fs>.
" Free search key with explicitly forcing binary search on used components.
" error prone since the table needs to be 'manually' sorted by the used components
READ TABLE itab BINARY SEARCH WITH KEY comp1 = operand1 ASSIGNING <fs>.
" And because it is error prone, there is no equivalent in table expressions
" Free search key with implicetly forcing binary search based on key (primary or secondary)
" error prone since used components dont have to partially/fully match the defined key components
READ TABLE itab WITH KEY key_name COMPONENTS comp1 = operand1 ASSIGNING <fs>.
" And because it is error prone, there is no equivalent in table expressions
" Search by primary table key (the full primary key has to be provided)
READ TABLE itab WITH TABLE KEY comp1 = operand1 ASSIGNING <fs>.
ASSIGN itab[ KEY primary_key COMPONENTS comp1 = operand1] TO <fs>.
" Search by specified table key (primary or secondary, the full key has to be provided)
READ TABLE itab WITH TABLE KEY key_name COMPONENTS comp1 = operand1 ASSIGNING <fs>.
ASSIGN itab[ KEY key_name COMPONENTS comp1 = operand1] TO <fs>.
‎2020 Sep 01 1:14 PM
We already had the almost same discussion 😉
1) Your table expression to read a record of the table, is using a search with a specified table key and it always requires the FULL key to be given.
You have to provide all key values with this method, no part of the key can be left out and no further non-key attributes can be included!
ls_tor_item_pred = lt_tor_item_pred[ KEY btd_id COMPONENTS
btd_id = <ls_tor_item_dlv_tmp>-orig_btd_id
btd_tco = <ls_tor_item_dlv_tmp>-orig_btd_tco
parent_key = <ls_tor_item_dlv_tmp>-key
root_key = <ls_tor_item_dlv_tmp>-root_key ].
" equivalent READ TABLE statement (this will also throw the same error as above in your case)
READ TABLE lt_tor_item_pred INTO ls_tor_item_pred WITH TABLE KEY btd_id COMPONENTS
btd_id = <ls_tor_item_dlv_tmp>-orig_btd_id
btd_tco = <ls_tor_item_dlv_tmp>-orig_btd_tco
parent_key = <ls_tor_item_dlv_tmp>-key
root_key = <ls_tor_item_dlv_tmp>-root_key.
2) Your READ TABLE statement is using, a free search key WITH a forced binary search on a complete/partial primary/secondary key. This statement does not have a corresponding table expression.
>> Unlike the statement READ TABLE with a free key specified, no binary searches can be forced for a table expression and it is not possible to specify explicit table key for optimizing searches using secondary keys.
READ TABLE lt_tor_item_pred INTO ls_tor_item_pred WITH KEY btd_id COMPONENTS
btd_id = <ls_tor_item_dlv_tmp>-orig_btd_id
btd_tco = <ls_tor_item_dlv_tmp>-orig_btd_tco
parent_key = <ls_tor_item_dlv_tmp>-key
root_key = <ls_tor_item_dlv_tmp>-root_key.
" no equivalent for table expressions3) Free search key vs. Specified search key
See the following examples to understand the differences in READ TABLE statements. Please be aware, that when a free key overlaps with some or all of the primary table key, the search optimizations are performed when sorted tables and hashed tables are read.
" Free search key (without forcing binary search)
READ TABLE itab WITH KEY comp1 = operand1 ASSIGNING <fs>.
ASSIGN itab[ comp1 = operand1 ] TO <fs>.
" Free search key with explicitly forcing binary search on used components.
" error prone since the table needs to be 'manually' sorted by the used components
READ TABLE itab BINARY SEARCH WITH KEY comp1 = operand1 ASSIGNING <fs>.
" And because it is error prone, there is no equivalent in table expressions
" Free search key with implicetly forcing binary search based on key (primary or secondary)
" error prone since used components dont have to partially/fully match the defined key components
READ TABLE itab WITH KEY key_name COMPONENTS comp1 = operand1 ASSIGNING <fs>.
" And because it is error prone, there is no equivalent in table expressions
" Search by primary table key (the full primary key has to be provided)
READ TABLE itab WITH TABLE KEY comp1 = operand1 ASSIGNING <fs>.
ASSIGN itab[ KEY primary_key COMPONENTS comp1 = operand1] TO <fs>.
" Search by specified table key (primary or secondary, the full key has to be provided)
READ TABLE itab WITH TABLE KEY key_name COMPONENTS comp1 = operand1 ASSIGNING <fs>.
ASSIGN itab[ KEY key_name COMPONENTS comp1 = operand1] TO <fs>.
‎2020 Sep 01 7:58 PM
Your question is incorrectly formatted: you say that "The structures secondary keys [I guess you mean the components of the secondary key BTD_ID] are: BTD_ID, BTD_KEY, PARENT_KEY, PREDEC_STATUS, ROOT_KEY."
Why do you access the internal table without using PREDEC_STATUS? Don't you think it's the cause of the error?