Buffering for all InfoObjects

Hi BW Team,
Where can i switch on number range buffering for all InfoObjects where a high number of tuples are loaded?
And also for number range buffering for dimensions.
Can anyone send the info on this ?
Best Regards,
--Laks.

Lakshmi,
Have a look at note 857998.
https://websmp108.sap-ag.de/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=857998&_NLANG=E
Aneesh

Similar Messages

Attr changes runs for all Infoobject in a process chain

Hi,
I have a process chain for the master data ( ATTR, TEXT and HIER),I want a Hierarchy/attribute change run like a last process in my chain and actives all the InfoObject and Hierarchy.
How can I carry out the structural changes for all InfoObject in a process chain?
Thanks!

yes but it requests me a variant. then a layout "execute infopackage", then the attr change doesn´t have Object.
I don´t know what I do?
This process actives all my ATTR and HIER in my chain???
Message was edited by: Victoria León

I bought new Macbook Pro 13" around two months before .My Apple ID is working on all other things except app store . It is buffering for a lot of time and lastly coming on screen " can not connect to app store " Please help me

I bought new Macbook Pro 13" around two months before .My Apple ID is working on all other things except app store . It is buffering for a lot of time and lastly coming on screen " can not connect to app store " Please help me

Have you tried repairing disk permissions : iTunes download error -45054

How to use single buffered table with FOR ALL ENTRIES KEYWORD

Hai,
I'm Using TJ02T Database table, It is single buffered table but at the same time I want to use FOR ALL ENTRIES KEYWORD , Please Help me.
Regards,
S.Janani

Hi,
FOR ALL ENTRIES will not depend on the buffering nature of the table. The single buffered table will only only buffer one record into memory. You can still use the statement to query the values, but it may have performance problems if the data volume is high since the records are not completely buffered into memory, the time will spent in getting data from DB.
Thanks..
Preetham S

