Which is better group by or for all entries in

We have more than 11 Lac Records in AUFM table.
I am working on a Report to find SO to Production Order to AUFM (for raw material).
It's ALV OOP.
Which code will give better result - For AUFM fetch with key AUFNR.
GROUP BY matnr
OR
FOR ALL ENTRIES IN it_previous
Moderator message: too vague to give decent advice, please try yourself first and compare runtimes, re-post including all relevant information if required, please use international units only when posting again.
Please Read before Posting in the Performance and Tuning Forum
locked by: Thomas Zloch on Sep 8, 2010 10:13 AM

that oracle wont work if we have group by on a column which is character data type instead of number data typeEither he has been taught wrongly OR he has come across one specific case where it seems that there was an issue but he doesn't know enough about that case and is making a generalisation.
Hemant K Chitale

Similar Messages

Group by with for all entries

Hi,
   SELECT max( VBELN ) VGBEL VGPOS POSNR FKIMG VRKME NTGEW MATNR ARKTX WERKS MVGR3
       FROM VBRP
       INTO TABLE T_INVIT
       FOR ALL ENTRIES IN T_INVHD
       WHERE VBELN = T_INVHD-VBELN
       AND    SPART = T_INVHD-SPART
       AND    werks IN swerks
       AND    mvgr3 IN smvgr3
       group by VBELN VGBEL VGPOS POSNR FKIMG VRKME NTGEW MATNR ARKTX WERKS MVGR3.
i want to (max) invoice no against a delivery i.e vgbel but in this query i am getting error that with for all entries only count * is allowed.
regards
Fozia

Hi Do this way..
IF NOT T_INVHD[] is initial.
LOOP AT T_INVHD
SELECT max( VBELN ) VGBEL VGPOS POSNR FKIMG VRKME NTGEW MATNR ARKTX WERKS MVGR3
FROM VBRP
INTO T_INVIT
WHERE VBELN = T_INVHD-VBELN
AND SPART = T_INVHD-SPART
AND werks IN swerks
AND mvgr3 IN smvgr3
group by VGBEL VGPOS POSNR FKIMG VRKME NTGEW MATNR ARKTX WERKS MVGR3.
IF SY-SUBRC = 0.
APPEND T_INVIT.
CLEAR T_INVIT
ENDIF.
endselect.
endloop.
endif.
EVEN NO EFFECT ON PERFORMANCE
RGDS
RAJESH

INNER JOIN with FOR ALL ENTRIES IN Performance ?

I am using following the following Select using Inner join with For All Entries in.
 SELECT kebeln kebelp kvbeln kvbelp
 FROM ekkn AS k INNER JOIN ekbe AS b ON kebeln = bebeln
 AND kebelp = bebelp
 INTO TABLE gi_purchase
 FOR ALL ENTRIES
 IN gi_sales
 WHERE k~mandt EQ sy-mandt
 AND k~vbeln EQ gi_sales-vbeln
 AND k~vbelp EQ gi_sales-posnr
 AND b~budat EQ p_date.
If i am not doing inner join then I will have to do 2 select with for all entries in on ekkn and ekbe tables and then compare them.
I want to know which one has better performance
Inner join with for all entries in
 or
2 Selects with for all entries in

the join is almost aways faster:
<a href="/people/rob.burbank/blog/2007/03/19/joins-vs-for-all-entries--which-performs-better">JOINS vs. FOR ALL ENTRIES - Which Performs Better?</a>
<a href="http://blogs.ittoolbox.com/sap/db2/archives/for-all-entries-vs-db2-join-8912">FOR ALL ENTRIES vs DB2 JOIN</a>
Rob

Innerjoin or for all entries

Hi Friends,
please suggest me in performance innerjoin is better or for all entries is better to get data from two transparent tables.
Krishna.

hi,
for all entries is the better method.
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.
*******************************8
look another example
what is the use of FOR ALL ENTRIES
1. INNER JOIN
DBTAB1 <----
> DBTAB2
It is used to JOIN two DATABASE tables
having some COMMON fields.
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)
4
REPORT abc.
DATA : BEGIN OF itab OCCURS 0,
bukrs LIKE t001-bukrs,
END OF itab.
DATA : t001 LIKE TABLE OF t001 WITH HEADER LINE.
itab-bukrs = '1000'.
APPEND itab.
itab-bukrs = '1100'.
APPEND itab.
SELECT * FROM t001
INTO TABLE t001
FOR ALL ENTRIES IN itab
WHERE bukrs = itab-bukrs.
LOOP AT t001.
WRITE :/ t001-bukrs.
ENDLOOP.
Hope this helps!
Regards,
Anver

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

