For all entries in join conditions

Hi All,
Can we use for all entries statement in the selection of joining 4 tables.
If so, please give me an example.
Thanks

Hello,
U can use it.
Check this:
* Get the material classification details
SELECT A~CUOBJ A~OBJEK A~KLART B~ATINN B~ATZHL B~ATWRT B~ATFLV
         B~ATAWE B~ATFLB B~ATAW1 C~CLINT D~CLASS
    INTO CORRESPONDING FIELDS OF TABLE G_T_OBJECTS
    FROM INOB AS A INNER JOIN AUSP AS B
      ON A~CUOBJ = B~OBJEK AND
         A~KLART = B~KLART
         INNER JOIN KSSK AS C
         ON B~OBJEK = C~OBJEK AND
            B~KLART = C~KLART
         INNER JOIN KLAH AS D
         ON C~CLINT = D~CLINT
     FOR ALL ENTRIES IN L_T_OBJECT
   WHERE A~OBJEK EQ L_T_OBJECT-OBJEK AND
         A~OBTAB EQ 'MARA' AND
         A~KLART IN S_KLART AND
         B~ADZHL EQ '0000' AND
         C~LKENZ EQ ' '     AND
         D~CLASS IN S_CLASS.
If useful reward.
Vasanth

Similar Messages

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.

Select inside loop into for all entries or joins

Experts please help in making it into for all entries or joins.
suppose assume this
zuser table has 2 fields usage and kunnr.
in i_table i always have 2 fields.
type
number
type will store user or nonuser
and number can store customer number or sales order number.
if the type is user then the numer will be customer number and
if the type is nonuser then the number will be sales order number.
and values in this table is like this
type number
user 100001210
nonuser 123200000
user 124573930
user 294839039
user 138393903
nonuser 382749239
type always have user or nonuser and corresponding to them we have customer numbers.
and now based on this we need to fine tune this code.
parameters :p_usage(20) type char
LOOP AT i_table.
IF i_table-type = 'NONUSER'.
SELECT single kunnr INTO skunnr FROM vbak WHERE
vbeln = i_table-value.
ENDIF.
ENDIF.
IF i_table-type = 'USER'.
skunnr = i_table-value.
ENDIF.
IF skunnr is not initial.
SELECT single usage FROM zuser
INTO v_usage
WHERE usage = p_usage
AND kunnr = skunnr.
IF v_usage IS NOT INITIAL.
i_export-kunnr = i_table-type.
i_export-auart = i_table-name.
i_export-flag = 'X'.
ELSE.
i_export-NAME = i_table-type.
i_export-age = i_table-name.
i_export-flag = ''.
ENDIF.
Append i_export to itab_final.
ENDIF.
ENDLOOP.
Moderator message - Moved to the correct forum
Edited by: Rob Burbank on Jul 2, 2009 2:53 PM

U can have this as a solution to avoid ur loop.
declare to itabs as below:
data: i_table_user type standard table of i_table,
i_table_nonuser type standard table of i_table.
i_table_user[] = i_table[].
i_table_nonuser[] = i_table[].
delete i_table_user where user eq 'NONUSER' . (BY THIS YOU WILL HAVE ONLY USERS IN THIS ITAB)
delete i_table_NONuser where user eq 'USER' . (BY THIS YOU WILL HAVE ONLY NONUSERS IN THIS ITAB)
NOW AVOID LOOP AT ITAB AND WRITE YOUR 2 SELECT STATEMENT BY USING FOR ALL ENTRIES OF
IF YOU DONT NEED any of THESE ITABS FURTHER , refresh them to improve ur memory and performance.
HOPE THIS HELPS.
THANKS
KIRAN

2 for all entries with different condition

