About for all entries in itab usage issue

hi
i will get a lot of material information first.
the next i will get inforamtion about table MARC AND MBEW.
one statement i use sap function to get MARC:
CALL FUNCTION 'MARC_ARRAY_READ'
    EXPORTING
      KZRFB                = ' '
      NEUFLAG              = ' '
      SPERRMODUS           = ' '
      STD_SPERRMODUS       = ' '
      EXCEPTION_ON_LOCK    = ' '
    IMPORTING
      RETC                 = ret
    TABLES
      IPRE01               = ipre
      MARC_TAB             = disp
    EXCEPTIONS
      ENQUEUE_MODE_CHANGED = 1
      LOCK_ON_MARC         = 2
      LOCK_SYSTEM_ERROR    = 3
      OTHERS               = 4.
two statement if i use:
    select matnr dispo ekgrp plifz
into table disp
from marc
for all entries in ipre
where werks = ipre-werks and
        matnr = ipre-matnr.
which one will get better performce.
and
if ipre table have a lot of data, so in sap what about for all entries of Limit?
and will lose data to use for all entries of statements?
have function in sap to get data like 'MARC_ARRAY_READ' about MEBW.
THANK YOU!

thank you!
what about for all entries of Limit?
and will lose data to use for all entries of statements?
exist function about get MEBW ARRAY??

Similar Messages

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

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

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

Error - for all entries in itab

Hello guys !!!
I have the following select queries....
select * from vbrp into table itab.
select * from vbpa into table i_vbpa for all entries in itab
where VBELN = itab-vbeln and ( PARVW = 'Z2' or PARVW = 'Z3').
select belnr awkey from bkpf into table i_bkpf2 for all entries in itab where xblnr = itab-vbeln.
I get the following error in 3rd select query.....
When you use the addition "FOR ALL ENTRIES IN itab", the fields "XBLNR"
and "ITAB-VBELN" must have the same type and the same length.
But if i try to change the data type of the field ITAB-VBELN to - " VBELN(16) TYPE C " then i get the following error....
When you use the addition "FOR ALL ENTRIES IN itab", the fields "VBELN"
and "ITAB-VBELN" must have the same type and the same length.
How to i solve this problem ?????

Hi,
This is because XBLNR is 16 char length and VBELN is of 10.
So before passing itab to 3 query;
select belnr awkey from bkpf into table i_bkpf2 for all entries in itab where xblnr = itab-vbeln.
Create an intermediate itab with structure of vbeln with length 16 and transfer all data to this itab.
Then do as;
select belnr awkey from bkpf into table i_bkpf2 for all entries in itab where xblnr = itab1-vbeln.
Since you are using only vbeln in for all entries its even enough for the intermediate itab to have only one field to hold the values of VBELN. But you should add leading zeroes( by CONVERSION_EXIT_ALPHA_INPUT) before passing it in the query.
Regards
Karthik D

About for all entries

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

HI
GOOD
Use of FOR ALL Entries
Outer join can be created using this addition to the where clause in a select statement. It speeds up the performance tremendously, but the cons of using this variation are listed below
Duplicates are automatically removed from the resulting data set. Hence care should be taken that the unique key of the detail line items should be given in the select statement.
If the table on which the For All Entries IN clause is based is empty, all rows are selected into the destination table. Hence it is advisable to check before-hand that the first table is not empty.
If the table on which the For All Entries IN clause is based is very large, the performance will go down instead of improving. Hence attempt should be made to keep the table size to a moderate level.
Not Recommended
            Loop at int_cntry.
             Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
            Endloop.
Recommended
            Select * from zfligh appending table int_fligh
            For all entries in int_cntry
            Where cntry = int_cntry-cntry.
GO THROUGH THESE LINKS
http://www.thespot4sap.com/articles/SAPABAPPerformanceTuning_ForAllEntries.asp
CODE
Code to demonstrate Select FOR ALL ENTRIES command
The FOR ALL ENTRIES comand only retrieves data which matches
entries within a particular internal table.
TYPES: begin of t_bkpf,
include structure bkpf.
bukrs like bkpf-bukrs,
belnr like bkpf-belnr,
gjahr like bkpf-gjahr,
BLDAT like bkpf-BLDAT,
monat like bkpf-monat,
budat like bkpf-budat,
xblnr like bkpf-xblnr,
awtyp like bkpf-awtyp,
awkey like bkpf-awkey,
end of t_bkpf.
data: it_bkpf type standard table of t_bkpf initial size 0,
      wa_bkpf type t_bkpf.
