Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

KONV - alternative selection

vijay_kumar134
Participant
0 Likes
1,324

Hi  Friends,

Please guide me for alternative for following code. Becuase KONV is a cluster table- fetching date for more time.

select knumv
           kposn
           stunr
           zaehk
           kwert
           kschl from konv
                 into table git_konv1
                 for all entries in git_vbrk
                 where knumv = git_vbrk-knumv
                   and kposn = git_vbrk-posnr
                   and kschl = c_jexp.

select knumv
           kposn
           stunr
           zaehk
           kwert
           kschl from konv
                 into table git_konv
                 for all entries in git_vbrk
                 where knumv = git_vbrk-knumv
                   and kposn = git_vbrk-posnr
                   and kschl in (c_znsr , c_zr00 , c_zr01 , c_za03 , c_za04 , c_za05 , c_za06 , c_za10 , c_zscg , c_zstc , c_zrtc ,
                                 c_zptc , c_kf00 , c_zpac , c_z0cd , c_jass , c_zocd ,c_z007 , c_zoth , c_zwhc , c_zwhs ,c_zk01 , c_zk02 ).
                                
Thanks.

Viji.

2 REPLIES 2
Read only

Sijin_Chandran
Active Contributor
0 Likes
935

HI Vijay ,

Why you have  wrote SELECT statements twice for where clause and kschl = c_jexp ?

Instead write a single for both and Process  kschl = c_jexp separately while processing the internal table data in loop . ( Using READ STATEMENT ).

And FOR ALL ENTRIES is the only way for joining a CLUSTER table.

Always try to avoid unnecessary select statements .

Read only

Former Member
0 Likes
935

You are using the two left most key fields of KONV in your selection - KNUMV and KPOSN and also that you are restricting by condition types KSCHL, so the select is already optimized to a good extent. If it is taking time it should be because your selection must also be large in git_vbrk internal table.

If you are only selecting pricing records (and NOT tax conditions) you can also add additional WHERE clause KAPPL = 'V'

Also why are you making two SELECTs? You can merge the first select into the second and later you can filter the JEXP records separately. That is more efficient