Hi
i have an internal 2 internal table which have the following field
ITAB1 : Stock category, plant, storage location , SKU code (those value are given though flat file)
ITAB2 : Grid value , meterial NO, SKU code (those values are determine through a FM where we export the SKU code and it will retreive the matnr and grid value in an ITAB2)
I have to do select FROM database MCHB
with the condition Grid value , material NO , Stock category, plant, storage location
Note that gris value and matnr are found in two different internal table i was thinking of doing for all entries but
is it possible to do for all entries from 2 internal table
SELECT FOROM MCHB
FOR ALL ENTRIES in ITAB1
FOR ALL ENTRIES in ITAB2
WHERE
grid value = itab2-gridvalue
matnr = itab2-matnr
stock cat = itab1-stock cat
plant = itab1-plant
storage location = itab1-storage location
Please help on how to tackle this?

Hi,
You have to create a new third internal table with the fields matnr, grid value, stock category, plant and storage location....
Then process the itab1 and get the process the itab2 for the corresponding SKU Code (which I believe is the common field for both of the internal tables) and then populate the third internal table itab3...
Then use the itab3 for the FOR ALL ENTRIES.
Thanks
Naren

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

Inner joins Vs for all entries

Hi All,
Pls let me know
the differences b/w innerjoins and for all entries,,,,which is the best option and Y??
Thanks in Advance,
Bye

Hi!
INNER JOIN is used if we want to retrieve some data from more than one table.
FOR ALL ENTRIES is used if we want some data from a table based on some conditions of some other table.
Using several nested INNER JOIN statements can be inefficient and cause time out if the tables become too big in the future."
In ABAP, these joins are first split by the ABAP processor and then sent to the database, with the increase in DATA in production system, these joins tend to give way if your database keeps growing larger and larger.
You should rather use "FOR ALL ENTRIES IN" (Tabular conditions), which is a much efficient way as far as performance is concerned.
Check these links:
inner joins and for all entries
inner join and for all entries
Reward points if it helps.
Regards
Sudheer

Inner join and select for all entries with respect to performance

Hi Friends,
I just want to know which is more efficient with respect to performance the Inner join or select for all entries?which is more efficient? and how? can you explain me in detail ?
Regards,
Dinesh

INNER JOIN->
The data that can be selected with a view depends primarily on whether the view implements an inner join or an outer join. With an inner join, you only get the records of the cross-product for which there is an entry in all tables used in the view. With an outer join, records are also selected for which there is no entry in some of the tables used in the view.
http://help.sap.com/saphelp_nw2004s/helpdata/en/cf/21ec77446011d189700000e8322d00/content.htm
FOR ALL ENTRIES->
Outer join can be created using this addition to the where clause in a select statement. It speeds up the performance tremendously, but the cons of using this variation are listed below
Duplicates are automatically removed from the resulting data set. Hence care should be taken that the unique key of the detail line items should be given in the select statement.
If the table on which the For All Entries IN clause is based is empty, all rows are selected into the destination table. Hence it is advisable to check before-hand that the first table is not empty.
If the table on which the For All Entries IN clause is based is very large, the performance will go down instead of improving. Hence attempt should be made to keep the table size to a moderate level.
Not Recommended
Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
Recommended
Select * from zfligh appending table int_fligh
For all entries in int_cntry
Where cntry = int_cntry-cntry.

About for all entries

can u give the information abt the FOR ALL ENTRIES and the conditions.

HI
GOOD
Use of FOR ALL Entries
Outer join can be created using this addition to the where clause in a select statement. It speeds up the performance tremendously, but the cons of using this variation are listed below
Duplicates are automatically removed from the resulting data set. Hence care should be taken that the unique key of the detail line items should be given in the select statement.
If the table on which the For All Entries IN clause is based is empty, all rows are selected into the destination table. Hence it is advisable to check before-hand that the first table is not empty.
If the table on which the For All Entries IN clause is based is very large, the performance will go down instead of improving. Hence attempt should be made to keep the table size to a moderate level.
Not Recommended
            Loop at int_cntry.
             Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
            Endloop.