TYPES: begin of t_bseg,
*include structure bseg.
bukrs     like bseg-bukrs,
belnr     like bseg-belnr,
gjahr     like bseg-gjahr,
buzei     like bseg-buzei,
mwskz     LIKE bseg-mwskz,         "Tax code
umsks     LIKE bseg-umsks,         "Special G/L transaction type
prctr     LIKE bseg-prctr,         "Profit Centre
hkont     LIKE bseg-hkont,         "G/L account
xauto     like bseg-xauto,
koart     like bseg-koart,
dmbtr     like bseg-dmbtr,
mwart     like bseg-mwart,
hwbas     like bseg-hwbas,
aufnr     like bseg-aufnr,
projk     like bseg-projk,
shkzg     like bseg-shkzg,
kokrs     like bseg-kokrs,
end of t_bseg.
data: it_bseg type standard table of t_bseg initial size 0,
      wa_bseg type t_bseg.
select bukrs belnr gjahr BLDAT monat budat xblnr awtyp awkey
up to 100 rows
from bkpf
into table it_bkpf.
if sy-subrc EQ 0.
select bukrs belnr gjahr buzei mwskz umsks prctr hkont xauto koart
         dmbtr mwart hwbas aufnr projk shkzg kokrs
    from bseg
    into table it_bseg
    FOR ALL ENTRIES in it_bkpf
    where bukrs eq it_bkpf-bukrs and
          belnr eq it_bkpf-belnr and
          gjahr eq it_bkpf-gjahr.
endif.
CODE
You can only use FOR ALL ENTRIES IN ...WHERE ...in a SELECT statement.
    SELECT ... FOR ALL ENTRIES IN itab WHERE cond returns the union of the solution sets of all SELECT
    statements that would result if you wrote a separate statement for each line of the internal table replacing the symbol
    itab-f with the corresponding value of component f in the WHERE condition.Duplicates are discarded from the result
    set. If the internal table itab does not contain any entries, the system treats the statement as though there were
    no WHERE cond condition, and selects all records (in the current client).
    for example:
       SELECT * FROM sflight INTO wa_sflight
                 FOR ALL ENTRIES IN ftab
                 WHERE CARRID = ftab-carrid AND
                  CONNID = ftab-connid AND
                         fldate = '20010228'.
    this condition, return all entries of the sflight
THANKS
MRUTYUN

FOR ALL ENTRIES IN Memory Dump Issue

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

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

For all entries in itab.....

Hi experts..
i hv select query which looks like this...
select field1 field2 into (itab-field1, itab-field2) from dbtab1
 where field1 in s_field1.
The problem is i hv to add another code
"for all entries in itab2
where field2 = itab2-field2"
 to this select query..
please advice how i can do this.....
Thanks in advance..
-Pranati..

Hi,
In the following piece of code,
select field1 field2 into (itab-field1, itab-field2) from dbtab1
for all entries in itab2
where field1 in s_field1
and field2 = itab2-field2.
change this to:
data: begin of itab1 occurs 0,
 field1 like dbtab1-field1,
 field2 like dbtab1-field2,
 end of itab1.
select field1 field2 into table itab1 from dbtab1
for all entries in itab2
where field1 in s_field1
and field2 = itab2-field2.
Hope this works.
Regards
Subramanian

"For All Entries in ITAB" -error

Hello!
                   I am new to this ABAP. I getting one error in Select query "For All Entries" keyword. My problem is,
        Iam taking vbeln field from the table LIPS and stored in internal table it_lips. and then based on this vbeln i am taking the material document no. field mblnr from MKPF table. The Common field present in this table is vbeln in LIPS and xblnr in MKPF.
my select query is,
                              select xblnr mblnr
        into corresponding fields of table it_mkpf
        from mkpf
        for all entries in it_lips
        where xblnr = it_lips-vbeln
        and blart = 'WL'.

Hi,
Use the below logic:
TYPES: BEGIN OF ty_mkpf,
        mblnr TYPE mblnr,
        xblnr TYPE xblnr1,
       END OF ty_mkpf.
TYPES: BEGIN OF ty_lips,
        vbeln TYPE vbeln_vl,
        vbeln1 TYPE xblnr1,
       END OF ty_lips.
DATA: git_mkpf TYPE STANDARD TABLE OF ty_mkpf,
            git_lips TYPE STANDARD TABLE OF ty_lips.
DATA: gwa_lips TYPE ty_lips.
SELECT vbeln FROM lips INTO TABLE git_lips
UP TO 5 ROWS.
LOOP AT git_lips INTO gwa_lips.
gwa_lips-vbeln1 = gwa_lips-vbeln.
MODIFY git_lips FROM gwa_lips.
ENDLOOP.
SELECT mblnr xblnr
INTO TABLE git_mkpf
FROM mkpf
FOR ALL ENTRIES IN git_lips
WHERE xblnr = git_lips-vbeln1
AND blart = 'WL'.