Better to have outer join or to have for all entries

Hi Gurus
I have one select query taking lot of time to retrieve data.
My question is Is it better to have a outer join or should i go with For all entries.
SELECT distinct sbukrs skunnr sumskz sgsber sbschl swaers
         sblart szfbdt sgjahr sbelnr sbuzei sbudat
         swrbtr sdmbtr sshkzg crzzrprctr
   APPENDING TABLE gt_data_a
   FROM bsad AS s
                  LEFT OUTER JOIN zcce1a as c
                    ON sbukrs = crbukrs
                   AND sgjahr = crefryear
                   AND sbelnr = cbelnr
                   AND sbuzei = cbuzei
                   AND sSHKZG = cDRCRK
                   AND c~REFDOCCT = 'W'
                   AND c~RLDNR = 'Z1'
                   AND c~RVERS = '001'
WHERE
         s~bukrs IN s_bukrs
     AND s~kunnr IN s_kunnr
     AND s~umsks IN s_umsks
     AND s~umskz IN s_umskz
     AND s~augdt IN s_augdt
     AND s~augbl IN s_augbl
     AND s~zuonr IN s_zuonr
     AND s~gjahr IN s_gjahr1
     AND s~belnr IN s_belnr
     AND ( sbudat IN s_budat1 AND sbudat LE p_stida )
     AND s~augdt GT p_stida
     AND s~bldat IN s_bldat1
     AND s~cpudt IN s_cpudt
     AND s~waers IN s_waers1
     AND s~xblnr IN s_xblnr
     AND s~blart IN s_blart
     AND s~monat IN s_monat
     AND s~bschl IN s_bschl
     AND s~shkzg IN s_shkzg
     AND s~gsber IN s_gsber
     AND s~mwskz IN s_mwskz
     AND s~dmbtr IN s_dmbtr
     AND s~wrbtr IN s_wrbtr
     AND s~hkont IN s_hkont
     AND s~filkd IN s_filkd
     AND s~zlsch IN s_zlsch
     AND s~zlspr IN s_zlspr
     AND s~mansp IN s_mansp
     AND s~mschl IN s_mschl
     AND s~madat IN s_madat
     AND s~manst IN s_manst
     AND s~maber IN s_maber
     AND s~rstgr IN s_rstgr
     AND s~projk IN s_projk
     AND s~xref1 IN s_xref1
     AND s~xref2 IN s_xref2
     AND s~imkey IN s_imkey
     AND s~fistl IN s_fistl
     AND s~dabrz IN s_dabrz
     AND s~kostl IN s_kostl
     AND s~cession_kz IN s_cessio.
Moderator message - Please see Please Read before Posting in the Performance and Tuning Forum before posting - post locked
Edited by: Rob Burbank on Sep 15, 2009 9:52 AM

Hi Sandeep Sharma,
Table BSAD is having below primary key fields...
BUKRS
KUNNR
UMSKS
UMSKZ
AUGDT
AUGBL
ZUONR
GJAHR
BELNR
BUZEI
Now the Question is In your selection screen what and all fields you kept mandatory ??
Try to make some of these above fileds as mandatory which may fit one of the index of BSAD table...
Different Available Indexes on BSAD is as below...
Index for logical database
MANDT
KUNNR
BUKRS
AUGDT
AUGBL
GJAHR
BELNR
BUZEI
Index using settlement run (payment cards)
MANDT
BUKRS
CCBTC
Index for Invoice Reference
MANDT
BUKRS
REBZG
REBZJ
REBZZ
KUNNR
UMSKS
REBZT
Index for Line Item Access
MANDT
BUKRS
BELNR
GJAHR
BUZEI
Index for BW Extract
MANDT
BUKRS
CPUDT
Also code in both the way... and check the time of execution for the queries... Actually it(Performance) depends on data as well as selection criteria...
Hope it will solve your problem..
Thanks & Regards
ilesh 24x7
ilesh Nandaniya