Recommended
            Select * from zfligh appending table int_fligh
            For all entries in int_cntry
            Where cntry = int_cntry-cntry.
GO THROUGH THESE LINKS
http://www.thespot4sap.com/articles/SAPABAPPerformanceTuning_ForAllEntries.asp
CODE
Code to demonstrate Select FOR ALL ENTRIES command
The FOR ALL ENTRIES comand only retrieves data which matches
entries within a particular internal table.
TYPES: begin of t_bkpf,
include structure bkpf.
bukrs like bkpf-bukrs,
belnr like bkpf-belnr,
gjahr like bkpf-gjahr,
BLDAT like bkpf-BLDAT,
monat like bkpf-monat,
budat like bkpf-budat,
xblnr like bkpf-xblnr,
awtyp like bkpf-awtyp,
awkey like bkpf-awkey,
end of t_bkpf.
data: it_bkpf type standard table of t_bkpf initial size 0,
      wa_bkpf type t_bkpf.
TYPES: begin of t_bseg,
*include structure bseg.
bukrs     like bseg-bukrs,
belnr     like bseg-belnr,
gjahr     like bseg-gjahr,
buzei     like bseg-buzei,
mwskz     LIKE bseg-mwskz,         "Tax code
umsks     LIKE bseg-umsks,         "Special G/L transaction type
prctr     LIKE bseg-prctr,         "Profit Centre
hkont     LIKE bseg-hkont,         "G/L account
xauto     like bseg-xauto,
koart     like bseg-koart,
dmbtr     like bseg-dmbtr,
mwart     like bseg-mwart,
hwbas     like bseg-hwbas,
aufnr     like bseg-aufnr,
projk     like bseg-projk,
shkzg     like bseg-shkzg,
kokrs     like bseg-kokrs,
end of t_bseg.
data: it_bseg type standard table of t_bseg initial size 0,
      wa_bseg type t_bseg.
select bukrs belnr gjahr BLDAT monat budat xblnr awtyp awkey
up to 100 rows
from bkpf
into table it_bkpf.
if sy-subrc EQ 0.
select bukrs belnr gjahr buzei mwskz umsks prctr hkont xauto koart
         dmbtr mwart hwbas aufnr projk shkzg kokrs
    from bseg
    into table it_bseg
    FOR ALL ENTRIES in it_bkpf
    where bukrs eq it_bkpf-bukrs and
          belnr eq it_bkpf-belnr and
          gjahr eq it_bkpf-gjahr.
endif.
CODE
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
THANKS
MRUTYUN

What is the usage of for all entries ?

What is the Usage of read table after using for all entries ?
In the following example what exactly it is doing ?
Usage of 'for all entries' in Select Statement
FORM data_retrieval.
DATA: ld_color(1) TYPE c.
DATA: BEGIN OF T_VBAP OCCURS 0,
        VBELN LIKE VBAP-VBELN,
        MATNR LIKE VBAP-MATNR,
        POSNR LIKE VBAP-POSNR,
        END OF T_VBAP.
DATA: BEGIN OF T_VBFA OCCURS 0,
        VBELV LIKE VBFA-VBELV,
        VBELN LIKE VBFA-VBELN,
        VBTYP_N LIKE VBFA-VBTYP_N,
        END OF T_VBFA.
DATA: BEGIN OF T_VBAK OCCURS 0,
        VBELN LIKE VBAK-VBELN,
        IHREZ LIKE VBAK-IHREZ,
        END OF T_VBAK.
DATA: BEGIN OF T_KNA1 OCCURS 0,
        KUNNR LIKE KNA1-KUNNR,
        NAME1 LIKE KNA1-NAME1,
        END OF T_KNA1.
   DATA: BEGIN OF T_MAKT OCCURS 0,
        MATNR LIKE MAKT-MATNR,
        MAKTX LIKE MAKT-MAKTX,
        END OF T_MAKT.
