Bseg data Reading slow

Question

I have done some programs for g/l balance frm bseg table ,its very slow to retriving records,even i declared proper where  conditions in select query...
advise fast retrive...
any thing like indexing the oracle table ??? or any performance programing ?

Answer 1

This is the final code I get. Try it out:
REPORT ztest MESSAGE-ID zc.
TABLES: bkpf, bseg.
******* new ********
TABLES: t001, ekbe.
******* new ********
DATA: BEGIN OF t_bkpf OCCURS 0.
        INCLUDE STRUCTURE bkpf.
DATA: END   OF t_bkpf.
DATA: BEGIN OF t_bseg OCCURS 0.
        INCLUDE STRUCTURE bseg.
DATA: END   OF t_bseg.
DATA: BEGIN OF t_re OCCURS 0.
        INCLUDE STRUCTURE bseg.
DATA: END   OF t_re.
DATA: BEGIN OF wa_bdc OCCURS 0.
        INCLUDE STRUCTURE bseg.
DATA: END   OF wa_bdc.
******* new ********
DATA: BEGIN OF doc_key OCCURS 0,
        bukrs LIKE bseg-bukrs,
        belnr LIKE bseg-belnr,
        gjahr LIKE bseg-gjahr,
      END   OF doc_key.
DATA: BEGIN OF ir_key OCCURS 0,
        belnr LIKE bseg-belnr,
        gjahr LIKE bseg-gjahr,
      END   OF ir_key.
******* new ********
DATA: p_hkont        LIKE bseg-hkont,
      v_reference    LIKE bkpf-awtyp,                   "REFERENCE KEY
      v_objectkey    LIKE bkpf-awkey.                   "OBJECT KEY
RANGES: p_gjahr  FOR bkpf-gjahr,
        wa_gjahr FOR bkpf-gjahr,
        p_budat  FOR bkpf-budat,
        t_po     FOR bseg-ebeln,
        r_bukrs  FOR t001-bukrs.
******* new ********
r_bukrs-option = 'EQ'.
r_bukrs-sign   = 'I'.
SELECT bukrs FROM t001 INTO r_bukrs-low
  WHERE spras = sy-langu.
  APPEND r_bukrs.
ENDSELECT.
******* new ********
SELECT * FROM bkpf INTO CORRESPONDING FIELDS OF t_bkpf
******* new ********
WHERE bukrs IN r_bukrs AND
      bstat IN (' ', 'A', 'B', 'D', 'M', 'S', 'V', 'W', 'Z') AND
******* new ********
      gjahr IN (p_gjahr, wa_gjahr) AND
      budat IN p_budat AND
      blart EQ 'RE'.
  SELECT * FROM bseg INTO CORRESPONDING FIELDS OF t_bseg
******* new ********
   WHERE bukrs EQ t_bkpf-bukrs AND
******* new ********
         belnr EQ t_bkpf-belnr AND
         gjahr EQ t_bkpf-gjahr AND
         hkont EQ p_hkont AND
         ebeln NE space AND
         augbl EQ space AND
         bschl IN ('86','96','40','50') AND
         bustw EQ 'RE01'.
    t_po-low = t_bseg-ebeln .
    t_po-sign = 'I'.
    t_po-option = 'EQ'.
    APPEND t_po.
    APPEND t_bseg.
    MOVE-CORRESPONDING t_bseg TO t_re.
    APPEND t_re.
  ENDSELECT.
ENDSELECT.
CLEAR t_bseg.
SORT t_po BY low.
DELETE ADJACENT DUPLICATES FROM t_po.
******* new ********
* From the PO history, get the material document for the IR
SELECT belnr gjahr FROM  ekbe
  INTO CORRESPONDING FIELDS OF TABLE ir_key
       WHERE  ebeln  IN t_po
       AND    gjahr  IN p_gjahr
       AND    vgabe  = '2'.
* Now get the accounting document for the material document
LOOP AT ir_key.
  v_objectkey+00(10) = ir_key-belnr.
  v_objectkey+10(10) = ir_key-gjahr. "BELNR+YEAR
  v_reference        = 'MKPF'.
ENDLOOP.
SELECT bukrs belnr gjahr FROM  bkpf
  APPENDING CORRESPONDING FIELDS OF TABLE doc_key
  WHERE  awtyp  = v_reference
  AND    awkey  = v_reference.
******* new ********
SELECT * FROM bseg INTO CORRESPONDING FIELDS OF wa_bdc
  FOR ALL ENTRIES IN doc_key
  WHERE bukrs = doc_key-bukrs AND
        belnr = doc_key-belnr AND
        gjahr = doc_key-gjahr AND
        hkont NE p_hkont AND
        ebeln IN t_po AND
        bschl IN ('89','99','86','96','40','50') AND
        augbl EQ space AND
        bustw EQ 'WE01'.
  MOVE-CORRESPONDING wa_bdc TO t_bseg.
  APPEND t_bseg.
ENDSELECT.
The other suggestions about nested selects, select/endselect, into corresponding, and retrieving only the fields you need are all good. I haven't done this to simplify the coding. I don't think you can use scondary index tables (BSIS and BSAS) because you are checking a not equal condition on HKONT.
There are a lot of other conditions in the selects that I haven't looked at. Maybe they should be done outside of the selects. I don't know. I also haven't looked at the logic
In 4.6C you cannot create an index on a cluster table. Since the database doesn't know the fields in the cluster, I don't see how it could be possible. (Maybe in other RDBMS??) In any event, it's a bad idea to create an index on an SAP table to speed up one report. There is overhead in updating the index each time the table is updated. With a little extra coding, you can almost always find a way to use existing indices.
Rob
I modified the code somewhat. The original code uses p_gjahr as both a select-option and a parameter. I changed it so that it is a select option.
Message was edited by: Rob Burbank