Which is better MAMP or XAMMP for OS X Mavericks?

Which is better MAMP or XAMMP for OS X Mavericks? Hope I will get the information with Pros and Cons of both application...

Which is better MAMP or XAMMP for OS X Mavericks? Hope I will get the information with Pros and Cons of both application...

Which is better verizon or att for cellular?

which is better verizon or att for cellular?

The 3/4G iPads are Verizon or ATT. You choose which one you want when you buy the iPad. It can't be changed.
 Cheers, Tom

HT5243 It says on the "Java for Mac OS X 10.6 Update 8" pg that this download is for all users and supercedes all earlier versions. Yet to the right is says you HAVE to have 10.6.8 as a requirement. WHICH is it? Is it for all versions of 10.6 or not?

It says on the "Java for Mac OS X 10.6 Update 8" pg that this download is for all users and supercedes all earlier versions. Yet to the right is says you HAVE to HAVE 10.6.8 as a requirement. WHICH is it? Is it for all versions of 10.6 or not? Why isnt this made more clear?
And question is STILL not answered. WHICH is to be downloaded and used?
I would like an answer.

Thank you for the clarification! It is really kinda circle-speaking to state on an information page to put forth info people need in that manner. It really does add to the confusion and frustration when you need a simple,
straight answer, such as you gave, and you dont get one. Kind of like that . . other... software company....
This rabbit hole still continues, though. I'm going to ladder it out, just to see for myself:
Have: MacBookPro / 2.4 GHz/ Intel Core i5/ running OS X 10.6.3 -
Need: latest version of Java, so Flash update can be loaded;
                              (want html5 to be the standard so badly, but client wants Flash)
Attempted: Tried to find Java for Mac OS X 10.6 Update 2 on Apple website. No Joy.
        Found:   Update 2 is proper update for Mac OS X 10.6.3. Could not find download on Apple website;
                       - No Joy.
Attempted: Tried to find Java for Mac OS X 10.6 Update 8. Half Joy. Confusing, no straight info.
        Found:   In order to install update for Java, must update OS X from present 10.6.3 to 10.6.8
Attempted:   Tried to find update to OS X 10.6.3 to 10.6.8. on Apple website.
how far does the rabbit hole go?

Select for all entries

Hi,
      I am new in abap reports. Now i want to know why we should use select for all entries in query. We can do retrieve directly by accessing the table in database dictionary.
      Experts please give me the reasons I want to know the concepts behind it.It will be better if you kindly explain this with help of code.
     With regards,
       Abir.

HI
GOOD
SELECT
Basic form
SELECT result [target] FROM source [where] [GROUP BY fields] [ORDER BY order].
Effect
Retrieves an extract and/or a set of data from a database table or view (see Relational database ). SELECT belongs to the OPEN SQL command set.
Each SELECT command consists of a series of clauses specifying different tasks:
The SELECT result clause specifies
whether the result of the selection is a table or a single record,
which columns the result is meant to have and
whether the result is allowed to include identical lines.
The INTO target clause specifies the target area into which the selected data is to be read. If the target area is an internal table, the INTO clause specifies
whether the selected data is to overwrite the contents of the internal table or
whether the selected data is to be appended to the contents and
whether the selected data is to be placed in the internal table all at once or in several packets.
The INTO clause can also follow the FROM clause.
You can omit the INTO clause. The system then makes the data available in the table work area (see TABLES ) dbtab . If the SELECT clause includes a "*", the command is processed like the identical SELECT * INTO dbtab FROM dbtab statement. If the SELECT clause contains a list a1 ... an , the command is executed like SELECT a1 ... an INTO CORRESPONDING FIELDS OF dbtab FROM dbtab .
If the result of the selection is meant to be a table, the data is usually (for further information, see INTO -Klausel ) read line by line within a processing loop introduced by SELECT and concluded by ENDSELECT . For each line read, the processing passes through the loop once. If the result of the selection is meant to be a single record, the closing ENDSELECT is omitted.
The FROM source clause the source (database table or view ) from which the data is to be selected. It also determines
the type of client handling,
the behavior for buffered tables and
the maximum number of lines to be read.
The WHERE where clause specifies the conditions which the result of the selection must satisfy. It thus determines the lines of the result table. Normally - i.e. unless a client field is specified in the WHERE clause - only data of the current client is selected. If you want to select across other clients, the FROM clause must include the addition ... CLIENT SPECIFIED .
The GROUP-BY fields clause combines groups of lines together into single lines. A group is a set of lines which contain the same value for every database field in the GROUP BY clause.
The ORDER-BY order clause stipulates how the lines of the result table are to be ordered.
Each time the SELECT statement is executed, the system field SY-DBCNT contains the number of lines read so far. After ENDSELECT , SY-DBCNT contains the total number of lines read.
The return code value is set as follows:
SY-SUBRC = 0 At least one line was read.
SY_SUBRC = 4 No lines were read.
SY-SUBRC = 8 The search key was not fully qualified.
(nur bei SELECT SINGLE ). The returned single record is any line of the solution set.
Example
Output the passenger list for the Lufthansa flight 0400 on 28.02.1995:
TABLES SBOOK.
SELECT * FROM SBOOK
WHERE
    CARRID   = 'LH '      AND
    CONNID   = '0400'     AND
    FLDATE   = '19950228'
