Inner join and select for all entries with respect to performance in SAP

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?
Regards,
Dinesh

I did some testing a while ago and found that a JOIN is usually a bit more efficient than FOR ALL ENTRIES. This wasn't always the case though, so the best thing to do is to write it both ways and see which is faster.
Rob

Similar Messages

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.

Select For all entries with multiple keys

Dear Developers,
im writing a program which reads the last the last mseg entry with bwart 101 and bwart 201 an writes it into different fields of a table. In dependance of the bwart the max-value of mkpf-budat should be moved into field wedat or wadat.
At the moment i use this coding:
loop at gt_daten assigning <fs_daten>.
 select distinct max( budat ) from wb2_v_mkpf_mseg2 into <fs_daten>-wedat
 where matnr_i = <fs_daten>-matnr
 and werks_i = <fs_daten>-werks
 and lgort_i = <fs_daten>-lgort
 and bwart_i = '101'.
 select distinct max( budat ) from wb2_v_mkpf_mseg2 into <fs_daten>-wadat
 where matnr_i = <fs_daten>-matnr
 and werks_i = <fs_daten>-werks
 and lgort_i = <fs_daten>-lgort
 and bwart_i = '201'.
endloop.
wb2_v_mkpf_mseg2 is a view combining mkpf an mseg by primary keys.
Searching the internet i read, using FOR ALL ENTRIES should be prefered to selectstatements in loops.
So i tried:
*selectstatement
select budat matnr_i werks_i lgort_i bwart_i from wb2_v_mkpf_mseg2 into table lt_mseg for all entries in gt_daten
 where matnr_i = gt_daten-matnr
 and werks_i = gt_daten-werks
 and lgort_i = gt_daten-lgort
 and ( bwart_i = '101' or bwart_i = '201' )
*Substitute the MAX( )-Function
sort lt_mseg descending by matnr werks lgort bwart budat.
delete adjacent duplicates from lt_mseg comparing matnr werks lgort bwart.
*Differ between wedat and wadat
loop at gt_daten assigning <fs_daten>.
 loop at lt_mseg assigning <fs_mseg>
 where matnr = <fs_daten>-matnr
 and werks = <fs_daten>-werks
 and lgort = <fs_daten>-lgort.
 case <fs_mseg>-bwart.
 when '101'.
 <fs_daten>-wedat = <fs_mseg>-budat.
 when '201'.
 <fs_daten>-wadat = <fs_mseg>-budat.
 endcase.
 endloop.
Even in the dev-system this takes twice the time of the "nested" selects.
Imho this is because of the internal OR interpretation of the FOR ALL ENTRIES-statement and the size of the result.
Can somebody give me a hint, how to tune this code?
Select Inner join should be difficult because the target field differs, dependent of the value in bwart...
Thanks in advance!

I understand that you are trying to capture the maximum value of posting date MKPF-BUDAT for movement types 101 and 201 for each combination of material, plant and storage location.
Few things, that makes the below coding more efficient at both application and database level and I confirmed this on an IDES sandbox
1. Along with MKPF and MSEG, there is another table WBGT, in the view WB2_V_MKPF_MSEG join and also WBGT has select condition restrictions imposed on its fields. So if this restriction impacts your selection you may want to do a INNER JOIN of MSEG with MKPF only (with MSEG as leading table, as it has an active secondary index with MATNR, WERKS, LGORT and BWART ) and also there won't be overhead from the unnecessary join with WBGT table whose fields you are not using.
2. The below SORT on lt_mseg will ensure that the record having greatest BUDAT will be at the top of all rows (least index) for each combination of MATNR, WERKS, LGORT and BWART.
3. DELETE ADJACENT DUPLICATES will ensure that only the top row (having greatest BUDAT) remains in the table lt_mseg for each combination of MATNR, WERKS, LGORT and BWART. This will ensure that subsequent READs with BINARY SEARCH will always and efficiently read the row with maximum value of BUDAT for each unique combination of MATNR, WERKS, LGORT and BWART.
4. The below logic will require more memory (even though it is more efficient performance wise) compared to direct SELECT with MAX for each MATNR, WERKS, LGORT and BWART in a LOOP the way you were doing before. So if the size of lt_mseg is causing memory issues, your logic with aggregate function MAX at database level will be your only option.
So, I propose you revise your coding like below for most optimal results
CHECK NOT gt_daten[] IS INITIAL.
*selectstatement
*SELECT budat matnr_i werks_i lgort_i bwart_i
* FROM wb2_v_mkpf_mseg2
* INTO TABLE lt_mseg
* FOR ALL ENTRIES IN gt_daten
* WHERE matnr_i = gt_daten-matnr
* AND werks_i = gt_daten-werks
* AND lgort_i = gt_daten-lgort
* AND ( bwart_i = '101' OR bwart_i = '201' ).
* The below SELECT is more economical than the one commented above
SELECT mkpf~budat mseg~matnr mseg~werks mseg~lgort mseg~bwart
FROM mseg INNER JOIN mkpf
 ON mseg~mblnr = mkpf~mblnr AND
 mseg~mjahr = mkpf~mjahr
 INTO TABLE lt_mseg
 FOR ALL ENTRIES IN gt_daten
 WHERE mseg~matnr = gt_daten-matnr
 AND mseg~werks = gt_daten-werks
 AND mseg~lgort = gt_daten-lgort
 AND ( mseg~bwart = '101' OR mseg~bwart = '201' ).