SELECT likpvbeln likplifex likpbldat likpwadat likpwadat_ist likpkodat likp~lfart
         likpkunnr likpvstel lipsposnv lipslfimg lipsvrkme lipslgmng lips~meins
         lipswerks lipslgort lipscharg lipsvbelv lipsposnr lipsmatnr
         lipsvbeln LIPSVGBEL LIPSVGPOS vbupkosta vbupwbsta vbupposnr vbup~vbeln
          VBAKIHREZ VBAKVBELN VBAP~VBELN
     INTO CORRESPONDING FIELDS OF TABLE it_itab
    FROM ( likp
           INNER JOIN lips
           ON lipsvbeln = likpvbeln
           INNER JOIN vbup
           ON vbupposnr = lipsposnr
           and VBUPVBELN = LIPSVBELN )
          left outer join VBAK
          on VBAKVBELN = LIPSVGBEL
          inner join VBAP
          on VBAPVBELN = VBAKVBELN )
         WHERE likp~vbeln IN so_vbeln
           AND likp~lifex IN so_lifex
           AND likp~lfart IN so_lfart
           AND likp~kunnr IN so_kunnr
           AND likp~vstel IN so_vstel
           AND likp~bldat IN so_bldat
           AND likp~wadat_ist IN so_wadat
           AND vbup~kosta IN so_kosta
           AND vbup~wbsta IN so_wbsta
           AND LIPS~LFIMG NE 0.
SELECT VBELN IHREZ INTO TABLE T_VBAK
FROM VBAK
FOR ALL ENTRIES IN IT_ITAB
WHERE VBELN = IT_ITAB-VGBEL.
APPEND T_VBAK.
ENDSELECT.
SELECT VBELN MATNR POSNR INTO TABLE T_VBAP
FROM VBAP
FOR ALL ENTRIES IN IT_ITAB
WHERE VBELN = IT_ITAB-VGBEL AND
        MATNR = IT_ITAB-MATNR AND
        POSNR = IT_ITAB-VGPOS.
APPEND T_VBAP.
ENDSELECT.
SELECT VBELV VBELN VBTYP_N INTO TABLE T_VBFA
FROM VBFA
FOR ALL ENTRIES IN IT_ITAB
WHERE VBELV = IT_ITAB-VBELN AND
        VBTYP_N = 'M' .
SELECT KUNNR NAME1 INTO TABLE T_KNA1
FROM KNA1
FOR ALL ENTRIES IN IT_ITAB
WHERE KUNNR = IT_ITAB-KUNNR.
APPEND T_KNA1.
ENDSELECT.
SELECT MATNR MAKTX INTO TABLE T_MAKT
FROM MAKT
FOR ALL ENTRIES IN IT_ITAB
WHERE MATNR = IT_ITAB-MATNR.
APPEND T_MAKT.
ENDSELECT.
*Populate field with color attributes
LOOP AT it_itab INTO wa_ITAB.
Populate color variable with colour properties
Char 1 = C (This is a color property)
Char 2 = 3 (Color codes: 1 - 7)
Char 3 = Intensified on/off ( 1 or 0 )
Char 4 = Inverse display on/off ( 1 or 0 )
i.e. wa_ekko-line_color = 'C410'
    REFRESH color.
    colourize 'VBELN' 0. " .
    WA_ITAB-farbe = color[].
    ld_color = ld_color + 1.