ORDER BY PRIMARY KEY.
WRITE: / SBOOK-BOOKID, SBOOK-CUSTOMID,   SBOOK-CUSTTYPE,
           SBOOK-SMOKER, SBOOK-LUGGWEIGHT, SBOOK-WUNIT,
           SBOOK-INVOICE.
ENDSELECT.
Note
Performance
In client/server environments, storing database tables in local buffers (see SAP buffering ) can save considerable amounts of time because the time required to make an access via the network is much more than that needed to access a locally buffered table.
Notes
A SELECT command on a table for which SAP buffering is defined in the ABAP/4 Dictionary is normally satisfied from the SAP buffer by bypassing the database. This does not apply with
- SELECT SINGLE FOR UPDATE
- SELECT DISTINCT in the SELECT clause ,
- BYPASSING BUFFER in the FROM clause ,
- ORDER BY f1 ... fn in the ORDER-BY clause ,
- aggregate functions in the SELECT clause ,
- when using IS [NOT] NULL WHERE condition ,
or if the generic key part is not qualified in the WHERE-Bedingung for a generically buffered table.
Authorization checks are not supported by the SELECT statement, so you must program these yourself.
In dialog systems, the database system locking mechanism cannot always guarantee to synchronize the simultaneous access of several users to the same dataset. In many cases, it is therefore advisable to use the SAP locking mechanism .
Changes to data in a database are only finalized after a database commit (see LUW ). Prior to this, any database update can be reversed by a database rollback (see Programming transactions ). At the lowest isolation level (see the section on the "uncommitted read" under Locking mechanism ), this can result in the dataset selected by the SELECT command not really being written to the database. While a program is selecting data, a second program can add, change or delete lines at the same time. Then, the changes made by the second program are reversed by rolling back the database system. The selection of the first program thus reflects only a very temporary state of the database. If such "phantom data" is not acceptable for a program, you must either use the SAP locking mechanism or at least set the isolation level of the database system to "committed read" (see Locking mechanism ).
In a SELECT-ENDSELECT loop, the CONTINUE statement terminates the current loop pass prematurely and starts the next.
If one of the statements in a SELECT ... ENDSELECT loop results in a database commit, the cursor belonging to the SELECT ... ENDSELECT loop is lost and the processing terminates with a runtime error. Since each screen change automatically generates a database commit, statements such as CALL SCREEN , CALL DIALOG , CALL TRANSACTION or MESSAGE are not allowed within a SELECT ... ENDSELECT loop.
Related OPEN CURSOR , FETCH und CLOSE CURSOR
GO THROUGH THIS LINK
http://www.geocities.com/SiliconValley/Campus/6345/select.htm
THANKS
MRUTYUN

Performance on Select Single&Write AND Select*(For All Entries)&Read&Write

Hi Experts,
I got a code review problem & we are in a argument.
I need the best performance code out of this two codes. I have tested this both on 5 & 1000 & 3000 & 100,000 & 180,000 records.
But still, I just need a second opinion of experts.
TYPES : BEGIN OF ty_account,
        saknr   TYPE   skat-saknr,
        END OF ty_account.