Issue with FOR ALL ENTRIES

Hi All,
I have used FOR ALL ENTRIES statement in while selecting data based on some other internal table (to avoid select within loop).
While using FOR ALL ENTRIES, the target table (internal table in which data is getting stored) is getting affected.
The other fields are becoming zero and several rows gets delerted from the internal table after performing select query.
How to avoid this bug?
Kindly help me out....
Regards
Pavan

hi after the for all entries statement did you used the read statement .
if not you will not get any data ..check this program..
tables:mara,marc.
data:begin of itab occurs 0,
     matnr like mara-matnr,
     end of itab.
data:begin of itab1 occurs 0,
     matnr like marc-matnr,
     werks like marc-werks,
     end of itab1.
select   matnr
      from mara
      into corresponding fields of table itab.
      if   itab is initial.
      select matnr
              werks
             from marc
             into table itab1
             for all entries in itab
             where matnr = itab-matnr.
             loop at itab1.
             read table itab with key matnr = itab-matnr.
             write:/ itab1-matnr,itab1-werks.
             endloop.
             endif.

Select... for all entries in...

Hi,
Can anybody help me to sort out this issue. This select should work. I m filling an itab with distinct pernr. in temp it should give all the records for which pernr should not be in itab.
report ZTEST4.
data : begin of ITAB occurs 0,
 PERNR like PA0001-PERNR,
 ename like pa0001-ename,
 end of ITAB.
data : temp like itab occurs 0 with header line.
clear : ITAB, TEMP.
refresh : ITAB,TEMP.
select distinct PERNR into table ITAB from PA0001 where PERNR le 10.
select PERNR ENAME into table TEMP from PA0001
for all entries in ITAB where pernr not in itab-pernr.
sort TEMP by PERNR.
break-point.