Number range buffering for dimension tables (DIM IDs) and InfoObjects (SIDs

Hi BW Experts,
How to check whether this number range buffering for dimension tables (DIM IDs) and InfoObjects (SIDs) is Active or not ??
can you please provide me this technical information where to go and check in the system ?
Thanks in Advance.

The Early Watch report lists these because of the large number of rows in the MD/Dim tables. Keep in mind though, that Number Range buffering will really only help if you continue to generate a large volume of new SIDs or Dim IDs with ongoing loads, e.g.
If your transactions being loaded to a cube result in several thousand new rows being added a Dim table, then it makes sense to turn on Number Range buffering for that Dim ID. But if the transaction volume is only cause a few hundred DIM IDs to be added, buffering will not really get you anything.

Can I have TWO Extractors for ONE InfoObject ???

Hi all,
We have two extractors (Business Content & Generic Extractor for 0WBS_ELEMT_ATTR). Can we have these TWO extractors for 0WBS_ELEMT InfoObject. If yes, can I have the procedure, PLEASE ?
Thanks.

Hi Venkat,
You can try to use Flexible update. For this you will need to make your InfoObject an InfoProvider. See here for an example:
http://help.sap.com/saphelp_nw04/helpdata/en/87/3fdf9587f211d5b2ff0050da4c74dc/content.htm
Hope this helps...

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.

Schedule a Webi XIR2 report to run for all values of the prompt ...

Hi there,
Any ideea about if it's possible to schedule a Web Intelligence XIR2 report to automatically run for all 150 different prompt values in the LOV (and have 150 different instances)?
BOXIR2, Java deployment.
Many thanks.

You'd be scheduling the document 150 different times, each for one value of the LOV.
You'd use the ReportEngine (REBean) SDK to read the LOV values, then use the Enterprise SDK to schedule.
Here's a bit of code that illustrates how to schedule a Webi doc a single time with specified prompts. You'd do something similar, but iterate the prompt setting and scheduling:
    IInfoStore iStore = (IInfoStore) eSession.getService("InfoStore");
    ReportEngine reportEngine = ((ReportEngines) eSession.getService("ReportEngines"))
                                    .getService(ReportEngines.ReportEngineType.WI_REPORT_ENGINE);
    IInfoObjects objs = iStore.query("Select TOP 1 * From CI_INFOOBJECTS Where "
                                      + " SI_KIND='Webi' And SI_INSTANCE=0 "
                                      + " And SI_NAME = '" + reportName + "'");
    //============================================================================
    // Open Webi document, then get and set Prompts collection
    //============================================================================
    IWebi            webi    = (IWebi) objs.get(0);
    DocumentInstance di      = reportEngine.openDocument(webi.getID());
    Prompts          prompts = di.getPrompts();
    for(int i = 0, m = prompts.getCount() ; i < m ; i++) {
        Prompt prompt = prompts.getItem(i);
        String name   = prompt.getName();
        if("Enter value(s) for State:".equals(name)) {
            Lov lov = prompt.getLOV();
            lov.refresh();
            Values values = lov.getAllValues();
            prompt.enterValues(new ValueFromLov[] { values.getValueFromLov(0),
                                                    values.getValueFromLov(1)});
        } else if ("Enter Shop Id:".equals(name)) {
            prompt.enterValues(new String[] { "261" });
    //===========================================================================
    // Copy prompts over to InfoObject
    //===========================================================================
    PromptsUtil.populateWebiPrompts(prompts, webi);
    //===========================================================================
    // Schedule Webi report to run once now
    //===========================================================================
    webi.getWebiFormatOptions().setFormat(IWebiFormatOptions.CeWebiFormat.Webi);
    ISchedulingInfo schedInfo = webi.getSchedulingInfo();
    schedInfo.setRightNow(true);
    schedInfo.setType(CeScheduleType.ONCE);
    iStore.schedule(objs);
Sincerely,
Ted Ueda

For All Entries is NOT better than INNER JOIN in most cases

I quote from Siegfried Boes' excellent post here: Will writing an inner join be better or creating a view?
For all the FOR ALL ENTRIES lovers ... there is no proof for these reappearing recommendation.
There is nearly nobody who receives forum points, who recommends FOR ALL ENTRIES instead of Joins. What is the reason ???
It is easier to prove the opposite. A Join is a nested loop inside the database, a FOR ALL ENTRIES is partly outside of the database. FOR ALL ENTRIES works in blocks, joins on totals.
FOR ALL ENTRIES are not recommded on really large tables, because the chances are too high that
too many records are transferred.
People prefer FOR ALL ENTRIES, because JOINs are not so easy to understand. Joins can go wrong, but with a bit of understanding they can be fixed.
Some Joins are slow and can not be fixed, but then the FOR ALL ENTRIES would be extremely slow.
There are several kinds of views:
- projection views, i.e. only one table involved just fields reduced
- join views, several tables, joins conditions stored in dictionary
- materialized views, here the joined data are actually stored in the database. Storing and synchronisation has to be done manually.
Only the last one creates real overhead. It should be the exception.
Join Views and Joins are nearly identical. The view is better for reuse. The join is better in complicated, becuase if the access goes wrong, it can often be fixed by adding a hint. Hints can not be added to views.
Abraham Bukit points out:
If it is cluster table, (you can't use join). If it is buffered table, I would also say avoid join.
If they all are transaction table which are not buffered and are not cluster tables.
He further supports Siegfried's statement that FAE is easier to undestand than INNER JOINs.
Thomas Zloch says, regarding buffered tables:
At least think twice, maybe compare runtimes if in doubt.
So, unless someone has some EVIDENCE that FOR ALL ENTRIES is better, I don't think we want to see this discussed further.
Kind regards
Matt

To give food for thought here's an example I gave in a thread:
If you have a statement like
SELECT ... FOR ALL ENTRIES IN FAE_itab WHERE f = FAE_itab-f.
SAP sends it to the database depending how the parameter rsdb/prefer_union_all is set:
rsdb/prefer_union_all = 0 =>
SELECT ... WHERE f = FAE_itab[1]-f
          OR    f = FAE_itab[2]-f
          OR    f = FAE_itab[N]-f
You have some influence of the generated statement type: Instead of OR'ed fields an IN list can be used
if you have only a single coulmn N to compare:
rsdb/prefer_in_itab_opt parameter:
SELECT ... WHERE f IN (itab[1]-f, itab[2]-f, ..., itab[N]-f)
rsdb/prefer_union_all = 1 =>
SELECT ... WHERE f = FAE_itab[1]-f
UNION ALL SELECT ... WHERE f = FAE_itab[2]-f
UNION ALL SELECT ... WHERE f = FAE_itab[N]-f
see: Note 48230 - Parameters for the SELECT ... FOR ALL ENTRIES statement
As you can see for the 2nd parameter several statements are generated and combined with a UNION ALL,
the first setting generates statements with OR's (or uses IN if possible) for the entries in FAE_itab.
I give you a little example here (my parameters are set in a way that the OR's are translated to IN lists; i traced the execution in ST05)
Select myid into table t_tabcount from mydbtable
for all entries in t_table    " 484 entries
    where myid = t_table-myid .
ST05 trace:
|Transaction SEU_INT|Work process no 0|Proc.type DIA|Client 200|User |
|Duration |Obj. name |Op.    |Recs.|RC    |Statement|
| 640|mydbtable |PREPARE|   | 0|SELECT WHERE "myid" IN ( :A0 , :A1 , :A2 , :A3 , :A4 ) AND "myid" = :A5|
| 2|mydbtable |OPEN   |   | 0|SELECT WHERE "myid" IN ( 1 , 2 , 3 , 4 , 5 ) AND "myid" = 72 |
| 2.536|mydbtable |FETCH |    0| 1403|   |
| 3|mydbtable |REOPEN |   | 0|SELECT WHERE "myid" IN ( 6 , 7 , 8 , 9 , 10 ) AND "myid" = 72 |
| 118|mydbtable |FETCH | 0| |
| 2|mydbtable |REOPEN | | 0|SELECT WHERE "myid" IN ( 11 , 12 , 13 , 14 , 15 ) AND "myid" = 72     |
| 3|mydbtable |REOPEN | | 0|SELECT WHERE "myid" IN ( 475 , 476 , 477 , 478 , 479 ) AND "myid" = 72 |
| 94|mydbtable |FETCH | 0| 1403|   |
| 2|mydbtable |REOPEN |   | 0|SELECT WHERE "myid" IN ( 480 , 481 , 482 , 483 , 484 ) AND "myid" = 72 |
You see the IN list contained 5 entries each , wich made up about 97 statements for all 484 entries.
For every statment you have a single fetch operation wich means a separate access to the database.
If you would replace the FAE with a join you would only have one fetch to the database.
With the example above we can derive these observations:
1. From database point of view these settings kill performance when you access a big table and/or have a lot of entries or columns in your FAE_itab. Furthermore, you hide information what data you will access
at all and thus you block the database from creating a more efficient execution plan because it DOESN'T KNOW wich data you will select in the next step. I.e. it may be more efficient to scan the table in one shot instead of having many index accesses - but the database can make this decision only if it can examine ONE statement that has ALL the information of what data to retrieve.
2. A second impact is that with every statement execution you trigger the allocation of database resources
wich will contribute to the overhead described above.
Said that, FAE can never be a replacement for joining big tables (think of having a table with thousands of records in a FAE table )
Edited by: kishan P on Nov 2, 2010 2:16 PM - Format Fixed

Need help for finding objects impacted by size change for an infoobject

hi all,
need help for finding objects impacted by size change
for xxx infoobject, due to some requirements, the size to be changed from
char(4) to char(10), in the source database tables as well as adjustment
to be done in BI side.
this infoobject xxx is nav attribute of YYY as well as for WWW
infoobjects. and xxx is loaded from infopkg for www infoobject load.
now that i have to prepare an impact analysis doc for BI side.
pls help me with what all could be impacted and what to be done as a
solution to implement the size change.
FYI:
where used list for xxx infoobject - relveals these object types :
infocubes,
infosources,
tranfer rules,
DSO.
attribute of characteristic,
nav attribute,
ref infoobject,
in queries,
in variables

Hi Swetha,
You will have to manually make the table adjustments in all the systems using SE14 trans since the changes done using SE14 cannot be collected in any TR.
How to adjust tables :
Enter the table name in SE14. For ex for any Z master data(Say ZABCD), master data table name would be /BIC/PZABCD, text table would be /BIC/TZABCD. Similarly any DSO(say ZXYZ) table name would be /BIC/AZXYZ00 etc.
Just enter the table name in SE14 trans --> Edit --> Select the radio button "Save Data" --> Click on Activate & adjust database table.
NOTE : Be very careful in using SE14 trans since there is possibility that the backend table could be deleted.
How to collect the changes in TR:
You can collect only the changes made to the IO --> When you activate, it will ask you for the TR --> Enter the correct package name & create a new TR. If it doesn't prompt you for TR, just goto Extras --> Write transport request from the IO properties Menu screen. Once these IO changes are moved successfully, then the above proceduce can be followed using SE14 trans.
Hope it helps!
Regards,
Pavan

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

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

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

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

Joins And For all Enteries in Select Statement

Could you please tell me when there is a high amount of data which is being handled in the table, does the use of INNER JOINS and FOR ALL ENTERIES in SELECT Statement decreases the system performance? ?
Can you also let me know where can i get some tips regarding do's and dont's for ABAP Programming, I want to increase my system performance.
Currently the programs which are being used are taking a lot of time for execution...
Its very URGENT!

Hai Jyotsna
Go through the following Tips for improving Performence
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)
Some steps that might make FOR ALL ENTRIES more efficient:
Removing duplicates from the driver table
Sorting the driver table
If possible, convert the data in the driver table to ranges so a BETWEEN statement is used instead of and OR statement:
               FOR ALL ENTRIES IN i_tab
                  WHERE mykey >= i_tab-low and
             mykey <= i_tab-high.
Nested selects
The plus:
Small amount of data
Mixing processing and reading of data
Easy to code - and understand
The minus:
Large amount of data
when mixed processing isnt needed
Performance killer no. 1
Select using JOINS
The plus
Very large amount of data
Similar to Nested selects - when the accesses are planned by the programmer
In some cases the fastest
Not so memory critical
The minus
Very difficult to program/understand
Mixing processing and reading of data not possible
Use the selection criteria
SELECT * FROM SBOOK.
CHECK: SBOOK-CARRID = 'LH' AND
                  SBOOK-CONNID = '0400'.
ENDSELECT.
SELECT * FROM SBOOK
WHERE CARRID = 'LH' AND
        CONNID = '0400'.
ENDSELECT.
Use the aggregated functions
C4A = '000'.
SELECT * FROM T100
WHERE SPRSL = 'D' AND
        ARBGB = '00'.
CHECK: T100-MSGNR > C4A.
C4A = T100-MSGNR.
ENDSELECT.
SELECT MAX( MSGNR ) FROM T100 INTO C4A
WHERE SPRSL = 'D' AND
       ARBGB = '00'.
Select with view
SELECT * FROM DD01L
WHERE DOMNAME LIKE 'CHAR%'
        AND AS4LOCAL = 'A'.
SELECT SINGLE * FROM DD01T
    WHERE   DOMNAME    = DD01L-DOMNAME
        AND AS4LOCAL   = 'A'
        AND AS4VERS    = DD01L-AS4VERS
        AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
SELECT * FROM DD01V
WHERE DOMNAME LIKE 'CHAR%'
       AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
Select with index support
SELECT * FROM T100
WHERE     ARBGB = '00'
       AND MSGNR = '999'.
ENDSELECT.
SELECT * FROM T002.
SELECT * FROM T100
    WHERE     SPRSL = T002-SPRAS
          AND ARBGB = '00'
          AND MSGNR = '999'.
ENDSELECT.
ENDSELECT.
Select Into table
REFRESH X006.
SELECT * FROM T006 INTO X006.
APPEND X006.
ENDSELECT
SELECT * FROM T006 INTO TABLE X006.
Select with selection list
SELECT * FROM DD01L
WHERE DOMNAME LIKE 'CHAR%'
        AND AS4LOCAL = 'A'.
ENDSELECT
SELECT DOMNAME FROM DD01L
INTO DD01L-DOMNAME
WHERE DOMNAME LIKE 'CHAR%'
       AND AS4LOCAL = 'A'.
ENDSELECT
Key access to multiple lines
LOOP AT TAB.
CHECK TAB-K = KVAL.
ENDLOOP.
LOOP AT TAB WHERE K = KVAL.
ENDLOOP.
Copying internal tables
REFRESH TAB_DEST.
LOOP AT TAB_SRC INTO TAB_DEST.
APPEND TAB_DEST.
ENDLOOP.
TAB_DEST[] = TAB_SRC[].
Modifying a set of lines
LOOP AT TAB.
IF TAB-FLAG IS INITIAL.
    TAB-FLAG = 'X'.
ENDIF.
MODIFY TAB.
ENDLOOP.
TAB-FLAG = 'X'.
MODIFY TAB TRANSPORTING FLAG
           WHERE FLAG IS INITIAL.
Deleting a sequence of lines
DO 101 TIMES.
DELETE TAB_DEST INDEX 450.
ENDDO.
DELETE TAB_DEST FROM 450 TO 550.
Linear search vs. binary
READ TABLE TAB WITH KEY K = 'X'.
READ TABLE TAB WITH KEY K = 'X' BINARY SEARCH.
Comparison of internal tables
DESCRIBE TABLE: TAB1 LINES L1,
                TAB2 LINES L2.
IF L1 <> L2.
TAB_DIFFERENT = 'X'.
ELSE.
TAB_DIFFERENT = SPACE.
LOOP
AT TAB1.
    READ TABLE TAB2 INDEX SY-TABIX.
    IF TAB1 <> TAB2.
      TAB_DIFFERENT = 'X'. EXIT.
    ENDIF.
ENDLOOP.
ENDIF.
IF TAB_DIFFERENT = SPACE.
ENDIF.
IF TAB1[] = TAB2[].
ENDIF.
Modify selected components
LOOP AT TAB.
TAB-DATE = SY-DATUM.
MODIFY TAB.
ENDLOOP.
WA-DATE = SY-DATUM.
LOOP AT TAB.
MODIFY TAB FROM WA TRANSPORTING DATE.
ENDLOOP.
Appending two internal tables
LOOP AT TAB_SRC.
APPEND TAB_SRC TO TAB_DEST.
ENDLOOP
APPEND LINES OF TAB_SRC TO TAB_DEST.
Deleting a set of lines
LOOP AT TAB_DEST WHERE K = KVAL.
DELETE TAB_DEST.
ENDLOOP
DELETE TAB_DEST WHERE K = KVAL.
Tools available in SAP to pin-point a performance problem
·                The runtime analysis (SE30)
·                SQL Trace (ST05)
·                Tips and Tricks tool
·                The performance database
Optimizing the load of the database
Using table buffering
Using buffered tables improves the performance considerably. Note that in some cases a statement can not be used with a buffered table, so when using these statements the buffer will be bypassed. These statements are:
Select DISTINCT
ORDER BY / GROUP BY / HAVING clause
Any WHERE clause that contains a sub query or IS NULL expression
JOIN s
A SELECT... FOR UPDATE
If you wan t to explicitly bypass the buffer, use the BYPASS BUFFER addition to the SELECT clause.
Use the ABAP SORT Clause Instead of ORDER BY
The ORDER BY clause is executed on the database server while the ABAP SORT statement is executed on the application server. The database server will usually be the bottleneck, so sometimes it is better to move the sort from the database server to the application server.
If you are not sorting by the primary key ( E.g. using the ORDER BY PRIMARY key statement) but are sorting by another key, it could be better to use the ABAP SORT statement to sort the data in an internal table. Note however that for very large result sets it might not be a feasible solution and you would want to let the database server sort it.
Avoid the SELECT DISTINCT Statement
As with the ORDER BY clause it could be better to avoid using SELECT DISTINCT, if some of the fields are not part of an index. Instead use ABAP SORT + DELETE ADJACENT DUPLICATES on an internal table, to delete duplicate rows.
Thanks & regards
Sreenivasulu P

Load Same Text data for all language key

Hello Everyone,
I have a datasource with Material and Desc fields but no language key.I need to load the same desc into my infoobject for all the languages i am maintaining (EN/DE/IT/FR/PL). Is this possible?
Thanks,
Ajay.D

Hi Ajay,
you can load same description for all the languages by maintaining constant language value at Transfer rules/ Transformations.
but here you need to change the constant value for each language.
Ex, if you are loading for EN, maintain language as Constant "EN".
and then for DE, maintain language as Constant "DE".
but this is repetitive process, if new materials are added then need to load again.
Best Regards.
Edited by: Daya Sagar on Sep 16, 2009 11:16 AM

Attribute data load fails for 0RPA_MARM Infoobject

Hi BW experts,
Attribute data load to the infoobject 0RPA_MARM(not a infoprovider) is on yellow status for long time and after it is throwing the below error
Runtime Errors :UNCAUGHT_EXCEPTION
Except : CX_RSR_X_MESSAGE
I checked the forums for this issue but got the solution for target as infoprovider.
Please suggest.
Regards,
Leo.

Hi Leo,
Basically loading data into Master data Infoobject and making it InfoProvider are two different things. Loading data in Master data infoobject will be same for all the Infoobjects and when you make them as Infoprovider you will get an advantage of doing reporting directly on top of that Infoobject.
Regards,
Durgesh.

Buffering for all InfoObjects

Similar Messages

Maybe you are looking for