For all entries changes the order of the itab

Hi Experts
             In the following query i have used two internal tables namely it_first and it_zlist.
            The material inwhich the it_zlist is different sorting order
      After executing this query, the order of the material inwhich the it_first is different from the it_zlist.
             What could be the reason, pls explain me on this.
select matnr test zsno ztnam from zmaster1
            into corresponding fields of table it_first
                  for all entries in it_zlist
                  where matnr = it_zlist-matnr.
Thanks in advance.
Regards
Rajaram

for all entries u should specified all primary key.
sort by u condition.
Effect
If the addition FOR ALL ENTRIES is specified before the language element WHERE, then the components comp of the internal table itab can be used as operands when comparing with relational operators.
The internal table itab must have a structured line type and the component comp must be compatible with the column col.
The logical expression sql_cond of the WHERE condition can comprise various logical expressions by using AND and OR. However, if FOR ALL ENTRIES is specified, there must be at least one Comparison with a column of the internal table itab, which can be specified either statistically or dynamically (Release 6.40 and higher). In a statement with a SELECTstatement with FOR ALL ENTRIES, the addition ORDER BY can only be used with the addition PRIMARY KEY.
The whole logical expression sql_cond is evaluated for each individual line of the internal table itab. The resulting set of the SELECT statement is the union of the resulting sets from the individual evaluations. Duplicate lines are automatically removed from the resulting set. If the internal table itab is empty, the whole WHERE statement is ignored and all lines in the database are put in the resulting set.
Notes
In Release 6.10 and higher, the same internal table can be specified after FOR ALL ENTRIES and after INTO.
The addition FOR ALL ENTRIES is only possible before WHERE conditions of the SELECT statement.
If the additions PACKAGE SIZE or UP TO n ROWS are specified together with FOR ALL ENTRIES, they are not passed to the database system but are applied instead to the resulting set once all selected rows on the application server have been imported.
With duplicated rows in the resulting set, the addition FOR ALL ENTRIES has the same effect as if addition DISTINCT were specified in the definition of the selection quantity. Unlike DISTINCT, the rows are not deleted from the database system but are deleted on the application server from the resulting set.
Addition FOR ALL ENTRIES is only possible for WHERE conditions of the SELECT statement.
Example
Exporting all flight data for a specified departure city. The relevant airlines and flight numbers are first put in an internal table entry_tab, which is evaluated in the WHERE condition of the subsquent SELECT statement.