Hi Sagar,
If i understand it well, you exclude all PERNR LE 10.
But first things first.
You cannot use the FOR ALL ENTRIES in your case (it doesn't allow the operator "NOT IN").
Your code should be:
REPORT ztest4.
TYPES: BEGIN OF ty_itab,
 pernr TYPE persno,
 ename TYPE emnam,
 END OF ty_itab.
DATA : itab TYPE ty_itab occurs 0,
 wtab TYPE ty_itab.
CLEAR: itab,
 wtab.
SELECT pernr ename
 INTO TABLE itab
 FROM pa0001
 WHERE pernr LE 10
 ORDER BY pernr.
IF sy-subrc EQ 0.
DELETE ADJACENT DUPLICATES FROM itab COMPARING pernr.
ENDIF.
Regards,
Rob.

Dynamic SELECT with FOR ALL ENTRIES IN: take 2

Hello Xperts,
we are now having a bit of new trouble with the following SELECT ... special thanks to Raul and Suhas for their previous contributions.
FIELD-SYMBOLS:
 <itab1> TYPE standard table.
ASSIGN ATTR_T_I->* TO <itab1>.
 select
 FIELD1
 FIELD2
 from DBTAB1
 into CORRESPONDING FIELDS OF table <itab1>
 FOR ALL ENTRIES IN <itab1>
 where
 (condition).
ATTR_T_I is a static attibute of type table containing 10 records where all records have FIELD1 and FIELD2 empty.
The select finds in DBTAB1 entries fulfilling the 'condition' for 8 of the above 10 records in ATTR_T_I.
Hence, after the select 8 of the 10 records in ATTR_T_I have the fields FIELD1 and FIELD2 filled (ie not empty).
So far so good!
BUT: the 2 remaining records (i.e. those without entries in DBTAB1 fullfilling 'condition') have been deleted! Why? This is not what we want nor expected.
Any ideas out there how to fix this?
Thanx!

Martin Helmstein wrote:
> Yes, 'condition' contains all the key fields of DBTAB1.
Hi Martin,
It's not the Where condition fields i was talking about. I was referring to the Select fields, you have to SELECT all the keyfields when using FAE. Something like this:
SELECT key1 key2 ... keyn "all the key fields of the table
field1 field2 ... fieldn
FROM table
INTO CORRESPONDING FIELDS OF it_data
FOR ALL ENTRIES IN <itab>
WHERE (condition).
You can search in the forums for further details. It has been discussed many a times.
BR,
Suhas

Select for all entries+offset

Folks,
please find my code below:
SELECT partner bpkind FROM but000 INTO TABLE i_but000
    FOR ALL ENTRIES IN lt_cmst_rtcm_bw
    WHERE partner = lt_cmst_rtcm_bw-tk_partner_i+0(10).
    SORT i_but000 BY partner.
partner is of length 10, tk_partner_i is of length 32.
when i use this offset value for comparison, its giving me the correct output. no errors.
but am getting this warning:
Bei der Verwendung von FOR ALL ENTRIES wird die Längenangabe für "TK_PARTNER_I" in dieser Bedingung ignoriert.
Do i have to mind this warning??..
if this is to be considered, please suggest me an alternate solution to use "For all entries" in this case.
Thanks in advance..
Yog

>
yogaprakash srirangan wrote:
> Hi,
>
> Actually i am writing this code in CRM system's CMOD-User exit program.
>
> when i remove the offset i am getting this error:
>
> When using the addition "FOR ALL ENTRIES IN itab", the fields "PARTNER"     and "LT_CMST_RTCM_BW-TK_PARTNER_I" must have the same type and length.and length.
>
> but with offset its generating warning and internal table is getting filled..
>
> so can you please explain me on this?..
>
> Thanks,
> Yog
Wow! It seems you have indeed found a bug! With the length specification you get a warning, without you get an error!
I've also written a little test program
TYPES: BEGIN OF mandt_ty,
         mandt TYPE char6,
       END OF mandt_ty.
DATA: t_mandt TYPE STANDARD TABLE OF mandt_ty WITH NON-UNIQUE KEY mandt,
      l_mandt TYPE mandt_ty.
DATA: lt_t000 TYPE STANDARD TABLE OF t000 WITH NON-UNIQUE KEY mandt,
      ls_t000 TYPE t000.
l_mandt-mandt = '1201'.
INSERT l_mandt INTO TABLE t_mandt.
SELECT * FROM t000 INTO TABLE lt_t000 FOR ALL ENTRIES IN t_mandt WHERE mandt = t_mandt-mandt+1(3).
*SELECT * FROM t000 INTO TABLE lt_t000 FOR ALL ENTRIES IN t_mandt WHERE mandt = t_mandt-mandt.
LOOP AT lt_t000 INTO ls_t000.
WRITE: ls_t000-mandt.
ENDLOOP.
And it seems that the offset isn't being ignored. I've also done and SQL trace, and this confirms that the offset isn't being ignored - the SQL issued actually says SELECT WHERE "MANDT" = '020' even though I've set it in the table to be 1201.
So it seems that, at the moment, you can safely ignore the message. But if SAP ever enforce it, or they make it an error instead of a warning, there will be problems.
matt

For all entries or join

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

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

HOW TO PRINT THE MATTER IN FOR ALL ENTRIES

HI HOW T PRINT THE FOR ALL ENTRIES MATTER

Hi Naresh,
You can only use FOR ALL ENTRIES IN ...WHERE ...in a SELECT statement.
SELECT ... FOR ALL ENTRIES IN itab WHERE cond returns the union of the solution sets of all SELECT statements that would result if you wrote a separate statement for each line of the internal table replacing the symbol itab-f with the corresponding value of component f in the WHERE condition.Duplicates are discarded from the result set. If the internal table itab does not contain any entries, the system treats the statement as though there were no WHERE cond condition, and selects all records (in the current client).
For example:
SELECT * FROM sflight INTO wa_sflight
FOR ALL ENTRIES IN ftab
WHERE CARRID = ftab-carrid AND
CONNID = ftab-connid AND
fldate = '20010228'.
This condition, return all entries of the sflight.
When using FOR ALL ENTRIES the number of matching records is restricted to the number of records in the internal table. If the number of records in the database tables is too large then join would cause overheads in performance. Additionally a JOIN bypasses the table buffering.
Thanks,
Reward If Helpful.

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.

Alternative for / Problems with: "For all entries in data_package"

Hi Guys
I doing some ABAP in a Start Rotine in BW and would like to do the following:
select * from /BI0/PMATERIAL into table 0mat
for all entries in DATA_PACKAGE
where material = DATA_PACKAGE-/bic/zmaterial.
But I get the following error:
E:When using the addition "FOR ALL ENTRIES IN itab", the fields "MATERIAL" and "DATA_PACKAGE-/BIC/ZMATERIAL" must have the same type and length. and length.
ZMATERIAL:
- Length: 28
- Type: CHAR - Character String
ZMATERIAL:
- Length: 18
- Type: CHAR - Character String
According to the error message "For all entries" cannot be used in this case since the lengths are not identical, but is there an alternative way to do what I would like to do?
Thanks in advance, kind regards,
Torben

Hi
one thing you can try like this define one variable in other itab of same type
then loop at the first table and assign it to new field and modify the itab
then use this field with for all entries
Regards
Shiva

About for all entries in itab usage issue

Similar Messages

Maybe you are looking for