*Substitute the MAX( )-Function
SORT lt_mseg BY matnr werks lgort bwart DESCENDING budat.
DELETE ADJACENT DUPLICATES FROM lt_mseg COMPARING matnr werks lgort bwart.
*Differ between wedat and wadat
LOOP AT gt_daten ASSIGNING <fs_daten>.
READ TABLE lt_mseg ASSIGNING <fs_mseg>
 WITH KEY matnr = <fs_daten>-matnr
 werks = <fs_daten>-werks
 lgort = <fs_daten>-lgort
 bwart = '101' BINARY SEARCH.
IF sy-subrc = 0.
 <fs_daten>-wedat = <fs_mseg>-budat.
ENDIF.
READ TABLE lt_mseg ASSIGNING <fs_mseg>
 WITH KEY matnr = <fs_daten>-matnr
 werks = <fs_daten>-werks
 lgort = <fs_daten>-lgort
 bwart = '201' BINARY SEARCH.
IF sy-subrc = 0.
 <fs_daten>-wadat = <fs_mseg>-budat.
ENDIF.
ENDLOOP.

Joins and use FOR ALL ENTRIES

Two questions :
(1) I use join with for all entries: the performance will go down?:
SELECT t1~MBLNR t1~MJAHR ZEILE BUDAT
INTO TABLE gt_mseg
FROM MSEG as T1 INNER JOIN MKPF AS T2
ON T1~MBLNR = T2~MBLNR and
 T2~MJAHR = T2~MJAHR
FOR ALL ENTRIES IN gt_coss
WHERE T1~MJAHR = gt_coss-GJAHR AND
 T1~AUFNR = gt_coss-aufnr AND
 ( BWART = '261' OR
 BWART = '262' ) AND
 T2~BUDAT IN r_budat.
(2) With "For all entries", if itab is too long, performance will go down?. In affirmative case. What can I do?

Hi Jose,
You'll have to make sure your global table gt_coss isn't empty.
A nasty little habit of the IN statement (for all entries is a kind of IN statement)
is that when it is empty, the system selekts all records.
You might know this when u use Select-Options in your statement (like r_budat).
Also there is an OSS note on he for all entries (531337) problems on i-series database.
Greetings Fred.

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

Loop -- Select, for all entries, HOW TO ?

Hi,
I have followoing code.
LOOP AT table ASSIGNING TO lt_all_roles_all_objects.
ENDSELECT.
ENDLOOP.
How to tune this? I don´t understand how and where to use the for all entries command.
And what will happen with my append?
Can somebody explain me?
Thanks

Hi,
First you need to know some of tips in abap so that you can give good shape to ur program according to performance wise.
--Try to avoid the joins and use FOR ALL ENTRIES IN in place of joins.
--Try to avoid the MOVE CORRESPONDING
--Dont use the loop statements with in loop.
-- Dont write the select statement with in loop.
-- Better use the read statement in side loop intead of loop in side loop.
-- Use alway BINARY SEARCH in READ statement- in this mandatory thing is u need to sorty the internal table a/c to with key conditions.
etc................. like this u need take care some of abap tips so that u can achieve good coding standards..
coming to your coding.............
declare an internal table "itab_agr_1250" which contain fields mandt, agr_name, object, and deleted .
SELECT mandt agr_name object deleted
 from agr_1250
 into itab_agr_1250
 where agr_name = <cust_tab>-rolename
 and mandt in sp_mandt
 and deleted = ''.
IF sy-subrc = 0.
sort itab_agr_1250 by agr_name.
ENDIF.
loop at table assigning <cust_tab>.
read table itab_agr_1250 with key agr_name = <cust_tab>-rolename
 BINARY SEARCH.