Only 7 colours so need to reset color value
    IF ld_color = 3. "8
      ld_color = 1.
    ENDIF.
    CONCATENATE 'C' ld_color '10' INTO wa_ITAB-line_color.
    WA_ITAB-NAME1 = ''.
    WA_ITAB-MAKTX = ''.
    WA_ITAB-IHREZ = ''.
    WA_ITAB-VBELV = ''.
    READ TABLE T_KNA1 WITH KEY KUNNR = WA_ITAB-KUNNR.
    IF SY-SUBRC = 0.
       WA_ITAB-NAME1 = T_KNA1-NAME1.
    ENDIF.
    READ TABLE T_MAKT WITH KEY MATNR = WA_ITAB-MATNR.
    IF SY-SUBRC = 0.
    WA_ITAB-MAKTX = T_MAKT-MAKTX.
    ENDIF.
    READ TABLE T_VBAK WITH KEY VBELN = WA_ITAB-VGBEL.
    IF SY-SUBRC = 0.
    WA_ITAB-IHREZ = T_VBAK-IHREZ.
    ENDIF.
    READ TABLE T_VBFA WITH KEY VBELV = WA_ITAB-VBELN.
    IF SY-SUBRC = 0.
    WA_ITAB-VBELVA = T_VBFA-VBELN.
    ENDIF.
   READ TABLE T_VBAP WITH KEY VBELN = WA_ITAB-VGBEL
                              POSNR = WA_ITAB-VGPOS
                              MATNR = WA_ITAB-MATNR.
   IF SY-SUBRC = 0.
   WA_ITAB-IHREZ = T_VBAK-IHREZ.
   ENDIF.
wa_ekko-line_color = 'C410'.
    MODIFY it_itab FROM wa_itab.
ENDLOOP.
ENDFORM. " data_retrieval

hi Jyotirmoy,
The explanation below can give u an idea of wat is going in ur code..
Use of FOR ALL Entries
Outer join can be created using this addition to the where clause in a select statement. It speeds up the performance tremendously, but the cons of using this variation are listed below
Duplicates are automatically removed from the resulting data set. Hence care should be taken that the unique key of the detail line items should be given in the select statement.
If the table on which the For All Entries IN clause is based is empty, all rows are selected into the destination table. Hence it is advisable to check before-hand that the first table is not empty.
If the table on which the For All Entries IN clause is based is very large, the performance will go down instead of improving. Hence attempt should be made to keep the table size to a moderate level.
Not Recommended
            Loop at int_cntry.
             Select single * from zfligh into int_fligh
             where cntry = int_cntry-cntry.
             Append int_fligh.
            Endloop.
Recommended
            Select * from zfligh appending table int_fligh
            For all entries in int_cntry
            Where cntry = int_cntry-cntry.
Thankyou,
Regards.

Offset in where clause of for all entries

Hi ,
I need to fetch VBELN from VBKD table based on Purchase order no which is fetched from a Z-table.So I am using for all entries with where condition as VBKD-BSTKD_M = Ztable-PONumber and fetching values from VBKD .But at times PO number in VBKD table can have additional things attached to it .
Eg Ztable-PO number = 12345678 , VBKD-BSTKD_M = 12345678-001 so I need to ignore the '-001' part and still fetch data from VBKD.So how can I do that.
Pls let me know if you have any ideas.
Thanks in advance,
Rajasekaran

Hi ,
We cannot use offset directly in where as it will result in syntax error as the field length for both fields have to match .In my case the length of both Ztable -PO number field and vbkd-bstkd_m are 35 characters.So cannot use offset directly in where clause of for all entries.
Pls let me know if you have any other ideas.
Thanks in advance,
Rajsekaran

Innerjoin & for all entries

what is innerjoin & for all entries?
which one is used in which position,explain plzzzzzzzzzzzzzzzzz.
explain advantages & disadvantages?

