LTAP and LTAK table issue

[Former Member]

Dear ABAPER,

i have used LTAP and LTAK table for inner join , but it will be very slow for data selection and i try to use FOR ALL ENTRIES IN also , it is also same issue.

below my code.

   SELECT ltak~lgnum ltak~tanum ltap~tapos
         ltap~matnr ltap~charg ltap~werks
         ltap~meins ltap~qdatu ltap~qzeit
         ltap~qname ltap~nlpla ltap~nistm
         ltap~lgort ltap~wenum ltap~wepos
                      FROM ltak INNER JOIN ltap
                      ON  ltak~mandt EQ ltap~mandt
                      AND ltak~lgnum EQ ltap~lgnum
                      AND ltak~tanum EQ ltap~tanum
                      INTO TABLE t_ltap
                      WHERE ltak~lgnum EQ lv_lgnum
                      AND ltak~bwart IN ('101' , '321')
                      AND ltak~kquit EQ 'X'
                      AND ltak~queue EQ ''
                      AND ltap~lgnum EQ lv_lgnum
                      AND ltap~werks EQ p_werks
                      AND ltap~bestq EQ ''
                      AND ltap~pquit EQ 'X'
                      AND ltap~qdatu GE s_budat-low
                      AND ltap~nltyp BETWEEN '101' AND '110'
                      %_HINTS ORACLE '&SUBSTITUTE LITERALS&'.

please give sugest me what can be done.

Thanks in advance..

[salah_zinet]

Hi Vellaisamy

Your SELECT is correct, but, I think that :

1) the condition "AND ltap~lgnum EQ lv_lgnum" in WHERE clause is redundant with " ltak~lgnum EQ lv_lgnum", because on the JOIN you have "ltak~lgnum EQ ltap~lgnum".

2) As you have an Index LTAK~Q for the table LTAK you can optimize your WHERE clause by moving the condition "AND ltak~bwart IN ('101' , '321')" after  "AND ltak~kquit EQ 'X'  AND ltak~queue EQ '' ", because the index LTAK~Q is created on fields (MANDT, LGNUM, KQUIT and QUEUE).

Moving the condition   "AND ltap~pquit EQ 'X' " before " AND ltap~werks EQ p_werks AND ltap~bestq EQ ''  "  can optimize your query also (because of Index LTAP~M & LTAP~V on Table LTAP)

Regards.

[Former Member]

You should first run an SQL trace (ST05) to see if the SELECT is using the index or doing a full table scan.

Rob