Standard and sorted itab

what is the diff between standard and sorted itab

Hi Abhay,
check the following explanation.
Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPENDstatement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option (BINARY) with key access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERTstatement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHEREcondition.
Hope this helps.
Regards,
kinshuk

Similar Messages

Diff btwn STANDARD and SORTED tbls??

Hi Experts,
Just curious to know that, In Wht scenarios/requiremets, we need to create a internal table, like fillowing(or How they differ from TYPE STANDARD TABLE OF)??
it_a504 TYPE SORTED TABLE OF a504 WITH UNIQUE KEY kunnr prodh.
 wa_a504 TYPE a504,.
thanq
Message was edited by:
 Srikhar

mainly performance reason ,if you use sorted internal table then it will have good performance than standard intentable
The internal tables could be catogrised into two.
indexed : standard and sorted tables.
nonindexed: hash tables.
standard table: it is the one we use generally.In this the data is not sorted and the only thing we can do is just process the data with out any restriction on it.
sorted tables: it works in two different manner.
 Frist one: is similar to standard table but the only difference is the data will be filled in a particular manner either ascending or descending.
 Second one: u can also fill the table keeping any field as primary key.now the data will be filled based on that particular key.
Hash tables: u can use this when u want to fill your internal table avoiding the duplication of data.it never permits the duplicate record to be stored in a internal table
Thanks
seshu

Sort itab stable

Hi,
can you please explain me diffrence between Sort itab stable and sort itab using simple example.
Regards,
Suresh.

1 3
2 2
1 3
1 2
2 3
SORT ITAB STABLE always gives the output same
1 2
1 3
1 3
2 2
2 3
but SORT ITAB gives
1 2
1 3
1 3
2 2
2 3
or
1 3
1 3
1 2
2 2
2 3
or
1 3
1 2
1 3
2 3
2 2

Creation of Sorted and Standard and Hashed Internal Tables ..