DATA : g_txt50      TYPE skat-txt50.
DATA : g_it_skat    TYPE TABLE OF skat,       g_wa_skat    LIKE LINE OF g_it_skat.
DATA : g_it_account TYPE TABLE OF ty_account, g_wa_account LIKE LINE OF g_it_account.
Code 1.
SELECT saknr INTO TABLE g_it_account FROM skat.
LOOP AT g_it_account INTO g_wa_account.
SELECT SINGLE txt50 INTO g_txt50 FROM skat
    WHERE spras = 'E'
      AND ktopl = 'XXXX'
      AND saknr = g_wa_account-saknr.
WRITE :/ g_wa_account-saknr, g_txt50.
CLEAR : g_wa_account, g_txt50.
ENDLOOP.
Code 2.
SELECT saknr INTO TABLE g_it_account FROM skat.
SELECT * INTO TABLE g_it_skat FROM skat
FOR ALL ENTRIES IN g_it_account
      WHERE spras = 'E'
        AND ktopl = 'XXXX'
        AND saknr = g_it_account-saknr.
LOOP AT g_it_account INTO g_wa_account.
READ TABLE g_it_skat INTO g_wa_skat WITH KEY saknr = g_wa_account-saknr.
WRITE :/ g_wa_account-saknr, g_wa_skat-txt50.
CLEAR : g_wa_account, g_wa_skat.
ENDLOOP.
Thanks & Regards,
Dileep .C

Hi Dilip.
from you both the code I have found that you are selecting 2 diffrent fields.
In Code 1.
you are selecting SAKNR and then for these SAKNR you are selecting TXT50 from the same table.
and in Code 2 you are selecting all the fields from SAKT table for all the values of SAKNR.
I don't know whats your requirement.
Better you declare a select option on screen and then fetch required fields from SAKT table for the values entered on screen for SAKNR.
you only need TXT50 and SAKNR fields.
so declare two types one for SAKNR and another for TXT50.
Points to be remember.
1. while using for all entries always check the for all entries table should not be blank.
2. you will have to fetch all the key fields in table while applying for all entries,
    you can compare key fields with a constant which is greater than initial value.
3. while reading the table sort the table by the field on which you are going to read it.
try this:
TYPES : BEGIN OF ty_account,
saknr TYPE skat-saknr,
END OF ty_account.
TYPES : begin of T_txt50,
      saknr type saknr,
      txt50 type txt50,
end of t_txt50.
DATA: i_account type table of t_account,
      w_account type t_account,
      i_txt50 type table t_txt50,
      w_txt50 type t_txt50.
select SAKNR from SKAT into table i_account.
if sy-subrc = 0.
sort i_account by saknr.
select saknr txt50 from SKAT into table i_txt50
for all entries in i_account
where SAKNR = i_account-SAKNR
here mention al the primary keys and compare them with their constants.
endif.
Note; here you need to take care that, you will have to fetch all the key fields in table i_txt50.
and compare those fields with there constants which should be greater than initial values.
they should be in proper sequence.
now for writing.
loop at i_account into w_account.
clear w_txt50.
sort i_txt50 by saknr.
read table i_txt50 into w_txt50 with key SAKNR = w_account-saknr
if sy-subrc = 0.
write: w_txt50-saknr, w-txt50-txt50.
clear w_txt50, w_account.
endif.
endloop.
Hope it wil clear your doubts.
Thanks
Lalit

For all entries problem

Hi experts,
I have a below statement in my code
"SELECT on EKPO for all entries on ITAB (which is having 4 hundread thousand recods )"
giving dump saying "MEMORY_PGFREE_FAILED" and "Error releasing memory block in paging"
i need your suggestion to avoid the memory problem
"MEMORY_PGFREE_FAILED" ?
can we go ahead with EXTRACT logic, does this solve the memory problem?
thoughts will be appriciated,
Thanks,
Shaik bhasha

See the example code :
REPORT ZSPFLI LINE-SIZE 132 LINE-COUNT 65(3)
                                             NO STANDARD PAGE HEADING.