final_Itab-field1 = itab_agr_1250-.....
final_Itab-field2 = itab_agr_1250-.....
final_Itab-field3 = itab_agr_1250-..... { USE single filed assign or move statement for each field instead of MOVE CORRESPONDING }
append final_Itab.
endloop.
Reward with points if useful
Regards,
Vijay

For all entries with inner join

Hi All,
I found some unusual thing.
i have written INNERJOIN along with FOR ALL ENTRIES and also INNERJOIN in loop..endloop. I have tested both programs with around 1000 records, i found that INNERJOIN with FOR ALL ENTRIES is taking more time compared to the other one. As we know FOR ALL ENTRIES with SIMPLE SELECT takes less time compared to select in loop..endloop. Anybody tell me is there any specific reason for this
thanks in advance
rajavardhana reddy

Have a look at this weblog by Dharmaveer Singh:
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2986 [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken]
Sudha

Regarding SELECT FOR ALL ENTRIES AND DELETE ADJACENT DUPLICATES

Hi,
i got few doubts.....
    1) Is it necessary to DELETE ADJACENT DUPLICATES when we perform a SELECT FOR ALL ENTRIES ? because for all entries itself eliminates the duplicate entries?
   2) Wat Sy-subrc returns after a SELECT FOR ALL ENTRIES statement?
   I found some code where these are used
           SORT ITAB[] BY NEWKO[].
          DELETE ADJACENT DUPLICATES FORM ITAB[].
SELECT buknr
               kunnr
FORM KNB1
    into table ITAB_KNB1
FOR ALL ENTRIES IN ITAB
    where kunnr eq itab-newko.
Regards.
Maehsh.

Hi Mahesh,
To be more specific, first you should delete "adjacent duplicates" using the sorting key ( here : NEWKO ), if Itab contains other fields.
SORT ITAB[] BY NEWKO[].
DELETE ADJACENT DUPLICATES FORM ITAB COMPARING NEWKO.
You can delete or not the duplicates, but, you must know that if you don't delete them in the Itab, you will retrieve them in the ITAB_KNB1.
Concerning the return code, it works like for the "SELECT" ( 0 = entries found / 4 = no entrie found )
=> One more thing, it's better check :
Check not ITab[] is initial
because, if the Itab is empty, you'll retrieve all the record of KNB1 !
Hope this helps,
Erwan.
Message was edited by:
        Erwan LE BRUN

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

Regarding select for all entries

Hi all,
I want to use select for all entries....
because i have to club 3 tablese and get the data.
I can go for inner joins but i cant use because of performmance issues.
so can anybody help me regarding this.
thanks and regards,
giri.

do this way............
types: begin of gt_vbrk,
        vbeln type vbrk-vbeln,
        fkart type vbrk-fkart,
        knumv type vbrk-knumv,
        bukrs type vbrk-bukrs,
        waerk type vbrk-waerk,
        netwr type vbrk-netwr,
        end of gt_vbrk,
        begin of gt_vbrp,
        vbeln type vbrp-vbeln,
        posnr type vbrp-posnr,
        fkimg type vbrp-fkimg,
        meins type vbrp-meins,
        gsber type vbrp-gsber,
        netwr type vbrp-netwr,
        aubel type vbrp-aubel,
        aupos type vbrp-aupos,
        end of gt_vbrp,
        begin of gt_vbak,
        vbeln type vbak-vbeln,
        augru type vbak-augru,
        vkgrp type vbak-vkgrp,
        gsber type vbak-gsber,
        end of gt_vbak,
        begin of gt_vbap,
        vbeln type vbap-vbeln,
        posnr type vbap-posnr,
        matnr type vbap-matnr,
        netwr type vbap-netwr,
        end of gt_vbap,
data : git_vbrk type standard table of gt_vbrk,
      git_vbrp type standard table of gt_vbrp,
      git_vbak type standard table of gt_vbak,
      git_fcode type table of gt_fcode,
      git_vbap type table of gt_vbap.
data : wa_vbrk type gt_vbrk,
      wa_vbrp type gt_vbrp,
      wa_vbak type gt_vbak,
      wa_fcode type gt_fcode,
      wa_vbap type gt_vbap.
select vbeln
          fkart
          knumv
          bukrs
          waerk
          netwr
    from vbrk into table git_vbrk
    where vbeln in s_vbeln.
if sy-subrc eq 0.
    sort git_vbrk by vbeln.