Hi ..
Pls specify me.. how to create .. sorted ,Standard and Hashed Internal Tables...
pls give me the full code regarding ...this ..
Thnks

Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.
Hashed tables
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
Special Features of Standard Tables
Unlike sorted tables, hashed tables, and key access to internal tables, which were only introduced in Release 4.0, standard tables already existed several releases previously. Defining a line type, table type, and tables without a header line have only been possible since Release 3.0. For this reason, there are certain features of standard tables that still exist for compatibility reasons.
Standard Tables Before Release 3.0
Before Release 3.0, internal tables all had header lines and a flat-structured line type. There were no independent table types. You could only create a table object using the OCCURS addition in the DATA statement, followed by a declaration of a flat structure:
DATA: BEGIN OF <itab> OCCURS <n>,
<fi> ...
END OF <itab>.
This statement declared an internal table <itab> with the line type defined following the OCCURS addition. Furthermore, all internal tables had header lines.
The number <n> in the OCCURS addition had the same meaning as in the INITIAL SIZE addition from Release 4.0. Entering 0 had the same effect as omitting the INITIAL SIZE addition. In this case, the initial size of the table is determined by the system.
The above statement is still possible in Release 4.0, and has roughly the same function as the following statements:
TYPES: BEGIN OF <itab>,
<fi> ...,
END OF <itab>.
DATA <itab> TYPE STANDARD TABLE OF <itab>
WITH NON-UNIQUE DEFAULT KEY
INITIAL SIZE <n>
WITH HEADER LINE.
In the original statement, no independent data type <itab> is created. Instead, the line type only exists as an attribute of the data object <itab>.
Standard Tables From Release 3.0
Since Release 3.0, it has been possible to create table types using
TYPES <t> TYPE|LIKE <linetype> OCCURS <n>.
and table objects using
DATA <itab> TYPE|LIKE <linetype> OCCURS <n> WITH HEADER LINE.
The effect of the OCCURS addition is to construct a standard table with the data type <linetype>. The line type can be any data type. The number <n> in the OCCURS addition has the same meaning as before Release 3.0. Before Release 4.0, the key of an internal table was always the default key, that is, all non-numeric fields that were not themselves internal tables.
The above statements are still possible in Release 4.0, and have the same function as the following statements:
TYPES|DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
WITH NON-UNIQUE DEFAULT KEY
INITIAL SIZE <n>
WITH HEADER LINE.
They can also be replaced by the following statements:
Standard Tables From Release 4.0
When you create a standard table, you can use the following forms of the TYPES and DATA statements. The addition INITIAL SIZE is also possible in all of the statements. The addition WITH HEADER LINE is possible in the DATA statement.
Standard Table Types
Generic Standard Table Type:
TYPES <itab> TYPE|LIKE STANDARD TABLE OF <linetype>.
The table key is not defined.
Fully-Specified Standard Table Type:
TYPES <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
WITH NON-UNIQUE <key>.
The key of a fully-specified standard table is always non-unique.
Standard Table Objects
Short Forms of the DATA Statement :
DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>.
DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
WITH DEFAULT KEY.
Both of these DATA statements are automatically completed by the system as follows:
DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
WITH NON-UNIQUE DEFAULT KEY.
The purpose of the shortened forms of the DATA statement is to keep the declaration of standard tables, which are compatible with internal tables from previous releases, as simple as possible. When you declare a standard table with reference to the above type, the system automatically adopts the default key as the table key.
Fully-Specified Standard Tables:
DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
WITH NON-UNIQUE <key>.
The key of a standard table is always non-unique.
Internal table objects
Internal tables are dynamic variable data objects. Like all variables, you declare them using the DATA statement. You can also declare static internal tables in procedures using the STATICS statement, and static internal tables in classes using the CLASS-DATA statement. This description is restricted to the DATA statement. However, it applies equally to the STATICS and CLASS-DATA statements.
Reference to Declared Internal Table Types
Like all other data objects, you can declare internal table objects using the LIKE or TYPE addition of the DATA statement.
DATA <itab> TYPE <type>|LIKE <obj> WITH HEADER LINE.
Here, the LIKE addition refers to an existing table object in the same program. The TYPE addition can refer to an internal type in the program declared using the TYPES statement, or a table type in the ABAP Dictionary.
You must ensure that you only refer to tables that are fully typed. Referring to generic table types (ANY TABLE, INDEX TABLE) or not specifying the key fully is not allowed (for exceptions, refer to Special Features of Standard Tables).
The optional addition WITH HEADER line declares an extra data object with the same name and line type as the internal table. This data object is known as the header line of the internal table. You use it as a work area when working with the internal table (see Using the Header Line as a Work Area). When you use internal tables with header lines, you must remember that the header line and the body of the table have the same name. If you have an internal table with header line and you want to address the body of the table, you must indicate this by placing brackets after the table name (<itab>[]). Otherwise, ABAP interprets the name as the name of the header line and not of the body of the table. You can avoid this potential confusion by using internal tables without header lines. In particular, internal tables nested in structures or other internal tables must not have a header line, since this can lead to ambiguous expressions.
TYPES VECTOR TYPE SORTED TABLE OF I WITH UNIQUE KEY TABLE LINE.
DATA: ITAB TYPE VECTOR,
JTAB LIKE ITAB WITH HEADER LINE.
MOVE ITAB TO JTAB. <- Syntax error!
MOVE ITAB TO JTAB[].
The table object ITAB is created with reference to the table type VECTOR. The table object JTAB has the same data type as ITAB. JTAB also has a header line. In the first MOVE statement, JTAB addresses the header line. Since this has the data type I, and the table type of ITAB cannot be converted into an elementary type, the MOVE statement causes a syntax error. The second MOVE statement is correct, since both operands are table objects.
plz reward if useful

Itab and sorting efficiency