Similar Messages

  • For all entries : lines are missing in the results

    Hi all,
    I have a problem with my abap code.
    some lines are missing in the results.
    I have check the note 65554 but i use the version 6.40
    TYPES: BEGIN OF wys_bseg,
             bukrs TYPE bsad-bukrs,
             belnr TYPE bsad-belnr,
             gjahr TYPE bsad-gjahr,
             augbl TYPE bseg-augbl,
             augdt type bseg-augdt,
             hkont TYPE bseg-hkont,
             WRBTR type bseg-WRBTR,
             KOART type bseg-KOART,
             SHKZG type bseg-SHKZG,
           END OF wys_bseg.
    TYPES: begin of wys_bsas,
             bukrs TYPE bsas-bukrs,
             hkont TYPE bsas-hkont,
             augbl TYPE bsas-augbl,
             augdt type bseg-augdt,
             gjahr TYPE bsas-gjahr,
             belnr TYPE bsas-belnr,
             waers TYPE bsas-waers,
             blart TYPE bsas-blart,
             gsber TYPE bsas-gsber,
             dmbtr TYPE bsas-dmbtr,
             xblnr TYPE bsas-xblnr,
             SHKZG type bseg-SHKZG,
             zmntfact TYPE bsas-WRBTR,
           end of wys_bsas.
    DATA: wt_bseg_tmp TYPE wys_bseg OCCURS 0 WITH HEADER LINE.
    DATA : wt_bsas type wys_bsas occurs 0 WITH HEADER LINE.
        sort wt_bsas by bukrs belnr gjahr.
        DELETE ADJACENT DUPLICATES FROM wt_bsas COMPARING bukrs belnr gjahr.
    IF NOT wt_bsas[] IS INITIAL.
        select bukrs belnr gjahr augbl augdt hkont WRBTR KOART SHKZG from
    bseg into table wt_bseg_tmp
                  for all entries in wt_bsas
                  where bukrs EQ wt_bsas-bukrs
                    and belnr EQ wt_bsas-belnr
                    and gjahr EQ wt_bsas-gjahr
                    and koart EQ 'D'.
    ENDIF.

    Hi
    Yes Arun is right, INTO TABLE option delete automatically the duplicates lines, so you make sure to insert all keys in order to load all record.
    Insert the field BUZEI in the structure of internal table:
    TYPES: BEGIN OF wys_bseg,
             bukrs TYPE bsad-bukrs,
             belnr TYPE bsad-belnr,
             gjahr TYPE bsad-gjahr,
             buzei type bseg-buzei, <------ New field
             augbl TYPE bseg-augbl,
             augdt type bseg-augdt,
             hkont TYPE bseg-hkont,
             WRBTR type bseg-WRBTR,
             KOART type bseg-KOART,
             SHKZG type bseg-SHKZG,
           END OF wys_bseg.
    Max

  • What is the condition for using 'for all entries' and  why?

    what is the condition for using 'for all entries' and  why? can any body tell the reason for this ? its a big favour of me .
    regards,
    ravi.

    hi,
    for all entries is used to join two or more tables.
    It is same as join but performance wise for all entries is more effective.
    You can only use FOR ALL ENTRIES IN ...WHERE ...in a SELECT statement.
    SELECT ... FOR ALL ENTRIES IN itab WHERE cond returns the union of the solution sets of all SELECT
    statements that would result if you wrote a separate statement for each line of the internal table replacing the symbol
    itab-f with the corresponding value of component f in the WHERE condition.Duplicates are discarded from the result
    set. If the internal table itab does not contain any entries, the system treats the statement as though there were
    no WHERE cond condition, and selects all records (in the current client).
    for example:
    SELECT * FROM sflight INTO wa_sflight
    FOR ALL ENTRIES IN ftab
    WHERE CARRID = ftab-carrid AND
    CONNID = ftab-connid AND
    fldate = '20010228'.
    this condition, return all entries of the sflight
    hen using FOR ALL ENTRIES the number of matching records is restricted to the number of records in the internal table. If the number of records in the database tables is too large then join would cause overheads in performance. Additionally a JOIN bypasses the table buffering.
    So for all entries is used for filtering out the data from the two tables based on the entries in them.
    Advantages:
    1) For all entries avoids inner join & so the performance increases.
    2) For specified values in 1 itab, if you to fetch values from other table you can use it.
    3) Use of select stmt in loop is gets avoided, as u can use read statement on the the new itab.

  • For all entries with large sets

    Hello All,
    Does for all entries have restriction that the itab should not exceed the maximum entries? Look at code below:
      select pernr raufpl raplzl catshours
             from catsdb
             into corresponding fields of table lit_catshrs
             for all entries in itab
             where pernr = itab-pernr
               and status in ('10', '20', '30')
               and workdate in s_date.
    if itab have 7000 entries in production system, will the select statement cause a short dump such as DBIF_RSQL_INVALID_RSQL?
    Thanks,
    Alex M

    Hi,
    check the sequence of the fields in the internal table lit_catshrs
    Because RSQL error occurs because of this.
    and Whenevr you use for all entries of some Internal Table it is a must to check that
    IF not ITAB[] Is initial.
    < write the select>
    endif.
    Other performance related thing w.r.t to ABAP are
    1) Dont use nested seelct statement
    2) If possible use for all entries in addition
    3) In the where addition make sure you give all the primary key
    4) Use Index for the selection criteria.
    5) You can also use inner joins
    6) You can try to put the data from the first select statement into an Itab and then in order to select the data from the second table use for all entries in.
    7) Use the runtime analysis SE30 and SQL Trace (ST05) to identify the performance and also to identify where the load is heavy, so that you can change the code accordingly
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5d0db4c9-0e01-0010-b68f-9b1408d5f234
    reward if useful
    regards,
    Anji

  • Question about statement for all entries

    Hi Abap experts,
    I have a question concerning the ABAP statement for all entries.
    Explanations:
    Let’s say that my source package (Source table) contains 2 types of data:
    -type1
    -type2
    I would like to use the statement select from table into internal table
    For all entries in source package
    But the where statement changes depending on the data type (2 keys when data type is 1 and only 1 key when data type is 2) .
    So that would be:
    Type1:
    Select fields
    From table into internal table
    Where field1 = source_package-field1
    And field2 = source_package-field2.
    Type2:
    Select fields
    From table into internal table
    Where field1 = source_package-field1
    How can I merge them assming that the field od data type is ftype?
    Thanks.
    Amine

    Hi amine,
    i think this is helpful for you.
    there are 2 ways  to use the for all entries...
    1. with header line:  this method is old one. in this method the internal table (ITAB) is automatically create workarea (WA) with same name, this method 1 drawback is there where we can use WA and ITAB confused that's why this is come difficult.
    2. without header line : this is nowadays we can use this method. in this method we create separate ITAb and WA. very clear this method.
    EXAMPLES:
    1.WITH HEADER LINE METHOD:
    PARAMETERS p_kunnr TYPE kna1-kunnr.
    DATA:it_kna1 LIKE kna1 OCCURS 0 WITH HEADER LINE,
          it_adrc LIKE adrc OCCURS 0 WITH HEADER LINE,
          it_adr2 LIKE adr2 OCCURS 0 WITH HEADER LINE,
          it_adr6 LIKE adr6 OCCURS 0 WITH HEADER LINE.
    START-OF-SELECTION.
       SELECT * FROM kna1 INTO TABLE it_kna1
          UP TO 100 ROWS.
       IF NOT it_kna1[] IS INITIAL.
         SELECT * FROM adrc INTO TABLE it_adrc
         FOR ALL ENTRIES IN it_kna1
         WHERE addrnumber = it_kna1-adrnr.
       ENDIF.
       IF NOT it_adrc[] IS INITIAL.
         SELECT * FROM adr2 INTO TABLE it_adr2
         FOR ALL ENTRIES IN it_adrc
         WHERE  addrnumber = it_adrc-addrnumber.
       ENDIF.
       IF NOT it_adr2[] IS INITIAL.
         SELECT * FROM adr6 INTO TABLE it_adr6
         FOR ALL ENTRIES IN it_adr2
         WHERE  addrnumber = it_adr2-addrnumber.
       ENDIF.
       LOOP AT it_kna1.
         READ TABLE it_adrc WITH KEY addrnumber = it_kna1-adrnr.
         IF sy-subrc = 0.
         ENDIF.
         READ TABLE it_adr2 WITH KEY addrnumber = it_kna1-adrnr.
         IF sy-subrc = 0.
         ENDIF.
         READ TABLE it_adr6 WITH KEY addrnumber = it_kna1-adrnr.
         IF sy-subrc = 0.
         ENDIF.
         WRITE : it_kna1-kunnr, it_kna1-name1, it_adrc-city1, it_adrc-street, it_adrc-po_box_reg,
                      it_adr2-telnr_long, it_adr6-smtp_addr.
       ENDLOOP.
    2. WITH OUT HEADER LINE:
    TABLES: KNA1 , ADRC.
    DATA : IT_KNA1 TYPE STANDARD TABLE OF KNA1,
            IT_ADRC TYPE STANDARD TABLE OF ADRC,
            WA_KNA1 TYPE KNA1,
            WA_ADRC TYPE ADRC.
    DATA: BEGIN OF STRTYPE ,
           CUSTMERNO LIKE KNA1-KUNNR,
           FIRSTNAME LIKE KNA1-NAME1,
           LASTNAME  TYPE NAME2,
           CITY TYPE ORT01,
           STATE TYPE REGIO,
           COUNTRY TYPE LAND1,
           ADDRESS LIKE ADRC-ADDRNUMBER,
           END OF STRTYPE.
    DATA : IT_1 LIKE TABLE OF STRTYPE.
    SELECT-OPTIONS  K_kunnr FOR kna1-kunnr NO-EXTENSION.
    SELECT * FROM KNA1 INTO TABLE IT_KNA1 WHERE KUNNR IN K_KUNNR.
    IF NOT IT_KNA1[] IS INITIAL.
    SELECT * FROM ADRC INTO WA_ADRC FOR ALL ENTRIES IN IT_KNA1 WHERE ADDRNUMBER = IT_KNA1-ADRNR.
    ENDSELECT.
    ENDIF.
    LOOP AT IT_KNA1 INTO WA_KNA1.
       READ TABLE IT_ADRC INTO WA_ADRC WITH KEY ADDRNUMBER = WA_KNA1-ADRNR.
       IF SY-SUBRC = 0.
           STRTYPE-ADDRESS = WA_ADRC-ADDRNUMBER.
       ENDIF.
    APPEND  STRTYPE TO IT_1.
       WRITE : / WA_KNA1-KUNNR, WA_KNA1-NAME1, WA_KNA1-NAME2, WA_KNA1-ORT01, WA_KNA1-REGIO, WA_KNA1-LAND1, WA_ADRC-ADDRNUMBER.
    ENDLOOP.
    regards,
    roopa.k

  • For All Entries with two tables

    Hi All,
             Can we use FOR ALL ENTRIES with two tables. for example
    SELECT * FROM MKPF INTO TABLE T_MKPF
             WHERE BUDAT IN S_BUDAT.
    SELECT * FROM MARA INTO TABLE T_MARA
             WHERE MTART IN S_MTART AND
                            MAKTL IN S_MAKTL.
    SELECT * FROM MSEG INTO TABLE T_MSEG
           FOR ALL ENTRIES IN  "T_MKPF AND T_MARA"
                  WHERE MBLNR EQ T_MKPF-MBLNR AND
                                 MATNR EQ T_MARA-MATNR.
    can we do it like this or any other way to do this plz tell. I waitting for your responce.
    Thanks
    Jitendra

    Hi,
    u cannot do like this....chek some documentation on it..
    1. duplicate rows are automatically removed
    2. if the itab used in the clause is empty , all the rows in the source table will be selected .
    3. performance degradation when using the clause on big tables.
    Say for example you have the following abap code:
    Select * from mara
    For all entries in itab
    Where matnr = itab-matnr.
    If the actual source of the material list (represented here by itab) is actually another database table, like:
    select matnr from mseg
    into corresponding fields of table itab
    where ….
    Then you could have used one sql statement that joins both tables.
    Select t1.*
    From mara t1, mseg t2
    Where t1.matnr = t2.matnr
    And T2…..
    So what are the drawbacks of using the "for all entires" instead of a join ?
    At run time , in order to fulfill the "for all entries " request, the abap engine will generate several sql statements (for detailed information on this refer to note 48230). Regardless of which method the engine uses (union all, "or" or "in" predicates) If the itab is bigger then a few records, the abap engine will break the itab into parts, and rerun an sql statement several times in a loop. This rerun of the same sql statement , each time with different host values, is a source of resource waste because it may lead to re-reading of data pages.
    returing to the above example , lets say that our itab contains 500 records and that the abap engine will be forced to run the following sql statement 50 times with a list of 10 values each time.
    Select * from mara
    Where matnr in ( ...)
    Db2 will be able to perform this sql statement cheaply all 50 times, using one of sap standard indexes that contain the matnr column. But in actuality, if you consider the wider picture (all 50 executions of the statement), you will see that some of the data pages, especially the root and middle-tire index pages have been re-read each execution.
    Even though db2 has mechanisms like buffer pools and sequential detection to try to minimize the i/o cost of such cases, those mechanisms can only minimize the actual i/o operations , not the cpu cost of re-reading them once they are in memory. Had you coded the join, db2 would have known that you actually need 500 rows from mara, it would have been able to use other access methods, and potentially consume less getpages i/o and cpu.
    In other words , when you use the "for all entries " clause instead of coding a join , you are depriving the database of important information needed to select the best access path for your application. Moreover, you are depriving your DBA of the same vital information. When the DBA monitors & tunes the system, he (or she) is less likely to recognize this kind of resource waste. The DBA will see a simple statement that uses an index , he is less likely to realize that this statement is executed in a loop unnecessarily.
    Beore using the "for all entries" clause and to evaluate the use of database views as a means to:
    a. simplify sql
    b. simplify abap code
    c. get around open sql limitations.
    check the links
    http://www.thespot4sap.com/articles/SAPABAPPerformanceTuning_ForAllEntries.asp
    The specified item was not found.
    Regards,
    Nagaraj

  • Select query like For all Entries

    Hi,
    I have a requirement like:
    I need to extract data (BKTXT) from table BKPF based on some criteria, into one internal table and I need to query on REGUP table for the above data, the selection criteria on REGUP as follows:
    BKTXT(Document Header Text with 25 Char) is a combination of DATE and character string.
    Ex: bkpf-bktxt = 20060710-PL02 (YYYYMMDD)
    it is like LAUFD + LAUFI (of table REGUP)
    i.e: LAUFD (REGUP) = 07/10/2006 (MM/DD/YYYY) and LAUFI(REGUP) = PL02
    here I am thinking to use a select query on REGUP using FOR ALL ENTRIES of table i_bkpf..
    How can I change the date format YYYYMMDD to MM/DD/YYYY for my requirement?
    ((    Run-on Date (REGUP-LAUFD) = the first 8 characters in the Document Header Text (BKPF- BKTXT) in MM/DD/YYYY date format (e.g. 07/10/2006)
       Run ID (REGUP-LAUFI) = the 10th character through the 15th character in the Document Header Text (BKPF- BKTXT)

    It is not possible to do in the way you are thinking of doing. "For all entries" requires you to have the itab table field and the database table field to have the same type and length. So something like below <u>will not work</u>.
    TABLES: regup.
    DATA: BEGIN OF itab OCCURS 0,
            text LIKE bkpf-bktxt.
    DATA: END OF itab.
    DATA: BEGIN OF itab_regup OCCURS 0.
            INCLUDE STRUCTURE regup.
    DATA: END OF itab_regup.
    SELECT * INTO TABLE itab_regup
             FROM regup FOR ALL ENTRIES IN itab
            WHERE laufd = itab-text+0(8).
    If you run this code, you will get an error as follows:
    <i>"When using the addition "FOR ALL ENTRIES IN itab", the fields "LAUFD" and "ITAB-TEXT+0(8)" must have the same type and length."</i>

  • Driver table in select for all entries

    anyone please let me what is driver table in select for all entries and when do we go for select for all entries

    Here is something from help
    FOR ALL ENTRIES WHERE
    Syntax
    ... FOR ALL ENTRIES IN itab WHERE ... col operator itab-comp ...
    Effect
    If the addition FOR ALL ENTRIES is specified before the language element WHERE, then the components comp of the internal table itab can be used as operands when comparing with relational operators.
    The internal table itab must have a structured line type and the component comp must be compatible with the column col.
    The logical expression sql_cond of the WHERE condition can comprise various logical expressions by using AND and OR. However, if FOR ALL ENTRIES is specified, there must be at least one Comparison with a column of the internal table itab, which can be specified either statistically or dynamically (Release 6.40 and higher). In a statement with a SELECTstatement with FOR ALL ENTRIES, the addition ORDER BY can only be used with the addition PRIMARY KEY.
    The whole logical expression sql_cond is evaluated for each individual line of the internal table itab. The resulting set of the SELECT statement is the union of the resulting sets from the individual evaluations. Duplicate lines are automatically removed from the resulting set. If the internal table itab is empty, the whole WHERE statement is ignored and all lines in the database are put in the resulting set.
    Notes
    In Release 6.10 and higher, the same internal table can be specified after FOR ALL ENTRIES and after INTO.
    The addition FOR ALL ENTRIES is only possible before WHERE conditions of the SELECT statement.
    Example
    Exporting all flight data for a specified departure city. The relevant airlines and flight numbers are first put in an internal table entry_tab, which is evaluated in the WHERE condition of the subsquent SELECT statement.
    PARAMETERS p_city TYPE spfli-cityfrom.
    TYPES: BEGIN OF entry_tab_type,
             carrid TYPE spfli-carrid,
             connid TYPE spfli-connid,
           END OF entry_tab_type.
    DATA: entry_tab   TYPE TABLE OF entry_tab_type,
          sflight_tab TYPE SORTED TABLE OF sflight
                           WITH UNIQUE KEY carrid connid fldate.
    SELECT carrid connid
           FROM spfli
           INTO CORRESPONDING FIELDS OF TABLE entry_tab
           WHERE cityfrom = p_city.
    SELECT carrid connid fldate
           FROM sflight
           INTO CORRESPONDING FIELDS OF TABLE sflight_tab
           FOR ALL ENTRIES IN entry_tab
           WHERE carrid = entry_tab-carrid AND
                 connid = entry_tab-connid.
    Regards,
    Santosh

  • FOR ALL ENTRIES IN Memory Dump Issue

    We have a "TSV_TNEW_BLOCKS_NO_ROLL_MEMORY" dump that is confusing me.  The dump shows the SELECT (copied below) results in a gt_ekko_total table with over 70 million records (from the dump - Table IT_58[70324288x66]).  The problem is since EKKO has 294,000 rows and EKPO has 4.5 million rows, and a FOR ALL ENTRIES IN automatically changes the SELECT to a SELECT DISTINCT, the result table can have at most 4.5 million records.  On a FOR ALL ENTRIES IN, does the database return all the rows and then SAP "deletes adjacent duplicates"?
    The only solution I can think of is to change the SELECT to a SELECT DISTINCT, so perhaps when SAP builds the receiving itab, it may have many fewer rows.  Let me know if you have seen this before.
    SELECT ekkoebeln ekkobsart ekkolponr ekkolifnr ekpo~werks
      FROM ekko
    INNER JOIN ekpo ON ekkoebeln = ekpoebeln
      INTO TABLE gt_ekko_total
       FOR ALL ENTRIES IN pt_sched_agrm
    WHERE ekko~lifnr = pt_sched_agrm-vendor
       AND ekko~bsart = pt_sched_agrm-doc_type
       AND ekpo~werks = pt_sched_agrm-plant
       AND ekko~loekz = space.

    Hi Mike,
    If did all the pre-requisite for for all entries and failed to improve the performance, you use the following way.
    Instead of directly select from ekko you can select the po number(EBELN) from VIEW M_MEKKL based on LIFNR, BSART and BSTYP (what ever the fields you have) . Then do the joining select based on EBELN not LIFNR. It will surely improve your performance. For more details take reference of sap note: 0000191492.
    Thanks
    Subhankr

  • For all entries in source package merge

    Hi experts,
    I have one question regarding statement for all entries in source package where …..
    Explanations:
    Let’s say that my source package contains 2 types of data:
    -type1
    -type2
    I would like to use the statement select from table into internal table
    For all entries in source package
    But the where statement changes depending on the data type (2 keys when data type is 1 and only 1 key when data type is 2) .
    So that would be:
    Type1:
    Select fields
    From table into internal table
    Where field1 = source_package-field1
    And field2 = source_package-field2.
    Type2:
    Select fields
    From table into internal table
    Where field1 = source_package-field1
    How can I merge them?
    Thanks.
    Amine

    Hi Amine,
    Didn't try that before but there are some idea for you to reference.
    I assume source_packet have a field which indicate the data type which call source_packet-dtype
    1) Write SQL like this... (Notes: never try that, not sure if it will work)
    Select fields
    From table into internal table
    Where ( source_packet-dtype = 1 and field1 = source_package-field1 and field2 = source_package-field2 )
    OR ( source_packet-dtype = 2 and field1 = source_package-field1 ).
    2) Try to split the source_packet into 2 itab, one contain type 1 and another contain type 2 data and then read with 2 sql and merge with appending key word, but this idea assume the record will be difference
    Select fields
    From table into internal table
    Where field1 = itab_type1-field1
    And field2 = itab_type1-field2.
    Select fields
    From table APPENDING internal table
    Where field1 = itab_type2-field1
    BTW, you may have better luck in the ABAP space.
    Regards
    Bill
    Message was edited by: Chie Bill

  • For all entries or join

    Hi,
    please which should be used between for all entries or join????

    All abap programers and most of the dba's that support abap programmers are familiar with the abap clause "for all entries". Most of the web pages I visited recently, discuss 3 major drawbacks of the "for all entries" clause:
    1. duplicate rows are automatically removed
    2. if the itab used in the clause is empty , all the rows in the source table will be selected .
    3. performance degradation when using the clause on big tables.
    In this post I'd like to shed some light on the third issue. Specifically i'll discuss the use of the "for all entries" clause as a means to join tables in the abap code instead of in db2.
    Say for example you have the following abap code:
    Select * from mara
    For all entries in itab
    Where matnr = itab-matnr.
    If the actual source of the material list (represented here by itab) is actually another database table, like:
    select matnr from mseg
    into corresponding fields of table itab
    where �.
    Then you could have used one sql statement that joins both tables.
    Select t1.*
    From mara t1, mseg t2
    Where t1.matnr = t2.matnr
    And T2�..
    So what are the drawbacks of using the "for all entires" instead of a join ?
    At run time , in order to fulfill the "for all entries " request, the abap engine will generate several sql statements (for detailed information on this refer to note 48230). Regardless of which method the engine uses (union all, "or" or "in" predicates) If the itab is bigger then a few records, the abap engine will break the itab into parts, and rerun an sql statement several times in a loop. This rerun of the same sql statement , each time with different host values, is a source of resource waste because it may lead to re-reading of data pages.
    returing to the above example , lets say that our itab contains 500 records and that the abap engine will be forced to run the following sql statement 50 times with a list of 10 values each time.
    Select * from mara
    Where matnr in ( ...)
    Db2 will be able to perform this sql statement cheaply all 50 times, using one of sap standard indexes that contain the matnr column. But in actuality, if you consider the wider picture (all 50 executions of the statement), you will see that some of the data pages, especially the root and middle-tire index pages have been re-read each execution.
    Even though db2 has mechanisms like buffer pools and sequential detection to try to minimize the i/o cost of such cases, those mechanisms can only minimize the actual i/o operations , not the cpu cost of re-reading them once they are in memory. Had you coded the join, db2 would have known that you actually need 500 rows from mara, it would have been able to use other access methods, and potentially consume less getpages i/o and cpu.
    In other words , when you use the "for all entries " clause instead of coding a join , you are depriving the database of important information needed to select the best access path for your application. Moreover, you are depriving your DBA of the same vital information. When the DBA monitors & tunes the system, he (or she) is less likely to recognize this kind of resource waste. The DBA will see a simple statement that uses an index , he is less likely to realize that this statement is executed in a loop unnecessarily.
    In conclusion I suggest to "think twice" before using the "for all entries" clause and to evaluate the use of database views as a means to:
    a. simplify sql
    b. simplify abap code
    c. get around open sql limitations.

  • Email Notifications through workflow for all Approved and Rejected Orders

    hi,
    i have to send Email Notifications through workflow for all Approved and Rejected Orders to the user who have submitted the order for approval.how could it be done.please send ur solutions.
    regards
    yesukannan

    Hi,
    An option would be use Oracle Alert. Create an event based alert on the table where you have order approvals or rejections. This alert will be raised after inserting or updating this table. Create an action linked to this alert, and choose message as action type.
    This setup can be done under Alert Manager Responsibility.
    Regards,
    Ketter Ohnes

  • How to use single buffered table with FOR ALL ENTRIES KEYWORD

    Hai,
    I'm Using TJ02T Database table, It is single buffered table but at the same time I want to use FOR ALL ENTRIES KEYWORD , Please Help me.
    Regards,
    S.Janani

    Hi,
    FOR ALL ENTRIES will not depend on the buffering nature of the table. The single buffered table will only only buffer one record into memory. You can still use the statement to query the values, but it may have performance problems if the data volume is high since the records are not completely buffered into memory, the time will spent in getting data from DB.
    Thanks..
    Preetham S

  • For All Entries is NOT better than INNER JOIN in most cases

    I quote from Siegfried Boes' excellent post here: Will writing an inner join be better or creating a view?
    For all the FOR ALL ENTRIES lovers ... there is no proof for these reappearing recommendation.
    There is nearly nobody who receives forum points, who recommends FOR ALL ENTRIES instead of Joins. What is the reason ???
    It is easier to prove the opposite. A Join is a nested loop inside the database, a FOR ALL ENTRIES is partly outside of the database. FOR ALL ENTRIES works in blocks, joins on totals.
    FOR ALL ENTRIES are not recommded on really large tables, because the chances are too high that
    too many records are transferred.
    People prefer FOR ALL ENTRIES, because JOINs are not so easy to understand. Joins can go wrong, but with a bit of understanding they can be fixed.
    Some Joins are slow and can not be fixed, but then the FOR ALL ENTRIES would be extremely slow.
    There are several kinds of views:
    - projection views, i.e. only one table involved just fields reduced
    - join views, several tables, joins conditions stored in dictionary
    - materialized views, here the joined data are actually stored in the database. Storing and synchronisation has to be done manually.
    Only the last one creates real overhead. It should be the exception.
    Join Views and Joins are nearly identical. The view is better for reuse. The join is better in complicated, becuase if the access goes wrong, it can often be fixed by adding a hint. Hints can not be added to views.
    Abraham Bukit  points out:
    If it is cluster table, (you can't use join). If it is buffered table, I would also say avoid join.
    If they all are transaction table which are not buffered and are not cluster tables.  
    He further supports Siegfried's statement that FAE is easier to undestand than INNER JOINs.
    Thomas Zloch says, regarding buffered tables:
    At least think twice, maybe compare runtimes if in doubt. 
    So, unless someone has some EVIDENCE that FOR ALL ENTRIES is better, I don't think we want to see this discussed further.
    Kind regards
    Matt

    To give food for thought here's an example I  gave in a thread:
    If you have a statement like
    SELECT ... FOR ALL ENTRIES IN FAE_itab WHERE f = FAE_itab-f.
    SAP sends it to the database depending how the parameter rsdb/prefer_union_all is set:
    rsdb/prefer_union_all = 0 =>
    SELECT ... WHERE f = FAE_itab[1]-f
              OR    f = FAE_itab[2]-f
              OR    f = FAE_itab[N]-f
    You have some influence  of the generated statement type: Instead of OR'ed fields an IN list can be used
    if you have only a single coulmn N to compare:
    rsdb/prefer_in_itab_opt parameter:
    SELECT ... WHERE f IN (itab[1]-f, itab[2]-f, ..., itab[N]-f)
    rsdb/prefer_union_all = 1 =>
    SELECT ... WHERE f = FAE_itab[1]-f
    UNION ALL SELECT ... WHERE f = FAE_itab[2]-f
    UNION ALL SELECT ... WHERE f = FAE_itab[N]-f
    see: Note 48230 - Parameters for the SELECT ... FOR ALL ENTRIES statement
    As you can see for the 2nd parameter several statements are generated and combined with a UNION ALL,
    the first setting generates statements with OR's (or uses IN  if possible) for the entries in FAE_itab.
    I give you a little example here (my parameters are set in a way that the OR's are translated to IN lists; i traced the execution in ST05)
    Select myid into table t_tabcount from mydbtable
      for all entries in t_table    " 484 entries
        where myid = t_table-myid .
    ST05 trace:
    |Transaction SEU_INT|Work process no 0|Proc.type  DIA|Client  200|User |
    |Duration |Obj. name |Op.    |Recs.|RC    |Statement|
    | 640|mydbtable |PREPARE|   |  0|SELECT WHERE "myid" IN ( :A0 , :A1 , :A2 , :A3 , :A4 ) AND "myid" = :A5|
    | 2|mydbtable |OPEN   |   |  0|SELECT WHERE "myid" IN ( 1 , 2 , 3 , 4 , 5 ) AND "myid" = 72 |
    | 2.536|mydbtable |FETCH  |    0|  1403|   |
    | 3|mydbtable |REOPEN |   |  0|SELECT WHERE "myid" IN ( 6 , 7 , 8 , 9 , 10 ) AND "myid" = 72 |
    | 118|mydbtable |FETCH  |  0|  |
    | 2|mydbtable |REOPEN |  |  0|SELECT WHERE "myid" IN ( 11 , 12 , 13 , 14 , 15 ) AND "myid" = 72     |
    | 3|mydbtable |REOPEN |  |  0|SELECT WHERE "myid" IN ( 475 , 476 , 477 , 478 , 479 ) AND "myid" = 72  |
    | 94|mydbtable |FETCH  | 0| 1403|   |
    | 2|mydbtable |REOPEN |   |  0|SELECT WHERE "myid" IN ( 480 , 481 , 482 , 483 , 484 ) AND "myid" = 72 |
    You see the IN list contained 5 entries each , wich made up about 97 statements for all 484 entries.
    For every statment you have a single fetch operation wich means a separate access to the database.
    If you would replace the FAE with a join you would only have one fetch to the database.
    With the example above we can derive these observations:
    1. From database point of view these settings kill performance when you access a big table and/or have a lot of entries or columns in your FAE_itab. Furthermore, you hide information what data you will access
    at all and thus you block the database from creating a more efficient execution plan because it DOESN'T KNOW wich data you will select in the next step. I.e. it may be more efficient to scan the table in one shot instead of having many index accesses - but the database can make this decision only if it can examine ONE statement that has ALL the information of what data to retrieve.
    2. A second impact is that with every statement execution you trigger the allocation of database resources
    wich will contribute to the overhead described above.
    Said that, FAE  can never be a replacement for joining big tables (think of having a table with thousands of records in a FAE table )
    Edited by: kishan P on Nov 2, 2010 2:16 PM - Format Fixed

  • I have a problem in using  for all entries

    Hi i have a problem in using <b>for all entries</b>
    i have declared the two internal tables as below
      DATA: BEGIN OF ITAB OCCURS 10,
              EBELN LIKE EKKO-EBELN,
              LIFNR LIKE EKKO-LIFNR,
              EBELP LIKE EKBE-EBELP,
              BELNR LIKE EKBE-BELNR,
    *          MATNR LIKE EKPO-MATNR,
    *          TXZ01 LIKE EKPO-TXZ01,
              VGABE LIKE EKBE-VGABE,
              GJAHR LIKE EKBE-GJAHR,
              KNUMV LIKE EKKO-KNUMV,
         END OF ITAB.
    DATA: BEGIN OF ITAB1 OCCURS 10,
              EBELN LIKE EKPO-EBELN,
              MATNR LIKE EKPO-MATNR,
              TXZ01 LIKE EKPO-TXZ01,
              WERKS LIKE EKPO-WERKS,
              NETWR LIKE EKPO-NETWR,
              MENGE LIKE EKPO-MENGE,
              MWSKZ LIKE EKPO-MWSKZ,
              LIFNR LIKE EKKO-LIFNR,
              EBELP LIKE EKBE-EBELP,
              BELNR LIKE EKBE-BELNR,
          END OF ITAB1.
    <b>and now i have tried to move the values in those internal tables using these statements</b>
       SELECT  A~EBELN A~LIFNR A~KNUMV B~VGABE B~EBELP B~GJAHR B~BELNR
            FROM  EKKO AS A
            INNER JOIN EKBE  AS B ON  B~EBELN = A~EBELN
            INTO  CORRESPONDING
            FIELDS OF TABLE ITAB WHERE B~VGABE = '2'.
       SELECT EKPO~EBELN EKPO~MATNR EKPO~TXZ01 EKPO~WERKS EKPO~NETWR
              EKPO~MENGE EKPO~MWSKZ
          FROM EKPO
          INTO CORRESPONDING FIELDS OF TABLE ITAB1
          FOR ALL ENTRIES IN ITAB
          WHERE EBELN = ITAB-EBELN.
          LOOP AT ITAB1.
           READ TABLE ITAB WITH KEY EBELN = ITAB-EBELN.
           ITAB-EBELN = ITAB1-EBELN.
           ITAB1-LIFNR = ITAB-LIFNR.
           ITAB1-EBELP = ITAB-EBELP.
           ITAB1-BELNR = ITAB-BELNR.
           ITAB1-EBELP = ITAB-EBELP.
           APPEND ITAB1.
          ENDLOOP.
    But when i was using loop then it was displaying values in debugging mode but while i was trying to execute it was taking a lot of time i thought that it was due to more information in the already declared internal table so i have tried to remove the previous entries but it was showing an error while i was removing the old entries
    and when i  remove the loop at itab1 then i'll get output directly but it was displaying the itab fields which is my 1st internal table but not the values of itab1 can u explain me what is the possible error for that
    Regards ,
    Pavan

    before using for all entries in, u need to check whether the driver internal table is empty, if it is empty, u should not enter into select statement.
    if u wont use this check means, when the driver internal table is empty, the second select will take all the entires from the tables.
    SELECT  AEBELN ALIFNR AKNUMV BVGABE BEBELP BGJAHR B~BELNR
            FROM  EKKO AS A
            INNER JOIN EKBE  AS B ON  BEBELN = AEBELN
            INTO  CORRESPONDING
            FIELDS OF TABLE ITAB WHERE B~VGABE = '2'.
    if itab[] is not initial.
       SELECT EKPOEBELN EKPOMATNR EKPOTXZ01 EKPOWERKS EKPO~NETWR
              EKPOMENGE EKPOMWSKZ
          FROM EKPO
          INTO CORRESPONDING FIELDS OF TABLE ITAB1
          FOR ALL ENTRIES IN ITAB
          WHERE EBELN = ITAB-EBELN.
    endif.
    I hope this will help u.
    else,
    Sujatha.

Maybe you are looking for

  • Pages refuse to print page 9

    Hi i have a strange problem, i have an eleven page essay i am trying to print on an epson stylus d68 printer, however, it will no print page 9 of the essay. it will print pages 1-8 and 10-11 but not 9, i have coped page 9 to a new document and tried

  • How do I add text messages to my icloud account

    How do I add text message to my online icloud backup account?

  • No sound from TomTom with Ford Bluetooth

    I have connected the IP4s with the Ford Bluettoth system and when trying to use TomTom I get not TTS. But when I discount the bluetooth I get TTS from TomTom. Has anyone had a similar problem and found a work around?

  • Instantiation and start_scn of capture process

    Hi, We are working on stream replication, and I have one doubt abt the behavior of the stream. During set up, we have to instantiate the database objects whose data will be transferrd during the process. This instantiation process, will create the ob

  • Sending idocs for custom field

    Hi I need to send idocs when i save the data in field , the idocs should be  send automatically when the data saved to field, please provide the solution. Thanks Moderator message: "spec dumping", please work yourself first on your requirement. Edite