hi,
follow these links for knowing the difference between For all entries and joins.
http://www.erpgenie.com/abap/performance.htm#For%20all%20entries
http://blogs.ittoolbox.com/sap/db2/archives/for-all-entries-vs-db2-join-8912
1. INNER JOIN
DBTAB1 <----
> DBTAB2
It is used to JOIN two DATABASE tables
having some COMMON fields.
To Impove the perfomance of program you can use for all entries instead of your inner join...This is always preferable..But before make a check and make sure that your internal table is not empty.
2. Whereas
For All Entries,
DBTAB1 <----
> ITAB1
is not at all related to two DATABASE tables.
It is related to INTERNAL table.
3. If we want to fetch data
from some DBTABLE1
but we want to fetch
for only some records
which are contained in some internal table,
then we use for alll entries.
1. simple example of for all entries.
2. NOTE THAT
In for all entries,
it is NOT necessary to use TWO DBTABLES.
(as against JOIN)
3. use this program (just copy paste)
it will fetch data
from T001
FOR ONLY TWO COMPANIES (as mentioned in itab)
FOR ALL ENTRIES is an effective way of doing away with using JOIN on two tables.
You can check the below code -
SELECT BUKRS BELNR GJAHR AUGDT
FROM BSEG
INTO TABLE I_BSEG
WHERE BUKRS = ....
SELECT BUKRS BELNR BLART BLDAT
FROM BKPF
INTO TABLE I_BKPF
FOR ALL ENTRIES IN I_BSEG
WHERE BUKRS = I_BSEG-BUKRS
AND BELNR = I_BSEG-BELNR
AND BLDAT IN SO_BLDAT
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.
http://www.thespot4sap.com/articles/SAPABAPPerformanceTuning_ForAllEntries.asp

Can a JOIN statement be rewritten using FOR ALL ENTRIES in any case ?

I had a SELECT statement, like:
    select p~key1 t~col3 t~col4 p~col2 p~col3
      into table itab1
      from ( table1 as p left outer join table2 as t
              on p~key1 = t~key1 and t~col2 = someValue ).
Among which, table1 and table2 are fully buffered.
Code Inspector suggests that this statement should be, e.g., rewritten using FOR ALL ENTRIES.
Since FOR ALL ENTRIES is only possible for WHERE conditions of the SELECT statement, which means the internal table right after it is not available for the RESULT clause of the SELECT statement, can the above statement be rewritten? If yes, how?
Thanks!

hi ,
select pkey1 tcol3 tcol4 pcol2 p~col3
      into table itab1
      from ( table1 as p left outer join table2 as t
              on pkey1 = tkey1 and t~col2 = someValue ).
<i>look below code</i>
select * from table2 into table int_tab2 where col2 = someValue.
select key1 col2 col3 into table int_tab1
FOR ALL ENTRIES IN int_tab2
WHERE key = int_tab2-key1.
then use read statements for manipulations
rgds
Anver

Join Internal Table for all entries

Hi,
   I have put the LIKP data in the internal table and then use the for all entries statement to join the table with LIPS. Besides, i specifiy an additional condition to filter empty batch.
But, i found that the empty batch record still exist in the result. Any idea??
    SELECT *
    FROM LIPS INTO TABLE I_DELIVERY_INFO
    FOR ALL ENTRIES IN I_DELIVERY
    WHERE
    VBELN = I_DELIVERY-VBELN.
    AND
    CHARG IS NOT NULL.
Regards,
Kit

Hi Kit,
If you are using LIKP and LIPS then you can directly join them since these tables are HEADER & ITEM table.
regd ur query you can use CHARG NE ' '.
Regards
Gopi

Does 'For All Entries in itab' work exactly like 'Join' statement?

Hi,
I would like to know that if 'For All Entries in itab' work exactly like 'Join' statement?
If yes, then when I use 'For All Entries in itab' and a 'Join' statement seperately with the same logical conditions for both, the number of records returned by the two methods are not same. Ideally, they should both return the same number of recs.
Can somebody help?
With regards.

Hi,
for all entries will not work in the same way unless untill it should satisfy some conditions,
it has some pre-requisests...
like in the select clause or in where clause or in both the cluases, there should be entire key..
then only it will behave like the join statement..
hope i am clear.
please revert back if u have any quiries.
Regards,
Sunil Kumar Mutyala.

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 in join conditions

Similar Messages

Maybe you are looking for