Hi,
I only want the earliest date of a date field (non unique) in the database table...
my way of doing...
1) create a standard itab with only the date field.
2) select all the records for that date field into the itab.
3) collect into another standard itab with same structure to remove duplicates.
4) sort the itab in acsending.
5) read from the itab with index 1.
any other better ways in terms of performance or code efficiency?
if i do the sort in the select statement (eg. order by), it would be slower right?
Thanks,
Charles
abap newbie

Hi,
It depends on the type of table you use.
1)With a COLLECT for standard tables, a hash function is created internally. Using this hash function results in good performance. The hash function for standard tables is, however, non-persistent, since it is destroyed by each INSERT, DELETE, and so on; after which performance is reduced with a COLLECT all fields that are not part of the key must have a numeric type.
2)With the COLLECT statement, the contents of the work area is added to an entry with the same key or added to the table as a new entry. This allows you to create aggregated internal tables, thereby reducing data volume.COLLECT searches in the internal table for a data record according to the table type and defined key. If it finds an entry in the table, it adds all numeric fields of the work area or header that are not part of the key to the corresponding fields of the entry. If no entry is found, the contents of the work area or header row are added as a new table entry.You can only use the COLLECT statement with internal tables whose non-key fields are all numeric (type I, P, or F). If not, you get a syntax error. From SAP Basis release 4.0A, the table key may contain numeric fields.
The COLLECT statement is internally optimized for standard tables so that the response time is constant. This optimization applies as long as the tables are not modified with DELETE, INSERT, or SORT (non-persistent hash function). Using the latter instructions loses the rapid internal access, and leads to linearly increasing access costs for the COLLECT.
3)With hashed and sorted tables, the cost of the COLLECT statement is constant, even if you use DELETE, INSERT or SORT.
For the DELETE ADJACENT DUPLICATES the internal table should be sorted one before you write the statement.
Thanks,
Balaji

How to use field-symbols in MODIFY ... TRANSPORTING and SORT

Hi,
I need to increase the performance of an abap report using the field-symbols. More exactly the code is the following.
TYPES:
BEGIN OF itab_structure.
 INCLUDE STRUCTURE nameofstructure.
TYPES:
 RECNO LIKE sy-tabix,
END OF itab_structure.
DATA:
itab TYPE STANDARD TABLE OF itab_structure
 WITH HEADER LINE
 WITH NON-UNIQUE DEFAULT KEY INITIAL SIZE 0.
SORT itab ASCENDING BY f1.
LOOP AT itab WHERE f1 = '10'.
 itab-fn= value-n.
MODIFY itab
 TRANSPORTING fx fy fz ft
 WHERE f1 = c1_filed AND
 f2 = c2_field.
