11-03-2008 10:02 AM
Moved by moderator. Please post in the correct forum
Hi,
I am using INTO CORRESPONDING FIELDS OF TABLE .... and it is taking a long time in a report.
WILL THIS APPROACH IMPROVE PERFORMANCE.
HOW to check it after implementing it.
If I use INTO TABLE INT_TAB
THEN I use
LOOP AT INT_TAB INTO WA_TAB
WA_TAB-FIELD1 = WA_TAB2-FIELD1
WA_TAB-FIELD2 = WA_TAB2-FIELD2
...
...
ENDLOOP.
11-06-2008 9:55 AM
do your own tests, and send me results if you can find an overhead. There is no remarkable overhead in database selects.
It is more a problem in buffer selects because they are much faster.
I can not say much on old releases, maybe it was not as good as it is.
Siegfried
11-03-2008 10:05 AM
HI
it would be better for u to avoid the corresponding fields stmt.
Instead u can decalre your structure in the corect format and use into table INT_TAB
Regards
Winnie
11-03-2008 10:06 AM
It is always recommended to use INTO TABLE instead of INTO CORRESPONDING FIELDS OF TABLE for performance.
For INTO TABLE see to it that the internal table is declared in the same sequence as of the fields that you are selecting from the SELCT query.
You can check the performance using tcode 'ST05'. Activate the SQL trace before executing the report. Once the report is executed deactivate it and display the trace. Here you will come to know the time taken by each select query in your program.
11-03-2008 10:07 AM
Yes definately.
INTO CORRESPONDING FIELDS OF is not advisable as it degrades the performance of the query
11-03-2008 10:08 AM
It is not a good programming practice to ise INTO CORRESPONDING FIELDS OF because when you use this addition of the select staement then internally it has to compare each and every field and then it has to transfer the data from database to internal table so inorder to improve the perfomance
Declare a structure with the required fields
Create a INternal table
Populate the values into the internal table by using INTO TABLE which is other addition of select statement
11-03-2008 10:12 AM
Yes, What they said is absolutely right..
We should avoid the use of INTO CORRESPONDING FIELDS OF .. as it is not recommended performance wise..
Insted of that pass into individual variables or declare one structre and pass into it..
Regards,
Sunil Kumar Mutyala
11-03-2008 10:12 AM
Hi,
using into corresponding fields of table is not good according to performance.
instead move field by field as below,
Move : itab-field1 to itab1-field1,
itab-field2 to itab1-field2.
Thanks & Regards
Sudheer
11-03-2008 10:13 AM
we should avoid using Corresponing fields of statement for Performance point of view. instead declare the structure with the same table field sequence and then use into table i_tab.
if u want to assign these value to new internal table then
u can use MOVE statement or Itab1[] = itab2[].
Edited by: nilanjana sinha on Nov 3, 2008 11:13 AM
Edited by: nilanjana sinha on Nov 3, 2008 11:14 AM
11-03-2008 10:14 AM
SELECT * INTO CORRESPONDING FIELDS is not a performance problem, as long as you declare a target structure with only the required fields.
If you trace such an Open SQL statement in ST05, you will see that the "*" has been replaced with the actual field list.
There is maybe a 0,1% performance gain, so not worth thinking about it.
Your performance problem is likely due to something else in your code...run an SE30 to find out.
Thomas
11-03-2008 12:23 PM
only the last comment is correct, the INTO CORRESPONDING is NOT A PROBLEM with a select on a not buffered table.
The problem must be the select itself!
Siegfried
11-05-2008 4:16 AM
Hi ,
Never use into corresponding fields. Reduces performace,
Use into table.
Tks,
Krishna
11-05-2008 2:27 PM
Just to throw some gasoline on the fire:
When I took one of the ABAP courses (I apologize for not remembering which one), one of the performance recommendations was "do not use INTO CORRESPONDING FIELDS OF..."
It always seemed to me that the benefits of programming simplicity outweighed any performance degradation, and when I did some testing it showed that any performance hit was minimal.
Still, it used to be the SAP standard.
Rob
11-06-2008 9:55 AM
do your own tests, and send me results if you can find an overhead. There is no remarkable overhead in database selects.
It is more a problem in buffer selects because they are much faster.
I can not say much on old releases, maybe it was not as good as it is.
Siegfried