For all entries in source package merge
Hi experts,
I have one question regarding statement for all entries in source package where …..
Explanations:
Let’s say that my source package contains 2 types of data:
-type1
-type2
I would like to use the statement select from table into internal table
For all entries in source package
But the where statement changes depending on the data type (2 keys when data type is 1 and only 1 key when data type is 2) .
So that would be:
Type1:
Select fields
From table into internal table
Where field1 = source_package-field1
And field2 = source_package-field2.
Type2:
Select fields
From table into internal table
Where field1 = source_package-field1
How can I merge them?
Thanks.
Amine
Hi Amine,
Didn't try that before but there are some idea for you to reference.
I assume source_packet have a field which indicate the data type which call source_packet-dtype
1) Write SQL like this... (Notes: never try that, not sure if it will work)
Select fields
From table into internal table
Where ( source_packet-dtype = 1 and field1 = source_package-field1 and field2 = source_package-field2 )
OR ( source_packet-dtype = 2 and field1 = source_package-field1 ).
2) Try to split the source_packet into 2 itab, one contain type 1 and another contain type 2 data and then read with 2 sql and merge with appending key word, but this idea assume the record will be difference
Select fields
From table into internal table
Where field1 = itab_type1-field1
And field2 = itab_type1-field2.
Select fields
From table APPENDING internal table
Where field1 = itab_type2-field1
BTW, you may have better luck in the ABAP space.
Regards
Bill
Message was edited by: Chie Bill
Similar Messages
-
Question about statement for all entries
Hi Abap experts,
I have a question concerning the ABAP statement for all entries.
Explanations:
Let’s say that my source package (Source table) contains 2 types of data:
-type1
-type2
I would like to use the statement select from table into internal table
For all entries in source package
But the where statement changes depending on the data type (2 keys when data type is 1 and only 1 key when data type is 2) .
So that would be:
Type1:
Select fields
From table into internal table
Where field1 = source_package-field1
And field2 = source_package-field2.
Type2:
Select fields
From table into internal table
Where field1 = source_package-field1
How can I merge them assming that the field od data type is ftype?
Thanks.
AmineHi amine,
i think this is helpful for you.
there are 2 ways to use the for all entries...
1. with header line: this method is old one. in this method the internal table (ITAB) is automatically create workarea (WA) with same name, this method 1 drawback is there where we can use WA and ITAB confused that's why this is come difficult.
2. without header line : this is nowadays we can use this method. in this method we create separate ITAb and WA. very clear this method.
EXAMPLES:
1.WITH HEADER LINE METHOD:
PARAMETERS p_kunnr TYPE kna1-kunnr.
DATA:it_kna1 LIKE kna1 OCCURS 0 WITH HEADER LINE,
it_adrc LIKE adrc OCCURS 0 WITH HEADER LINE,
it_adr2 LIKE adr2 OCCURS 0 WITH HEADER LINE,
it_adr6 LIKE adr6 OCCURS 0 WITH HEADER LINE.
START-OF-SELECTION.
SELECT * FROM kna1 INTO TABLE it_kna1
UP TO 100 ROWS.
IF NOT it_kna1[] IS INITIAL.
SELECT * FROM adrc INTO TABLE it_adrc
FOR ALL ENTRIES IN it_kna1
WHERE addrnumber = it_kna1-adrnr.
ENDIF.
IF NOT it_adrc[] IS INITIAL.
SELECT * FROM adr2 INTO TABLE it_adr2
FOR ALL ENTRIES IN it_adrc
WHERE addrnumber = it_adrc-addrnumber.
ENDIF.
IF NOT it_adr2[] IS INITIAL.
SELECT * FROM adr6 INTO TABLE it_adr6
FOR ALL ENTRIES IN it_adr2
WHERE addrnumber = it_adr2-addrnumber.
ENDIF.
LOOP AT it_kna1.
READ TABLE it_adrc WITH KEY addrnumber = it_kna1-adrnr.
IF sy-subrc = 0.
ENDIF.
READ TABLE it_adr2 WITH KEY addrnumber = it_kna1-adrnr.
IF sy-subrc = 0.
ENDIF.
READ TABLE it_adr6 WITH KEY addrnumber = it_kna1-adrnr.
IF sy-subrc = 0.
ENDIF.
WRITE : it_kna1-kunnr, it_kna1-name1, it_adrc-city1, it_adrc-street, it_adrc-po_box_reg,
it_adr2-telnr_long, it_adr6-smtp_addr.
ENDLOOP.
2. WITH OUT HEADER LINE:
TABLES: KNA1 , ADRC.
DATA : IT_KNA1 TYPE STANDARD TABLE OF KNA1,
IT_ADRC TYPE STANDARD TABLE OF ADRC,
WA_KNA1 TYPE KNA1,
WA_ADRC TYPE ADRC.
DATA: BEGIN OF STRTYPE ,
CUSTMERNO LIKE KNA1-KUNNR,
FIRSTNAME LIKE KNA1-NAME1,
LASTNAME TYPE NAME2,
CITY TYPE ORT01,
STATE TYPE REGIO,
COUNTRY TYPE LAND1,
ADDRESS LIKE ADRC-ADDRNUMBER,
END OF STRTYPE.
DATA : IT_1 LIKE TABLE OF STRTYPE.
SELECT-OPTIONS K_kunnr FOR kna1-kunnr NO-EXTENSION.
SELECT * FROM KNA1 INTO TABLE IT_KNA1 WHERE KUNNR IN K_KUNNR.
IF NOT IT_KNA1[] IS INITIAL.
SELECT * FROM ADRC INTO WA_ADRC FOR ALL ENTRIES IN IT_KNA1 WHERE ADDRNUMBER = IT_KNA1-ADRNR.
ENDSELECT.
ENDIF.
LOOP AT IT_KNA1 INTO WA_KNA1.
READ TABLE IT_ADRC INTO WA_ADRC WITH KEY ADDRNUMBER = WA_KNA1-ADRNR.
IF SY-SUBRC = 0.
STRTYPE-ADDRESS = WA_ADRC-ADDRNUMBER.
ENDIF.
APPEND STRTYPE TO IT_1.
WRITE : / WA_KNA1-KUNNR, WA_KNA1-NAME1, WA_KNA1-NAME2, WA_KNA1-ORT01, WA_KNA1-REGIO, WA_KNA1-LAND1, WA_ADRC-ADDRNUMBER.
ENDLOOP.
regards,
roopa.k -
I was under the impression that, while getting data from database table 'for all entries' always imporves performance. Since we are not getting whole database table data. I was doing a select statement and I have used for all entries. I have only 20,000 records in the internal table. While selecting data from database table, it took more than one hour and timed out.
Latter, I hard coded some values and query worked and it just took few minutes.
So, do we need to avoid for all entries? What the best practice?
For more details Please check the code:
Source package has only 20,000 records and while getting data it timed out. So I commented for all entries and hardcoded the values. This time it took only few minutes. Can any one suggest the best practice for handling such things?
IF SOURCE_PACKAGE[] IS NOT INITIAL.
SELECT
CALMONTH
CALYEAR
COMPANY
/BIC/XPROF_CTR
PCOMPANY
/BIC/ZPRODASGN
/BIC/ZSLSRPTCD
CURKEY_TC
UNIT
GL_ACCOUNT
MATERIAL
FUNC_AREA
COSTCENTER
WBS_ELEMT
CURKEY_LC
/BIC/ZTEMPKEY
QUANTITY
/BIC/ZAMT_REP
/BIC/ZSALETYP
FROM
/BIC/AZGMROA1400
INTO TABLE IT_SOURCE_TMP
FOR ALL ENTRIES IN SOURCE_PACKAGE
WHERE
CALMONTH BETWEEN CMONTH1 AND CMONTH2 AND
CALYEAR = CURR_YEAR AND
COMPANY = SOURCE_PACKAGE-COMPANY AND
/BIC/XPROF_CTR = SOURCE_PACKAGE-/BIC/XPROF_CTR AND
PCOMPANY = SOURCE_PACKAGE-PCOMPANY AND
/BIC/ZPRODASGN = SOURCE_PACKAGE-/BIC/ZPRODASGN AND
/BIC/ZSLSRPTCD = SOURCE_PACKAGE-/BIC/ZSLSRPTCD AND
CURKEY_TC = SOURCE_PACKAGE-CURKEY_TC AND
UNIT = SOURCE_PACKAGE-UNIT AND
GL_ACCOUNT = SOURCE_PACKAGE-GL_ACCOUNT AND
MATERIAL = SOURCE_PACKAGE-MATERIAL AND
/BIC/ZSALETYP in ('TS', 'CG', 'IS', 'IC',
'TO', 'FG', 'OD', 'SS',
'RD', 'I3', 'D1', 'D2',
'D3', 'MS', 'PF', 'RA') .
FUNC_AREA = SOURCE_PACKAGE-FUNC_AREA AND
COSTCENTER = SOURCE_PACKAGE-COSTCENTER AND
WBS_ELEMT = SOURCE_PACKAGE-WBS_ELEMT AND
CURKEY_LC = SOURCE_PACKAGE-CURKEY_LC and
/BIC/ZACCOUNT = SOURCE_PACKAGE-/BIC/ZACCOUNT .
ENDIF.Hi,
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 small influence of the number of generated statements in the case of OR'ed taht an IN list should be used by
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 that the last setting generates several statements and combine them with a UNION ALL,
the first setting generates a statement with OR's (or uses IN list) 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
and myid = 72.
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| 1403| |
| 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.
From database point of view these settings kill performance when you have a lot of entries and/or
a lot of columns in your FAE_itab.
Said that, FAE i.e. can never be a replacement for joining big tables (think of having a table with thousands of records in a FAE table like you had)
If you say now that you completly threw away the FAE table of 20.000 entries it is no wonder
that it performs better. 20.000 records is not a small number if you create a lot of UNION's or OR's / IN lists that way!
Your original statement is a good example for the abuse of a FAE. In the SAP Notes this is the core problem with FAE besides empty FAE tables.
It's safe to use a FAE_itab table if the expected entries count is small (i.e. << 100).
What you have to decide is if it's more advantagous to
retrieve the FAE_tabs data once and executing other statements with the SAME FAE table in the same program to reuse it
or having additional roundtrips to the database if you don't use FAE tables at all
Bye
yk -
Performance Issue in Select Statement (For All Entries)
Hello,
I have a report where i have two select statement
First Select Statement:
Select A B C P Q R
from T1 into Table it_t1
where ....
Internal Table it_t1 is populated with 359801 entries through this select statement.
Second Select Statement:
Select A B C X Y Z
from T2 in it_t2 For All Entries in it_t1
where A eq it_t1-A
and B eq it_t1-B
and C eq it_t1-C
Now Table T2 contains more than 10 lac records and at the end of select statement it_t2 is populated with 844003 but it takes a lot of time (15 -20 min) to execute second select statement.
Can this code be optimized?
Also i have created respective indexes on table T1 and T2 for the fields in Where Condition.
Regards,If you have completed all the steps mentioned by others, in the above thread, and still you are facing issues then,.....
Use a Select within Select.
First Select Statement:
Select A B C P Q R package size 5000
from T1 into Table it_t1
where ....
Second Select Statement:
Select A B C X Y Z
from T2 in it_t2 For All Entries in it_t1
where A eq it_t1-A
and B eq it_t1-B
and C eq it_t1-C
do processing........
endselect
This way, while using for all entries on T2, your it_t1, will have limited number of entries and thus the 2nd select will be faster.
Thanks,
Juwin -
For all entries table handled by Tables parameter of Subroutine!
Hi....
See my code...
Dont leave as it seems very big code... Actually its very small one...
In sourse code of function module...
data:itab1 type standard table of <local structure of top include> with header line,
itab2 type standrad table of knvp with header line.
perform routine_data tables itab1
using p_var
Subroutine code, saved in F include of that function group...
form routine_data tables itab1 type standard table
using p_var
select * from <db table>
into corresponding fields of table itab
where <keyfield> = p_var.
endform.
Back to source cod eof Function module..
if sy-subrc is = 0.
select parvw kunn2 kunnr from knvp
into corresponding fields of table itab2 for all entries in itab1
where kunnr = itab1-kunnr
and ( parvw = 'WE' or parvw = 'RE' or parvw = 'RG').
endif.
This code is working fine......
==================Now coming to my problem==========================
In source code of function module...
data:itab1 type standard table of <local structure of top include> with header line,
itab2 type standrad table of knvp with header line.
perform routine_data tables itab1
using p_var
Subroutine code, saved in F include of that function group...
form routine_data tables itab1 type standard table
using p_var
select * from <db table>
into corresponding fields of table itab
where <keyfield> = p_var.
endform.
Function module source code...
perform routine2_data tables itab1
itab2.
F include coding part for above subroutine....
form routine2_data tables itab1 type standard table
itab2 type standard table
select parvw kunn2 kunnr from knvp
into corresponding fields of table itab2 for all entries in itab1
where kunnr = itab1-kunnr <-----causing error
and ( parvw = 'WE' or parvw = 'RE' or parvw = 'RG').
endform.
Giving error message....
>>> The specified type has no structure and therefore no component called 'KUNNR".....
So here the problem is there is a incorrect way to declare parameters....
Plz remind that SUBROUTINES OF FUNCTION MODULES SAVING IN INCLUDE PROGRAMS, because they making some deffenrce with normal external subroutines...
also...
Here for all entries is mandatory!
And Two sub routines are mandatory!
Thanks for your attention...
Naveen Inuganti.Hi ,
Use the below syntax to pass the tables as parameters
*The below perform is in the source code of the F.M
PERFORM goods_movement_post TABLES itab1
itab2
itab3
USING ls_goodsmvt_header
g_mov_code.
suppose u are using the itab1 & itab2 tables data to get the itab3 Data
And The below code is in the Frms include
FORM goods_movement_post
TABLES
pt_itab1 STRUCTURE vbak
pt_itab2 STRUCTURE vbap
pt_itab3 STRUCTURE bapiret2
USING
p_ls_goodsmvt_header STRUCTURE bapi2017_gm_head_01
p_g_mov_code.
ENDFORM
Thanks & Reagrds
Mallikharjuna Reddy -
For all entries changes the order of the itab
Hi Experts
In the following query i have used two internal tables namely it_first and it_zlist.
The material inwhich the it_zlist is different sorting order
After executing this query, the order of the material inwhich the it_first is different from the it_zlist.
What could be the reason, pls explain me on this.
select matnr test zsno ztnam from zmaster1
into corresponding fields of table it_first
for all entries in it_zlist
where matnr = it_zlist-matnr.
Thanks in advance.
Regards
Rajaramfor all entries u should specified all primary key.
sort by u condition.
Effect
If the addition FOR ALL ENTRIES is specified before the language element WHERE, then the components comp of the internal table itab can be used as operands when comparing with relational operators.
The internal table itab must have a structured line type and the component comp must be compatible with the column col.
The logical expression sql_cond of the WHERE condition can comprise various logical expressions by using AND and OR. However, if FOR ALL ENTRIES is specified, there must be at least one Comparison with a column of the internal table itab, which can be specified either statistically or dynamically (Release 6.40 and higher). In a statement with a SELECTstatement with FOR ALL ENTRIES, the addition ORDER BY can only be used with the addition PRIMARY KEY.
The whole logical expression sql_cond is evaluated for each individual line of the internal table itab. The resulting set of the SELECT statement is the union of the resulting sets from the individual evaluations. Duplicate lines are automatically removed from the resulting set. If the internal table itab is empty, the whole WHERE statement is ignored and all lines in the database are put in the resulting set.
Notes
In Release 6.10 and higher, the same internal table can be specified after FOR ALL ENTRIES and after INTO.
The addition FOR ALL ENTRIES is only possible before WHERE conditions of the SELECT statement.
If the additions PACKAGE SIZE or UP TO n ROWS are specified together with FOR ALL ENTRIES, they are not passed to the database system but are applied instead to the resulting set once all selected rows on the application server have been imported.
With duplicated rows in the resulting set, the addition FOR ALL ENTRIES has the same effect as if addition DISTINCT were specified in the definition of the selection quantity. Unlike DISTINCT, the rows are not deleted from the database system but are deleted on the application server from the resulting set.
Addition FOR ALL ENTRIES is only possible for WHERE conditions of the SELECT statement.
Example
Exporting all flight data for a specified departure city. The relevant airlines and flight numbers are first put in an internal table entry_tab, which is evaluated in the WHERE condition of the subsquent SELECT statement. -
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
JitendraHi,
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 -
Problem with FOR ALL ENTRIES IN
This is my simple source code.
TABLES: stpo.
DATA: t_stpo LIKE stpo OCCURS 0 WITH HEADER LINE,
t_stpo_itm LIKE stpo OCCURS 0 WITH HEADER LINE,
t_stpo-stlnr = '00000058'.
t_stpo-stlkn = '00000003'.
append t_stpo.
t_stpo-stlnr = '00000058'.
t_stpo-stlkn = '00000007'.
append t_stpo.
SELECT * FROM stpo INTO TABLE t_stpo_itm
FOR ALL ENTRIES IN t_stpo
WHERE stlnr = t_stpo-stlnr " BOM No.
AND stlkn <> t_stpo-stlkn. " BOM item node number
The output from this source including BOM item node number 00000003, 00000007 but at SQL stlkn <> t_stpo-stlkn doesn't effected.
Could Anyone please tell me why?
Are there something wrong?
Thank you in advance.Hi,
You can also Use ranges for Stlnr and Stlkn fields, instead of int table.
TABLES: stpo.
DATA: begin of t_stpo OCCURS 0.
stlnr like stpo-stlnr,
stlkn like stpo-stlkn,
end of t_stpo.
data t_stpo_itm LIKE stpo OCCURS 0 WITH HEADER LINE.
t_stpo-stlnr = '00000058'.
t_stpo-stlkn = '00000003'.
append t_stpo.
clear t_stpo.
t_stpo-stlnr = '00000058'.
t_stpo-stlkn = '00000007'.
append t_stpo.
clear t_stpo.
if not t_stpo[] is initial.
SELECT * FROM stpo INTO TABLE t_stpo_itm
FOR ALL ENTRIES IN t_stpo
WHERE stlnr = t_stpo-stlnr " BOM No.
AND stlkn <> t_stpo-stlkn. " BOM item node number
endif.
or you can simply write a select for STPO like this:
SELECT * FROM stpo INTO TABLE t_stpo_itm
WHERE stlnr = '00000058' " BOM No.
AND ( stlkn <> '00000007' or stlkn <> '00000003' ). " BOM item node number
regards,
Anji -
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 -
Hi All,
Below is the select query I have which is taking more time when the records in the internal table is touching to almost 2 million.
SELECT paledger vrgar versi
perio paobjnr pasubnr
belnr posnr gjahr perde
FROM ce1ec01
APPENDING TABLE t_ce1ec01 PACKAGE SIZE 10000
FOR ALL ENTRIES IN t_arixco2_tmp
WHERE paobjnr EQ t_arixco2_tmp-paobjnr
AND PERIO gt p_perio.
ENDSELECT.
The secondary index is created with fields PAOBJNR and PERIO fields.
I have used ST05 and it is using the secondary index.
Regards,
Pratyusha.the second thing (after Rob's suggestion) to do is to try it like this:
SELECT paledger vrgar versi
perio paobjnr pasubnr
belnr posnr gjahr perde
FROM ce1ec01
INTO TABLE t_ce1ec01
FOR ALL ENTRIES IN t_arixco2_tmp
WHERE paobjnr EQ t_arixco2_tmp-paobjnr
AND PERIO gt p_perio.
since the package size will not save memory for the FAE we can try it directly
since all the data is selected before the package size is applied in any case.
if this fails we have a configuration issue. (your memory demand is higher than what
your configuration allows). You have to think of alternative solutions than... e.g.
divide the entries in t_arixco2_tmp in packages and process one after the other with FAE.
Kind regrds,
Hermann -
LIKE in SELECT FOR ALL ENTRIES
Hello all,
select * from mara
into corresponding fields of tabel itab_mara
for all entries in table itab
where matnr LIKE itab-matnr.
for my requirement, I want to use the above statement. because in ITAB, i have MATNR with only 10 digit.
But the problem is system does not allow this syntax.
Do you have an idea which will avoid any other SELECT s and get away with it.
Thanks.Hi
Select Statements contd For All Entries
The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.
The plus
Large amount of data
Mixing processing and reading of data
Fast internal reprocessing of data
Fast
The Minus
Difficult to program/understand
Memory could be critical (use FREE or PACKAGE size)
Points to be must considered FOR ALL ENTRIES
Check that data is present in the driver table
Sorting the driver table
Removing duplicates from the driver table
Consider the following piece of extract
Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
The above mentioned can be more optimized by using the following code.
Sort int_cntry by cntry.
Delete adjacent duplicates from int_cntry.
If NOT int_cntry[] is INITIAL.
Select * from zfligh appending table int_fligh
For all entries in int_cntry
Where cntry = int_cntry-cntry.
Endif. -
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. -
Doubt regarding FOR ALL ENTRIES and INDEXES
Hi iam Aslam ..
and i have a doubt ..regrding .. .
1) what are the disadvs of using FOR ALL ENTRIES
2) what are the disadvs of using INDEXES
3) what is the disadvs of using Binary search ..
4) . how can u do performance tuning ...if u have more than one SELECT statements between ... Loop and Endloop .......
please answer to these questions or reply me to [email protected] ..
thanks in advance ..
byeHI
<b>1) what are the disadvs of using FOR ALL ENTRIES</b>
if there is no data available for you condition mentioned in the where condition then it will retrive all the data from the database table , which we don't want , but we can solve that easily
Ways of Performance Tuning
1. Selection Criteria
2. Select Statements
Select Queries
SQL Interface
Aggregate Functions
For all Entries
Select Over more than one Internal table
Selection Criteria
1. Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.
2. Select with selection list.
Points # 1/2
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
Select Statements Select Queries
1. Avoid nested selects
2. Select all the records in a single shot using into table clause of select statement rather than to use Append statements.
3. When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.
4. For testing existence , use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.
5. Use Select Single if all primary key fields are supplied in the Where condition .
Point # 1
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
FROM EKKO AS P INNER JOIN EKAN AS F
ON PEBELN = FEBELN.
Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.
Point # 2
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
Point # 3
To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields . In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.
Point # 4
SELECT * FROM SBOOK INTO SBOOK_WA
UP TO 1 ROWS
WHERE CARRID = 'LH'.
ENDSELECT.
The above code is more optimized as compared to the code mentioned below for testing existence of a record.
SELECT * FROM SBOOK INTO SBOOK_WA
WHERE CARRID = 'LH'.
EXIT.
ENDSELECT.
Point # 5
If all primary key fields are supplied in the Where condition you can even use Select Single.
Select Single requires one communication with the database system, whereas Select-Endselect needs two.
Select Statements contd.. SQL Interface
1. Use column updates instead of single-row updates
to update your database tables.
2. For all frequently used Select statements, try to use an index.
3. Using buffered tables improves the performance considerably.
Point # 1
SELECT * FROM SFLIGHT INTO SFLIGHT_WA.
SFLIGHT_WA-SEATSOCC =
SFLIGHT_WA-SEATSOCC - 1.
UPDATE SFLIGHT FROM SFLIGHT_WA.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
UPDATE SFLIGHT
SET SEATSOCC = SEATSOCC - 1.
Point # 2
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE CARRID = 'LH'
AND CONNID = '0400'.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE MANDT IN ( SELECT MANDT FROM T000 )
AND CARRID = 'LH'
AND CONNID = '0400'.
ENDSELECT.
Point # 3
Bypassing the buffer increases the network considerably
SELECT SINGLE * FROM T100 INTO T100_WA
BYPASSING BUFFER
WHERE SPRSL = 'D'
AND ARBGB = '00'
AND MSGNR = '999'.
The above mentioned code can be more optimized by using the following code
SELECT SINGLE * FROM T100 INTO T100_WA
WHERE SPRSL = 'D'
AND ARBGB = '00'
AND MSGNR = '999'.
Select Statements contd Aggregate Functions
If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.
Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )
Consider the following extract.
Maxno = 0.
Select * from zflight where airln = LF and cntry = IN.
Check zflight-fligh > maxno.
Maxno = zflight-fligh.
Endselect.
The above mentioned code can be much more optimized by using the following code.
Select max( fligh ) from zflight into maxno where airln = LF and cntry = IN.
Select Statements contd For All Entries
The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.
The plus
Large amount of data
Mixing processing and reading of data
Fast internal reprocessing of data
Fast
The Minus
Difficult to program/understand
Memory could be critical (use FREE or PACKAGE size)
Points to be must considered FOR ALL ENTRIES
Check that data is present in the driver table
Sorting the driver table
Removing duplicates from the driver table
Consider the following piece of extract
Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
The above mentioned can be more optimized by using the following code.
Sort int_cntry by cntry.
Delete adjacent duplicates from int_cntry.
If NOT int_cntry[] is INITIAL.
Select * from zfligh appending table int_fligh
For all entries in int_cntry
Where cntry = int_cntry-cntry.
Endif.
Select Statements contd Select Over more than one Internal table
1. Its better to use a views instead of nested Select statements.
2. To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.
3. Instead of using nested Select loops it is often better to use subqueries.
Point # 1
SELECT * FROM DD01L INTO DD01L_WA
WHERE DOMNAME LIKE 'CHAR%'
AND AS4LOCAL = 'A'.
SELECT SINGLE * FROM DD01T INTO DD01T_WA
WHERE DOMNAME = DD01L_WA-DOMNAME
AND AS4LOCAL = 'A'
AND AS4VERS = DD01L_WA-AS4VERS
AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
The above code can be more optimized by extracting all the data from view DD01V_WA
SELECT * FROM DD01V INTO DD01V_WA
WHERE DOMNAME LIKE 'CHAR%'
AND DDLANGUAGE = SY-LANGU.
ENDSELECT
Point # 2
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
FROM EKKO AS P INNER JOIN EKAN AS F
ON PEBELN = FEBELN.
Point # 3
SELECT * FROM SPFLI
INTO TABLE T_SPFLI
WHERE CITYFROM = 'FRANKFURT'
AND CITYTO = 'NEW YORK'.
SELECT * FROM SFLIGHT AS F
INTO SFLIGHT_WA
FOR ALL ENTRIES IN T_SPFLI
WHERE SEATSOCC < F~SEATSMAX
AND CARRID = T_SPFLI-CARRID
AND CONNID = T_SPFLI-CONNID
AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
The above mentioned code can be even more optimized by using subqueries instead of for all entries.
SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA
WHERE SEATSOCC < F~SEATSMAX
AND EXISTS ( SELECT * FROM SPFLI
WHERE CARRID = F~CARRID
AND CONNID = F~CONNID
AND CITYFROM = 'FRANKFURT'
AND CITYTO = 'NEW YORK' )
AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
1. Table operations should be done using explicit work areas rather than via header lines.
2. Always try to use binary search instead of linear search. But dont forget to sort your internal table before that.
3. A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.
4. A binary search using secondary index takes considerably less time.
5. LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.
6. Modifying selected components using MODIFY itab TRANSPORTING f1 f2.. accelerates the task of updating a line of an internal table.
Point # 2
READ TABLE ITAB INTO WA WITH KEY K = 'X BINARY SEARCH.
IS MUCH FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY K = 'X'.
If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).
Point # 3
READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.
Point # 5
LOOP AT ITAB INTO WA WHERE K = 'X'.
ENDLOOP.
The above code is much faster than using
LOOP AT ITAB INTO WA.
CHECK WA-K = 'X'.
ENDLOOP.
Point # 6
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.
The above code is more optimized as compared to
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1.
7. Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably
8. If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.
9. "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to LOOP-APPEND-ENDLOOP.
10. DELETE ADJACENT DUPLICATES accelerates the task of deleting duplicate entries considerably as compared to READ-LOOP-DELETE-ENDLOOP.
11. "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to DO -DELETE-ENDDO.
Point # 7
Modifying selected components only makes the program faster as compared to Modifying all lines completely.
e.g,
LOOP AT ITAB ASSIGNING <WA>.
I = SY-TABIX MOD 2.
IF I = 0.
<WA>-FLAG = 'X'.
ENDIF.
ENDLOOP.
The above code works faster as compared to
LOOP AT ITAB INTO WA.
I = SY-TABIX MOD 2.
IF I = 0.
WA-FLAG = 'X'.
MODIFY ITAB FROM WA.
ENDIF.
ENDLOOP.
Point # 8
LOOP AT ITAB1 INTO WA1.
READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.
IF SY-SUBRC = 0.
ADD: WA1-VAL1 TO WA2-VAL1,
WA1-VAL2 TO WA2-VAL2.
MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.
ELSE.
INSERT WA1 INTO ITAB2 INDEX SY-TABIX.
ENDIF.
ENDLOOP.
The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by
LOOP AT ITAB1 INTO WA.
COLLECT WA INTO ITAB2.
ENDLOOP.
SORT ITAB2 BY K.
COLLECT, however, uses a hash algorithm and is therefore independent
of the number of entries (i.e. O(1)) .
Point # 9
APPEND LINES OF ITAB1 TO ITAB2.
This is more optimized as compared to
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
Point # 10
DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.
This is much more optimized as compared to
READ TABLE ITAB INDEX 1 INTO PREV_LINE.
LOOP AT ITAB FROM 2 INTO WA.
IF WA = PREV_LINE.
DELETE ITAB.
ELSE.
PREV_LINE = WA.
ENDIF.
ENDLOOP.
Point # 11
DELETE ITAB FROM 450 TO 550.
This is much more optimized as compared to
DO 101 TIMES.
DELETE ITAB INDEX 450.
ENDDO.
12. Copying internal tables by using ITAB2[ ] = ITAB1[ ] as compared to LOOP-APPEND-ENDLOOP.
13. Specify the sort key as restrictively as possible to run the program faster.
Point # 12
ITAB2[] = ITAB1[].
This is much more optimized as compared to
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
Point # 13
SORT ITAB BY K. makes the program runs faster as compared to SORT ITAB.
Internal Tables contd
Hashed and Sorted tables
1. For single read access hashed tables are more optimized as compared to sorted tables.
2. For partial sequential access sorted tables are more optimized as compared to hashed tables
Hashed And Sorted Tables
Point # 1
Consider the following example where HTAB is a hashed table and STAB is a sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE HTAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
This runs faster for single read access as compared to the following same code for sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE STAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
Point # 2
Similarly for Partial Sequential access the STAB runs faster as compared to HTAB
LOOP AT STAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
This runs faster as compared to
LOOP AT HTAB INTO WA WHERE K = SUBKEY.
ENDLOOP. -
Unable to Get the Data Using For All Entries
Hi everybody, i am using for all entries in a program. but when i am writing a code using for all entries i am getting an error as
Where condition does not refers to the FOR ALL ENTRIES tables...
SELECT KUNNR
NAME1
ORT01
LAND1
FROM KNA1 INTO TABLE ITAB1 WHERE KUNNR IN S_KUNNR.
IF NOT ITAB1 IS INITIAL.
SELECT VBELN
ERDAT
KUNNR
FROM VBAK INTO TABLE ITAB2 FOR ALL ENTRIES IN ITAB1 WHERE KUNNR = IT_KNA1-KUNNR.
ENDIF.
can anybody help out in this
regards
hyder aliThe correct one may be like this:
SELECT KUNNR
NAME1
ORT01
LAND1
FROM KNA1 INTO TABLE ITAB1 WHERE KUNNR IN S_KUNNR.
IF NOT ITAB1 IS INITIAL.
SELECT VBELN
ERDAT
KUNNR
FROM VBAK INTO TABLE ITAB2 FOR ALL ENTRIES IN ITAB1 WHERE KUNNR = ITAB1-KUNNR. "modified here
ENDIF.
Edited by: XuJian84 on Mar 9, 2010 4:25 AM -
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_retrievalhi 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.
Maybe you are looking for
-
How do you set up and work single image variations?
Howdy Forum, My question is L4 workflow related. As everyone else, I select an image file and fiddled about in the `Develop` mode until I am happy with the result which is great. The modified image is in the catalog which is also great. On other occa
-
How to put variable value inside ora:parseEscapedXML ?
Hi, I am in a situation like I have a variable like temp that has value "runtime value". Now I want to put this temp variable like ora:parseEscapedXML('<data><xd:name="a"> <xd:value>temp</dsml:value></xd:name> </data>') But it shows temp as a String
-
Hi, i have got a macbook, 13" running with snowleopard 10.6.8 . I want to update to mountain lion - this does not work. How can i do it? Thanks for answering,
-
Attaching photos to text messages
My Torch will not send a text with a photograph. It has until just a few days ago. I have tried "rebooting" the phone more than once to no effect. It will send a text without a photograph without issue. What might have caused the change and how can I
-
I have an Apple ID that was set up when I first purchased my MacBook Pro and it's the same one I use for iTunes. After MobileMe was released, I set up a MobileMe account, within which the ID was set up by creating an @me.com address and password thu