ENDLOOP.
I need your suggestions in this kind of conversion or solution.
SORT itab ASCENDING BY f1 (<-- I don't know if in this case the better performances should be obtained using field symbols and in which way)
FIELD-SYMBOLS: <fs_itab_line> TYPE LINE OF itab.
LOOP AT itab ASSIGNING <fs_itab_line> WHERE
<fs_itab_line>-f1 = '10'.
MODIFY itab
 TRANSPORTING fx fy fz ft
 WHERE f1 = c1_filed AND
 f2 = c2_field.
(I don't know if in this case the better performances should be obtained using field symbols and in which way)
ENDLOOP.
I wish to implement the field symbols or the better performance in terms of execution time in all my abap code, where it is possible.
Any suggestion will be well appreciated.
Thanks in advance for your kind support.
Regards,
 Giovanni

Dear All,
I have appeciated your suggestions and I can conclude these points in my case:
1) The "sort" statement is not optimized in a different way using filed-symbols
2) The loop with "where" condition on a standard table is performed using filed-symbols
But ... my last point to investigate is about the statement MODIFY table TRANSPORTING f1, f2 WHERE conditions.
More exactly, in my code the execution logic of the abap code expects a global modification of the same table at the end of every (primary) loop, using the MODYFY statement.
In other words in my code I can locate two loops on the same table in the following logic:
LOOP AT table1 WHERE f1 = '10'. (#1)
 updates to table1
 set c1_filed, c2_filed
 LOOP AT table1. (#2)
 IF f1 = c1_filed AND
 f2 = c2_filed.
 table1-fx = 'x'.
 table1-fy = 'y'.
 table1-fz = 'z'.
 table1-ft = 't'.
 ENDIF.
 MODIFY table1.
 ENDLOOP. (#2)
ENDLOOP. (#1)
In better way (maybe more fast in terms of execution time) to modify a set of lines (MODIFY...TRANSPORTING...WHERE):
LOOP AT table1 WHERE f1 = '10'.
 table1-fx= 'x'.
 table1-fy= 'y'.
 table1-fz= 'z'.
 table1-ft= 't'.
 MODIFY itab
 TRANSPORTING fx fy fz ft
 WHERE f1 = c1_filed AND
 f2 = c2_field.
ENDLOOP.
My aim is to use field-symbols everywhere possible for speeding up the execution of my code,by maintaining this logic.
My proposal should be the following but I need your kind opinion.
FIELD-SYMBOLS: <fs_#1_line> TYPE LINE OF table1.
FIELD-SYMBOLS: <fs_#2_line> TYPE LINE OF table1.
LOOP AT table1 WHERE f1 = '10' ASSIGNING <fs_#1_line>. (#1)
 updates to table1
 set c1_filed, c2_filed
 LOOP AT table1 ASSIGNING <fs_#2_line>. (#2)
 IF <fs_#2_line>-f1 = c1_filed AND
 <fs_#2_line>-f2 = c2_filed.
 <fs_#2_line>-fx = 'x'.
 <fs_#2_line>-fy = 'y'.
 <fs_#2_line>-fz = 'z'.
 <fs_#2_line>-ft = 't'.
 ENDIF.
 ENDLOOP. (#2)
ENDLOOP. (#1)
Your kind support is very important for me.
Thanks in advance.
Regards,
 Giovanni

Can we pass IT table name dynamically to READ and SORT stmt

Hello All,
i have a requirement in which i am passing table name using a variable and want to read the same table: so my question is can we execute read and sort stmt with dynamic IT name. please see below for explaination.
v_itname = <it_2>.
now read using variable
READ table ( v_itname ) with key <field>.
and
SORT ( v_itname ) by (otab).
thanks
Mani

Hi ,
This can be done. Please refer to the codes below. Please note that the code will work if the itabs are of type standard table else it may dump.
You just need to replace the variables form the values from your internal table.
DATA: v_table1(10) TYPE c VALUE 'I_MARA',
 v_field(10) TYPE c VALUE 'MATNR',
 i_mara TYPE STANDARD TABLE OF mara.
FIELD-SYMBOLS : <fs_tab> TYPE STANDARD TABLE,
 <fs_field> TYPE ANY.
DATA: otab TYPE abap_sortorder_tab,
oline TYPE abap_sortorder.
SELECT * UP TO 10 ROWS
FROM mara
INTO TABLE i_mara.
IF sy-subrc = 0.
ASSIGN (v_table1) TO <fs_tab>.
IF sy-subrc = 0.
 oline-name = v_field.
 APPEND oline TO otab.
 SORT <fs_tab> BY (otab).
 READ TABLE <fs_tab>
 WITH KEY (v_field) = '000000000020000989' "
 BINARY SEARCH
 TRANSPORTING NO FIELDS.
 IF sy-subrc = 0.
 ENDIF.
ENDIF.
ENDIF.
Regards,
Dev.

Standard and Detailed Profitability

Hello Gurus
I am a newbie in HPCM.
I am aware that there are standard and detailed HPCM available,
standard HPCM uses Essbase while detailed HPCM uses a relational database.
What are the Pros and Cons and major differences for these two?
Thank you very much for your time!
Regards
K

Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be UNIQUE or NON-UNIQUE. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
http://help.sap.com/saphelp_erp2005/helpdata/en/fc/eb35de358411d1829f0000e829fbfe/frameset.htm
Please award points

COLLECT: Which table is better to use - STANDARD or SORTED?

Hello Performance gurus,
I read this curious fact about COLLECT statement:
In standard tables that are filled using COLLECT only, the entry is determined by a temporary hash administrator. The workload is independent of the number of entries in the table. The hash administrator is temporary and is generally invalidated when the table is accessed to be changed. If COLLECT statements are specified after an invalidation, a linear search of all table rows is performed. The workload for this search increases in a linear fashion in relation to the number of entries.
In sorted tables, the entry is determined using a binary search. The workload has a logarithmic relationship to the number of entries in the table.
In hashed tables, the entry is determined using the hash administrator of the table and is always independent of the number of table entries.
So does this mean if we're populating a table using COLLECT we should prefer STANDARD over SORTED(due to the HASH administration)? Is there any performance overload while setting up the temporary hash administrator for STANDARD tables?
Please enlighten me.
BR,
Suhas

Actually I have just noticed I already had created a test program for this somewhere in the past.
Here are the results:
STANDARD            1.091.295
SORTED              3.159.771
HASHED                994.101
If for the STANDARD table you somehow destroy the hash administration (in this case it was done in the beginning by APPENDing one record):
STANDARD            2.255.905
SORTED                 14.013
HASHED                  8.022
(this 2nd execution was with less rows that the 1st execution, otherwise for the standard table it would take too long).
So this does prove that standard tables can be faster than sorted tables in that special case, but again I would not rely on that.
Rui Dantas

SORT ITAB BY VARIABLE_NAME

hi,
i want to sort the int table with variable parameters, like VKBUR, BUDAT, VKORG, MATNR, etc.
for that ive created a char variable of 5 length (say CRIT) and assigned value based on selection criteria by the user.
Then, im using SORT ITAB BY CRIT. Its not getting sorted properly.
Any suggestions,
Regards,
Naveen

You can easily achieve it by using filed symbols.
Assign the field (upon which you require sorting) to field symbol<Fs> and then sort the table with (<Fs>)reference.
Sample code is given below for your help.
DATA: BEGIN OF x1 OCCURS 0,
 t1 TYPE string,
 t2 TYPE string,
 t3 TYPE string,
 END OF x1.
FIELD-SYMBOLS: <fs> TYPE ANY.
x1-t1 = 'B'.
x1-t2 = 'D'.
x1-t3 = '9'.
APPEND x1.
x1-t1 = 'C'.
x1-t2 = 'X'.
x1-t3 = '4'.
APPEND x1.
x1-t1 = 'F'.
x1-t2 = 'Y'.
x1-t3 = '6'.
APPEND x1.
LOOP AT x1.
WRITE: / x1-t1, ' ', x1-t2, ' ', x1-t3.
ENDLOOP.
SKIP 2.
* Sort by field T1
ASSIGN 't1' TO <fs>.
SORT x1 BY (<fs>).
LOOP AT x1.
WRITE: / x1-t1, ' ', x1-t2, ' ', x1-t3.
ENDLOOP.
skip 2.
* Sort by field T3
ASSIGN 't3' TO <fs>.
SORT x1 BY (<fs>).
LOOP AT x1.
WRITE: / x1-t1, ' ', x1-t2, ' ', x1-t3.
ENDLOOP.

Contacts Display and Sort by Company Name

I have over 1000 contacts in Outlook which synced wonderfully with my new iPhone.
Alas, I need to lookup and sort by Company Name. This is a VERY standard method for contacts. The options presented by iphone are first and last name, sigh and tech support had no suggestions and the helpful tech support genttleman could find no 3rd party applications which could help.
Help!
I relly like my iPhone, but I need to be able to look up contacts and notes by company.
Thanks

I have noticed something useful when entering contacts directly into my iPhone. When entering a contact that I want shown in the list by the company name, I enter the company name first (without entering the "first name" and "last name") and save it. If you do it that way, the little square where the photo would be will change from the blank head to some buildings, and the contact will be listed by the company name. You can then go back and edit to add a first and last name and it will stay listed by company name.
However, if you enter the last name, first name, and company name all at the same time it will list the entry by the "last name" instead of by the company.
For example, if I want my son's doctor's office to display as "Arizona Pediatrics" instead of "Dr. John Smith" in the contact list, I would enter the Arizona Pediatrics first, save, and then go back in and add the Dr. John Smith in the last name, first name fields.
I need to check the manual to see if this is detailed, as I stumbled on it accidentaly, but it's pretty useful.
-SB

Sort up and sort Down push buttons in module pool with table control wizard

hi,
i have created 2 buttons for Sort up and sort Down push buttons in module pool with table control wizard
please any one can help me.
regards

Hi
Following code is to enable and disable the tbl control using two buttons. Just alter the code and for each button write the sort code.
REPORT YJAN27_SCREEN                                               .
TABLES: SFLIGHT, YFLIGHT_28.
TYPES: BEGIN OF struct1,
      carrid like sflight-carrid,
      connid like sflight-connid,
      fldate like sflight-fldate,
       END OF struct1.
CONTROLS TBL1 TYPE TABLEVIEW USING SCREEN 2700.
DATA: OK_CODE LIKE SY-UCOMM,
      CARRID LIKE SFLIGHT-CARRID,                                    "cols in tbl ctrl
      CONNID LIKE SFLIGHT-CONNID,
      FLDATE LIKE SFLIGHT-FLDATE,
      itab TYPE TABLE OF STRUCT1 WITH HEADER LINE,
      cols like line of TBL1-COLS,
      FLAG TYPE I.
FLAG = 1.
CALL SCREEN 2700.
*&      Module STATUS_2700 OUTPUT
*       text
MODULE STATUS_2700 OUTPUT.
SET PF-STATUS 'BACK'.
* SET TITLEBAR 'xxx'.
ENDMODULE.                 " STATUS_2700 OUTPUT
*&      Module USER_COMMAND_2700 INPUT
*       text
MODULE USER_COMMAND_2700 INPUT.
OK_CODE = SY-UCOMM.
CASE OK_CODE.
WHEN 'BACK'.
    LEAVE PROGRAM.
WHEN 'DIS'.                                                         "write code for sort up
    loop AT TBL1-COLS INTO COLS.
       COLS-SCREEN-INPUT = 0.
        MODIFY TBL1-COLS FROM COLS.
    ENDLOOP.
    FLAG = 2.
WHEN 'ENA'.                                                       "write code for sort down
    loop AT TBL1-COLS INTO COLS.
        COLS-SCREEN-INPUT = 1.
        MODIFY TBL1-COLS FROM COLS.
    ENDLOOP.
    FLAG = 1.
ENDCASE.
ENDMODULE.                 " USER_COMMAND_2700 INPUT
*&      Module GET_DATA OUTPUT
*       text
MODULE GET_DATA OUTPUT.
select carrid connid fldate from SFLIGHT into table itab.
ENDMODULE.                 " GET_DATA OUTPUT
*&      Module POPULATE_TBL OUTPUT
*       text
MODULE POPULATE_TBL OUTPUT.
    MOVE-CORRESPONDING ITAB TO SFLIGHT.
ENDMODULE.                 " POPULATE_TBL OUTPUT
*&      Module CHANGE_SCREEN OUTPUT
*       text
MODULE CHANGE_SCREEN OUTPUT.    " use this module if you want to hide the other button
CASE FLAG.
WHEN 1.
    LOOP AT SCREEN.
      IF SCREEN-NAME = 'B_ENA'.
        SCREEN-INVISIBLE = 1.
         MODIFY SCREEN.
      ENDIF.
    ENDLOOP.
    LOOP AT SCREEN.
      IF SCREEN-NAME = 'B_DIS'.
        SCREEN-INVISIBLE = 0.
         MODIFY SCREEN.
      ENDIF.
   ENDLOOP.
WHEN 2.
    LOOP AT SCREEN.
      IF SCREEN-NAME = 'B_DIS'.
        SCREEN-INVISIBLE = 1.
        MODIFY SCREEN.
      ENDIF.
    ENDLOOP.
    LOOP AT SCREEN.
      IF SCREEN-NAME = 'B_ENA'.
        SCREEN-INVISIBLE = 0.
         MODIFY SCREEN.
      ENDIF.
   ENDLOOP.
ENDCASE.
ENDMODULE.                 " CHANGE_SCREEN OUTPUT
PROCESS BEFORE OUTPUT.
MODULE STATUS_2700.
MODULE CHANGE_SCREEN.     " use this if you want to display one button at a time
MODULE GET_DATA.
loop at itab WITH control TBL1.
    MODULE POPULATE_TBL.       " populate tbl ctrl
endloop.
PROCESS AFTER INPUT.
MODULE USER_COMMAND_2700.    " do the sort operations
loop at itab.
endloop.
Hope this helps
Regards,
Jayanthi.K

I spent ages renaming and sorting my holiday photos in correct order but when uploaded to print they reverted to the original name and order? How can I stop this happening?

I spent ages renaming and sorting my holiday photos in correct order but when uploaded to print they reverted to the original name and order? How can I stop this happening?

When you "rename" a photo in iPhoto you're adding a Title to the shot, not renaming the file. This si quite standard metadata in photography, but it appars that it's getting lost in the upload/at Snapfish process.
You can use the Titles as filenames if you export using the File -> Export command. It's one of the options in the export dialogue. You can upload the exported items.
Regards
TD

Sort itab by using field symbol

All,
I have a field symbol that pointing to a field value in work area of an internal table i_sort ( For example work area that contains the field name having a value MATNR' ( this decides only at runtime) )
My requirement is i need to sort another table for example i_tab (structure same as records in i_sort) using this field symbol.
Any Info?
a®

Hi,
Check the below report sorting table VBAP based on field VBELN dynamically.
Let me know if u need any clarification.
REPORT ZTEST1.
tables: dd03l.
field-symbols: <fs1> type any,
 <fs2> type any.
data:
 wa_1 type vbak,
 w_index type sy-index.
data:
itab like standard table of vbap,
ftab like standard table of dd03l.
select * from vbap into table itab
 up to 10 rows.
select single * from vbak into wa_1 where vbeln ne space.
assign wa_1-vbeln to : <fs1>,
 <fs2>.
do.
assign component sy-index of structure wa_1 to <fs1>.
if <fs1> = <fs2>.
 w_index = sy-index.
 exit.
endif.
enddo.
select *
from DD03L
into table ftab
where TABNAME eq 'VBAK'.
sort ftab by position.
read table ftab with key position = w_index into dd03l.
sort itab by (dd03l-FIELDNAME).
Thanks,
- Ram

Ways of building sort itabs

eg. is this way of doing correct for building sorted table?
will this lose the binary properties for quick access?
sort standard_itab by a b c.
sorteditab[] = standard_itab[]
or should it be this way? using insert?
loop at standard_itab into wa.
insert wa into sorteditab.
endloop.

Hi Charles,
This link: http://help.sap.com/saphelp_nw2004s/helpdata/en/fc/eb34d0358411d1829f0000e829fbfe/content.htm
soesn't specify anything about the type of tables when assigning.
So, your first code looks ok.
This code works fine for me:
REPORT ZTEST.
DATA: ftab TYPE SORTED TABLE OF f
           WITH NON-UNIQUE KEY table_line,
      itab TYPE standard TABLE OF i ,
      fl   TYPE f.
DO 3 TIMES.
INSERT sy-index INTO TABLE itab.
ENDDO.
sort itab.
LOOP AT itab INTO fl.
WRITE: / fl.
ENDLOOP.
ftab[] = itab[].
LOOP AT ftab INTO fl.
WRITE: / fl.
ENDLOOP.
Regards,
Ravi
Message was edited by:
        Ravi Kanth Talagana

Standard and sorted itab

Similar Messages

Maybe you are looking for