ABAP New Syntax

[former_member647100]

Hello Experts,

why i get the error message by using the new syntax e.g. when I replaced the statement:

READ TABLE mt_xyz assigning <ls_x> with key test COMPONENTS a = <ls_x>-t.

With:

ASSIGN mt_xyz[ key test COMPONENTS a = <ls_x>-t ] to <ls_x>.

I get the error message that the key is not specified in full in the second (new) statement, but with the old syntax it works without any problems.

BR

[michael_piesche]

You didnt 'replace' the old statement with the corresponding new statement, you changed it to something 'different'. You need to make yourself familar with the ABAP concepts of a "FREE SEARCH KEY" and "SEARCH BY TABLE KEY".

'Unfortunately', the syntax and available functionality for how to make use of a free search key and search by table key has changed from 'old' to 'new', and that is where your troubles might come from. The FREE SEARCH KEY with FORCED BINARY SEARCH based on a key is not available in the new syntax, most likely to avoid the wrong usage of this, in case you are using components wrongly (just the same reason why the statement BINARY SEARCH shouldnt be a first choice any more).

" This would actually 'correspond'

" SEARCH BY TABLE KEY: Using all and only components of the key
" note: this will throw the same syntax errors for old and new version
READ TABLE mt_xyz assigning <ls_x> with TABLE key test COMPONENTS a = <ls_x>-t.
ASSIGN mt_xyz[ key test COMPONENTS a = <ls_x>-t ] to <ls_x>.

" SEARCH BY FREE KEY: Using any components of the table
" this leads in general to a sequential search, 
" and functionality differs between old an new for implictely using other 'available' keys
READ TABLE mt_xyz assigning <ls_x> with key a = <ls_x>-t.
ASSIGN mt_xyz[ a = <ls_x>-t ] to <ls_x>.

" SEARCH BY FREE KEY FORCING BINARY SEARCH: 
" Using any components of the table and forcing a binary search based on a key
READ TABLE mt_xyz assigning <ls_x> with key test COMPONENTS a = <ls_x>-t.
ASSIGN mt_xyz[ ????? ] to <ls_x>. " no equivalent function available

Please use the SAP ABAP documentation when you encounter issues like that, it is really helpful!

>> If the free key overlaps with some or all of the primary table key, the optimizations described under READ TABLE are performed when sorted tables and hashed tables are read.

>> 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.

[former_member647100]

That would mean, that there is no new statement for replacing this coding, correct?

READ TABLE mt_dlv_kl_fu ASSIGNING <ls_dlv_kl_fu> WITH KEY source_key = iv_dlv_key.

And the reason is that the explanation from above:

" This would actually 'correspond'" SEARCH BY TABLE KEY: Using all and only components of the key" note: this will throw the same syntax errors for old and new version

Correct?

Because this will not work:

assign mt_dlv_kl_fu[ key source_key = iv_dlv_key ] to <ls_dlv_kl_fu>.

[michael_piesche]

coding1407

You are mixing the presented cases, your original READ TABLE statement with a free search key AND a forced binary search on a partial key in your question does not have a corresponding (new) table expression, whereas from your above comment the READ TABLE statement with a free search key AND NO forced binary search does a corresponding (new) table expression:

1. The free search key (WITHOUT a forced binary search on a complete/partial primary/secondary key) with READ TABLE has a corresponding table expression:

" READ TABLE itab WITH KEY comp1 = operand1 ASSIGNING <fs>.  -> free search key
READ TABLE mt_dlv_kl_fu ASSIGNING <ls_dlv_kl_fu> WITH KEY source_key = iv_dlv_key.

" ASSIGN itab[ comp1 = operand1 ] TO <fs>.                   -> free search key
ASSIGN mt_dlv_kl_fu[ source_key = iv_dlv_key ] TO <ls_dlv_kl_fu>.

See also the SAP ABAP documentation for table_exp - itab_line syntax:

>> The table expression reads the row in accordance with the specified free search key.
>> The search is performed in exactly the same way as when specifying the free search key comp1 = operand1 comp2 = operand2 ... in the statement READ TABLE.
>> Similarly, the components comp1 comp2 ... can be specified in accordance with the rules from the section Specifying Components.
>> Also, compatible or convertible operands operand1 operand2 ... must be specified that are general expression positions.
>> If the free key overlaps with some or all of the primary table key, the optimizations described under READ TABLE are performed when sorted tables and hashed tables are read.

2. The free search key WITH a forced binary search on a complete/partial primary/secondary key, does not have a corresponding table expression:

READ TABLE itab WITH KEY key_name COMPONENTS comp1 = operand1 ASSIGNING <fs>.
ASSIGN itab[ ????? ] TO <fs>. " no equivalent table expression available

>> 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.

3. The search with a specified table key has a corresponding table expression, and it always requires the FULL key to be given:

" KEY with one component:
" This only works if 'key_name' has only the COMPONENT comp1!
READ TABLE itab WITH TABLE KEY key_name COMPONENTS comp1 = operand1 ASSIGNING <fs>.
ASSIGN itab[ KEY key_name COMPONENTS comp1 = operand1] TO <fs>. 

" KEY with two components:
" This only works if 'key_name' has only the COMPONENTS comp1 and comp2!
READ TABLE itab WITH TABLE KEY key_name COMPONENTS comp1 = operand1 comp2 = operand2 ASSIGNING <fs>.
ASSIGN itab[ KEY key_name COMPONENTS comp1 = operand1 comp2 = operand2 ] TO <fs>. 

>> The table key must be covered completely by specifying component and no components can be specified that are not part of the table key.

[ChrisSolomon]

I could understand one "New Syntax" question....or maybe 2....3 possibly.....but you literally have been spam posting these every day. Maybe a better option for you is to spend time (a lot?) actually working with the syntax (old and new) for a while.....and THEN come back and ask your questions if you have any at that time. Right now, you aren't learning anything.....just having it fed to you....which makes it VERY hard to retain. Just my $0.02.

[Sandra_Rossi]

It's just that statements which are introduced with new ABAP releases may have a stricter check. The Table Expression requires that you indicate the key in full. It's not required with the equivalent syntax of READ TABLE.