TABLES:SPFLI,SCARR, SFLIGHT, SBOOK.
SELECT-OPTIONS: MYCARRID FOR SPFLI-CARRID.
FIELD-GROUPS: HEADER, SPFLI_FG, SFLIGHT_FG, SBOOK_FG.
INSERT:
        SPFLI-CARRID
        SPFLI-CONNID
        SFLIGHT-FLDATE
        SBOOK-BOOKID
       INTO HEADER,
        SPFLI-CARRID
        SPFLI-CONNID
        SPFLI-CITYFROM
        SPFLI-AIRPFROM
        SPFLI-CITYTO
        SPFLI-AIRPTO
        SPFLI-DEPTIME
        SCARR-CARRNAME
      INTO SPFLI_FG,
        SFLIGHT-FLDATE
        SFLIGHT-SEATSMAX
        SFLIGHT-SEATSOCC
        SFLIGHT-PRICE
      INTO SFLIGHT_FG,
        SBOOK-BOOKID
        SBOOK-CUSTOMID
        SBOOK-CUSTTYPE
        SBOOK-SMOKER
       INTO SBOOK_FG.
SELECT * FROM SPFLI WHERE CARRID IN MYCARRID.
SELECT SINGLE * FROM SCARR WHERE CARRID = SPFLI-CARRID.
EXTRACT SPFLI_FG.
SELECT * FROM SFLIGHT
   WHERE CARRID = SPFLI-CARRID AND CONNID = SPFLI-CONNID.
    EXTRACT SFLIGHT_FG.
    SELECT * FROM SBOOK
           WHERE CARRID = SFLIGHT-CARRID AND
           CONNID = SFLIGHT-CONNID AND FLDATE = SFLIGHT-FLDATE.
      EXTRACT SBOOK_FG.
      CLEAR SBOOK.
    ENDSELECT.
    CLEAR SFLIGHT.
ENDSELECT.
CLEAR SPFLI.
ENDSELECT.
SORT.
LOOP.
AT SPFLI_FG.
    FORMAT COLOR COL_HEADING.
    WRITE: / SCARR-CARRNAME,
             SPFLI-CONNID, SPFLI-CITYFROM,
             SPFLI-AIRPFROM, SPFLI-CITYTO, SPFLI-AIRPTO, SPFLI-DEPTIME.
    FORMAT COLOR OFF.
ENDAT.
AT SFLIGHT_FG.
    WRITE: /15 SFLIGHT-FLDATE, SFLIGHT-PRICE, SFLIGHT-SEATSMAX,
               SFLIGHT-SEATSOCC.
ENDAT.
AT SBOOK_FG.
    WRITE: /30 SBOOK-BOOKID, SBOOK-CUSTOMID,
                 SBOOK-CUSTTYPE, SBOOK-SMOKER.
ENDAT.
ENDLOOP.

Facin problems in the 'Select... for all entries'

I am facing problem with this piece of code, please share ur thoughts on it. I have specified the inputs.
I am extracting the open items from the BSIS table for specified 3 account number.
Inputs to the prg:
field No. of values
r_bukrs 1
r_hkont 2
r_blart 6
r_budat date range of 1 yr
r_bldat nil
v_tosdef contain 1 account number
" In each FI document posted, one line will have the 'v_tosdef' account number and one account from the 'r_hkont' values."
So will this query efficient.
SELECT bukrs
 hkont
 gjahr
 belnr
 budat
 bldat
 xblnr
 blart
 shkzg
 dmbtr
 FROM bsis
 INTO TABLE i_bsis
 WHERE bukrs IN r_bukrs " Company code
 AND hkont = v_tosdef " Account number
 AND budat IN r_budat " Posting date
 AND bldat IN r_bldat " Document date
 AND blart IN r_blart. " Document type
IF sy-subrc <> 0.
 MESSAGE i003.
 STOP.
ENDIF.
*@ Collecting the BELNR & GJAHR From the extracted records
li_bsis[] = i_bsis[].
SORT li_bsis BY bukrs gjahr belnr.
DELETE ADJACENT
DUPLICATES FROM li_bsis
 COMPARING bukrs gjahr belnr.
IF NOT li_bsis[] IS INITIAL.
 SELECT bukrs
 hkont
 gjahr
 belnr
 budat
 bldat
 xblnr
 blart
 shkzg
 dmbtr
 FROM bsis
APPENDING TABLE i_bsis
 FOR ALL ENTRIES IN li_bsis
 WHERE bukrs = li_bsis-bukrs " Company code
 AND hkont IN r_hkont " Account number
 AND gjahr = li_bsis-gjahr " Fiscal year
 AND belnr = li_bsis-belnr. " Document num