endif.
if not git_vbrk[] is initial.
clear git_vbrp[].
select vbeln
          posnr
          fkimg
          meins
          gsber
          netwr
          aubel
          aupos
     from vbrp into table git_vbrp
     for all entries in git_vbrk
     where vbeln = git_vbrk-vbeln.
if sy-subrc eq 0.
    sort git_vbrp by vbeln.
endif.
select vbeln
          augru
          vkgrp
          gsber
    from vbak into table git_vbak
    for all entries in git_vbrp
    where vbeln = git_vbrp-aubel.
if sy-subrc eq 0.
    sort git_vbak by vbeln.
endif.
reward points if helpful............

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

Select FOR ALL ENTRIES statement cannot get duplicates entries

Hi all,
t_yxapy_fields consist of
inty field
0001 kostl
0002 perid
0008 ansal
0008 preas
0008 trfst
The following is the code for me to transfer the contents of t_yxapy_fields into t_pa_fields.
SELECT dbtab
      FROM t777d
      INTO TABLE t_pa_fields
      FOR ALL ENTRIES IN t_yxapy_fields
      WHERE infty = t_yxapy_fields-infty.
And t_pa_fields just ended up with
field   infty
pa0001
pa0002
pa0008
Question:The first table have 3 similar infotype 0008 but the result table only have one pa0008. I need to filled up acordingly as what table 1 have. I need another 2 pa0008 in my 2nd table. What is wrng with my Select for all entries statement here?
Edited by: Siong Chao on Mar 27, 2010 10:35 AM

This has nothing to do with duplicates in t777d.
Correct, I failed to recognize that table t777d has only infty as key as pointed out by Aby. Thus in your particular case my comment was misleading. In general though FOR ALL ENTRIES removes all duplicate rows from your result set.
If you want the other 2 values just loop t_yxapy_fields this table and read t_pa_fields and if record found add the other values to t_pa_fields table. --> will trigger performance tuning issue
I'm pretty sure if you'd code this, you won't run into any performance issues, so follow Aby's recipe. To be more concrete, here's what I'd do: Define a mapping table t777d_tab, which holds the translation from infty to dbtab:
types:
begin of T_T777D_VIEW,
    INFTY type T777D-INFTY,
    DBTAB type T777D-DBTAB,
end of T_T777D_VIEW.
data:
T777D_TAB type hashed table of T_T777D_VIEW with unique key INFTY.
Fill table t_pa_fields, typed using t_t777d_tab from above, from table t777d. Then loop over your table t_yxapy_fields (I'd use [LOOP AT ... ASSIGNING|http://help.sap.com/abapdocu_70/en/ABAPLOOP_AT_ITAB_RESULT.htm] instead of LOOP AT ... INTO) and for each entry get the corresponding DBTAB value from t777d_tab (again use the [READ TABLE ... ASSIGNING|http://help.sap.com/abapdocu_70/en/ABAPREAD_TABLE_OUTDESC.htm] variant) and build your result table t_pa_fields.
Anyhow, I suspect that even with less optimal coding (e.g. using just standard table for lookup of DBTAB values) you'd not see much of an performance impact, because it seems that your internal tables are most likely rather small...
Cheers, harald

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

Dynamic select for all entries?

Hi!
Is it possible to do a dynamic SELECT FOR ALL ENTRIES IN... command?
sg. like:
DATA:
 select_text TYPE string,
 from_text TYPE string,
 where_text TYPE string.
SELECT FOR ALL ENTRIES IN <gt_table1> (select_text)
into corresponding fields of table <gt_table2>
FROM (from_text)
WHERE (where_text).
Thanks and Best Regards,
Tamas

Hi,
you can use the Dynamic Selects for FOR ALL ENTRIES, but i think you may need to use the correct Internal table to match the tabel structure
Regards
Sudheer

Dynamic OpenSQL - SELECT FOR ALL ENTRIES ?

Hi!
Is it possible to do a dynamic SELECT FOR ALL ENTRIES IN... command?
sg. like:
DATA:
select_text TYPE string,
from_text TYPE string,
where_text TYPE string.
SELECT FOR ALL ENTRIES IN <gt_table1> (select_text)
into corresponding fields of table <gt_table2>
FROM (from_text)
WHERE (where_text).
Thanks and Best Regards,
Tamas

Hi
INSERT INTO (SELECT department_id, department_name, location_id
FROM departments WHERE location_id < 2000)
VALUES (9999, 'Entertainment', 2500);
Is this you are looking for ?
Regards
Vinod

Inner join and select for all entries with respect to performance in SAP

Similar Messages

Maybe you are looking for