BSIS table size around 86GB
primary index size aroung 33GB
and the index quality is 54%
the CBO shows less cost, but the actual runs takes too much disk read's / bgets..
Message was edited by:
 Sandy

Hi Sandy,
You indicated the size of the tables and index, what is the total number of records in your BSIS?
In your range tables, make sure they are postive formed.
Ex. r_bukrs : I EQ '1001', and not I NE '1000'.
You should consider coding your statements to check for input for bldat, code it with r_bldat and then another set without. It should be better performance to not have empty where conditions. So two routines, Selects with bldat and without.
Don't know if you have a Basis person to help analyze the performance, but you should look at the indexes in BSIS. You may have several indexes that contain some of your input fields but they may be spread across several indexes or there may be none. But say you have 5 indexes and it happens that just one of your parameters are in each of those indexes. Well, it can only use one index so while you think you are providing alot of parameters to help performance only one field is being used to access the index. What you need to do then is to find an index that has the most fields in your where clause and see if you can add to that, so long it's not an SAP index. If it's a z index consider adding additional fields to it, or consider creating a new index.
You can at least analyze the first Select in your DEV client. Run a trace, ST05 and then execute your code. It will show you which index it has used if any.
Also, look at the query values it is passing to the database. You said you get 6 M records on the first Select. This just seem like a lot of records, which is for just one account number (v_tosdef) along with the other parameters. I'm wondering if there's a problem with your input data. With 6M in your first table, your FOR ALL ENTRIES statement will be executed 1.2 million times. Tyically the database interface breaks down your Select-For All entries statement into 5 records per query. Again, run ST05 and you will see this.
In SE16, on your BSIS table, what is your count of records if you enter only the account number?
As a test, you might want to try entering all your parameters in SE16, run ST05 to trace the SQL to see what it is doing. You may have to kill your SE16 session or it may time out on you. You can stop your ST05 trace before your SE16 finishes and it will still show how SAP is going after the data and what index it used.
Let me know if this helped any.
Regards,
Filler

Duplicate entries missing using for all entries in select query.

Hi Gurus,
Is there any way to avoid missing duplicate entries in an internal table if you use for all entries in select statement?
Note : i am selecting two tables using non key fields and i have to aggregate the data. I want only 2 data fields and one amount field in my final internal table. I can add all the primary key fields into my internal table and collect my required fields in another table, but I just want to know is there any other way to avoid missing duplicate entries without adding all the key fields?
Regards,
Raghavendra

Hi,
Just check what are the other possible fields in the table which may be having
duplicate entries and make use of them in the selection accordingly.
You may not miss any entries unless there is any restriction on them.
You can better judge that in debugging mode while selecting data from that table.

Inner Join with For All Entries - Performance ?

I am using following the following Select using Inner join with For All Entries in.
 SELECT kebeln kebelp kvbeln kvbelp
 FROM ekkn AS k INNER JOIN ekbe AS b ON kebeln = bebeln
 AND kebelp = bebelp
 INTO TABLE gi_purchase
 FOR ALL ENTRIES
 IN gi_sales
 WHERE k~mandt EQ sy-mandt
 AND k~vbeln EQ gi_sales-vbeln
 AND k~vbelp EQ gi_sales-posnr
 AND b~budat EQ p_date.
If i am not doing inner join then I will have to do 2 select with for all entries in on ekkn and ekbe tables and then compare them.
I want to know which one has better performance
Inner join with for all entries in
 or
2 Selects with for all entries in

An Inner Join with for all entries should be done if you add this....
IF NOT gi_sales[] IS INITIAL.
SELECT k~ebeln k~ebelp k~vbeln k~vbelp
FROM ekkn AS k INNER JOIN ekbe AS b ON k~ebeln = b~ebeln
AND k~ebelp = b~ebelp
INTO TABLE gi_purchase
FOR ALL ENTRIES
IN gi_sales
WHERE k~mandt EQ sy-mandt
AND k~vbeln EQ gi_sales-vbeln
AND k~vbelp EQ gi_sales-posnr
AND b~budat EQ p_date.
ENDIF.
Also, while you use an index or the complete key for the SELECT, your not going to suffer from lack of performance -;)
Greetings,
Blag.

Which is better group by or for all entries in

Similar Messages

Maybe you are looking for