Sorting by various keys internal table

Hi All ,
There is a small confusion i am having in my mind so wanted to clear it
In my internal table i have 4 fields
1. Material no.
2.material plant no.
3.sold to party
4.ship to party
I need to read this internal table different times in different places based on various keys as like
Read itab with key material no BINARY SEARCH.
Read itab with key material plant no. BINARY SEARCH.
Read itab with key sold to party BINARY SEARCH.
Read itab with key ship to party BINARY SEARCH.
So my questions is shld i sort the table by each key sepertly before reading it
like this
sort itab by material no
Read itab with key material no BINARY SEARCH.
sort itab by material plant no
Read itab with key material plant no. BINARY SEARCH.
sort itab by sold to party
Read itab with key sold to party BINARY SEARCH.
sort itab by ship to party
Read itab with key ship to party BINARY SEARCH.
Or i can once sort table by material no material plant no sold to party ship to party
Please explain me how best this can be done and why?
Regards
Bhanu

your task is a bit strange and I guess the reason was giving by you:
> WHEN 'PROGRAM ID 'ABC ON SELECTION SCREEN '
> READ ITAB BY MATERIAL NO.
This looks to me as if you have to use onyl one read type per execution, depending to the
selection.
So it should be enough to sort once also depending on the selection.
To be on the safe side, it would better to split the whole program in different branches, such that
only one branch is used in one execution. Inside the branch there is the sort, the loop and the
respective read binary search inside.
Otherwise, if you really have to read in one program execution with 4 different keys inside one loop.
Then you must prepare 4 identical tables and sort them outside of the loop and use for each
read binary search the respectivly sorted table.
=> and please update to the new Netweaver release. 7.0 EhP 2 as soon as possible, there you can define different secondary keys, which solves your problem.
Siegfried

Similar Messages

Sort issue with an Internal table

Hi All,
I have an internal table with following format.
Invoice Item Amount
951 <Blank> 450.00
951 0010 1200.00
951 0020 1300.00
Now i need to display this internal table in such a way that,
Invoice Item Amount
951 0010 1200.00
951 0020 1300.00
951 <Blank> 450.00
How to sort for such requirements?
Basically, the item value is blank for Tax amount.
Hence in the report, the layout should show the details as above.... (Line item 1, 2...and at last Total Tax of all line items Amount).
Please Help me.....
Regards
Pavan

>
Pavan Sanganal wrote:
> Hi All,
>
> I have an internal table with following format.
>
> Invoice Item Amount
> 951 <Blank> 450.00
> 951 0010 1200.00
> 951 0020 1300.00
>
> Now i need to display this internal table in such a way that,
>
> Invoice Item Amount
> 951 0010 1200.00
> 951 0020 1300.00
> 951 <Blank> 450.00
>
>
> How to sort for such requirements?
>
> Basically, the item value is blank for Tax amount.
>
> Hence in the report, the layout should show the details as above.... (Line item 1, 2...and at last Total Tax of all line items Amount).
>
>
> Please Help me.....
>
> Regards
> Pavan
Add another column to the table, copy the item values into this column setting the tax line value to 9999, sort by this column.

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

Std Internal Tables

Hi, what are Standard Internal Tables and Standard reports, and can I have names of some 'Standard Internal Tables' and 'Standard Reports' plz ?
Thnx.

these are some of the standard reports\
REKH0004
   SAP demo program that shows how to do 2d        3D, and 4D graphics.
RGUGBR00
Substitution/Validation utility
RHGEN00
     Regen PD and PA inconsistencies
RHGRENZ0
   Delimit IT1000 and related 1001s. Program                     will            delete any 1001 infotypes whose start date is after the delimit date.
RHGRENZ1
Extend the end date on delimited records. Very useful when you delimit a bunch of records incorrectly, and need to change the end date.
RHGRENZ2
Delimit IT1001 only.
RKCTSEAR
Search source code for up to two strings. Also see RSRSCAN1 and RPR_ABAP_SOURCE_SCAN.
RPDTRA00
List all HR transactions.
RPR_ABAP_SOURCE_SCAN
Search ABAP code for a string. Has many more options for selecting the ABAPs to search than RSRSCAN1 or RKCTSEAR.
RPUAUD00
HR Report to list all logged changes for an employee. Uses the PCL4 Audit Cluster.
RPUAUDDL
HR Report to delete audit data from the PCL4 Audit Cluster.
RPUDELPN
Delete all info for an employee number, including cluster data and infotypes
RPUP1D00/10
View/Delete data from PCL1 Cluster
RPUP2D00/10
View/Delete data from PCL2 Cluster
RPUP3D00/10
View/Delete data from PCL3 Cluster
RPUP4D00/10
View/Delete data from PCL4 Cluster
RSABAPIV
Mass print/display of ABAP/4 help text
RSAVGL00
Table adjustment across clients
RSBDCBTC
Submit a BDC job with an internal batch number and wait for the end of the batch input session.
RSBDCDRU
Prints the contents of a Batch Input session. No options for error transactions only.
RSBDCOS0
Execute UNIX commands. Looks similar to the old SAPMSOS0 program that disappeared in 3.0
RSBDCSUB
Release batch input sessions automatically
RSBTCDEL
Clean the old background job records
RSSDOCTB
R/3 Table Manual - prints a list of all fields in the selected tables with the field name and the field documentation.
RSCLTCOP
Copy tables across clients
RSDBCREO
Clean batch input session log
RSINCL00
Extended program list
RSNASTED
Process message control output for entries in the NAST table
RSORAREL
Get the Oracle Release
RSPARAM
Display all instance parameters
RSPO0041
Removing old spooling objects
RSRSCAN1
Search source code for a given string. Will also search includes. Also see RKCTSEAR and RPR_ABAP_SOURCE_SCAN.
RSSNAPDL
Clean the old ABAP error dumps
RSTBSERV
Compare a contents of a table between clients
RSTXFCON
Converts SAPScript page formats
RSTXSCRP
Save a SAPScript layout set to disk, and load it back into SAP.
RSTXSCRP
Transport SAPscript files across systems
RSTXSCRP
Upload and download SAPScript layout sets
RSTXTPDF4
Pass the spool number of a report's output to this program to have the output converted to PDF format.
RSTXTRAN
Add standard texts to a transport so they can be moved between systems.
RSUSR003
Check the passwords of users SAP* and DDIC in all clients
RSUSR006
List users last login
RSWBO052
Change development class of a sapscript (provided by Alan Cecchini)
RSWBO060
put objects into a request and transport it to any other system
inernal tables
INTERNAL TABLES IN ABAP:
There are two ways of accessing the records in an internal table:
By copying individual records into a work area. The work area must be compatible with the line type of the internal table.
You can access the work area in any way, as long as the component you are trying to access is not itself an internal table. If one of the components is an internal table, you must use a further work area, whose line type is compatible with that of the nested table.
When you change the internal table, the contents of the work area are either written back to the table or added as a new record.
By assigning the individual data records to an appropriate field symbol. Once the system has read an entry, you can address its components directly via its address. There is no copying to and from the work area. This method is particularly appropriate for accessing large or complex tables.
If you want to read more than one record, you must use a LOOP... ENDLOOP structure. You can then change or delete the line that has just been read, and the system applies the change to the table body. You can also change or delete lines using a logical condition.
When you use the above statements with sorted tables, you must ensure that the sort sequence is maintained.
Within a loop, the INSERT statement adds the data record before the current record in the table. If you want to insert a set of lines from an internal table into another index table, you should use the INSERT LINES OF variant instead.
When you read single data records, you can use two further additions:
In the COMPARING addition, the system compares the field contents of a data record with those in the work area for equality.
In the TRANSPORTING addition, you can restrict the data transport to selected fields.
Other statements for standard tables
SORT [ASCENDING|DESCENDING]
[BY [ASCENDING|DESCENDING] ..
[ASCENDING|DESCENDING]][AS TEXT] [STABLE].
These statements sort the table by the table key or the specified field sequence. If you do not use an addition, the system sorts ascending. If you use the AS TEXT addition, character fields are sorted in culture-specific sequence. The relative order of the data records with identical sort keys only remain constant if you use the STABLE addition.
APPEND INTO SORTED BY .
This statement appends the work area to the ranked list in descending order. The ranked list may not be longer than the specified INITIAL SIZE, and the work area must satisfy the sort order of the table.
The statements listed here can be used freely with both standard and sorted tables.
When you change a single line, you can specify the fields that you want to change using the TRANSPORTING addition. Within a loop, MODIFY changes the current data record.
If you want to delete a set of lines from an index table, use the variant DELETE FROM... TO.. or WHERE... instead of a loop. You can program almost any logical expression after WHERE.
The only restriction is that the first field in each comparison must be a component of the line structure (see the corresponding Open SQL statements). You can pass component names dynamically.
If you want to delete the entire internal table , use the statement CLEAR .
In the LOOP AT... ENDLOOP structure, the statements within the loop are applied to each data record in turn. The INTO addition copies entries one at a time into the work area.
The system places the index of the current loop pass in the system field sy-tabix. When the loop has finished, sy-tabix has the same value that it had before the loop started.
Inserting and deleting lines within a loop affects the following loop passes.
Access to a hashed table is imple mented using a hash algorithm. Simplified, this means that the data records are distributed randomly but evenly over a particular memory area.. The addresses are stored in a special table called the hashing table .
There is a hash function, which determines the address at which the pointer to a data record with a certain key can be found. The function is not injective, that is, there can be several data records stored at a single address. This is implemented internally as a chained list. Therefore, although the system still has to search sequentially within these areas, it only has to read a few data records (usually no more than three). The graphic illustrates the simplest case, that is, in which there is only one data record stored at each address.
Using a hash technique means that the access time no longer depends on the total number of entries in the table. On the contrary, it is always very fast. Hash tables are therefore particularly useful for large tables with which you use predominantly read access.
Data records are not inserted into the table in a sorted order. As with standard tables, you can sort hashed tables using the SORT statement:
SORT [ASCENDING|DESCENDING]
[BY [ASCENDING|DESCENDING] ..
[ASCENDING|DESCENDING]][AS TEXT].
Sorting the table can be useful if you later want to use a loop to access the table.
You can use the statements listed here with tables of all three types. Apart from a few special cases, you can recognize the statements from the extra keyword TABLE. The technical implementation of the statements varies slightly according to the table type.
As a rule, index access to an internal table is quickest. However, it sometimes makes more sense to access data using key values. A unique key is only possible with sorted and hashed tables. If you use the syntax displayed here, your program coding is independent of the table type (generic type specification, easier maintenance).
With a standard table, inserting an entry has the same effect as appending. With sorted tables with a non-unique key, the entry is inserted before the first (if any) entry with the same key.
To read individual data records using the first variant, all fields of that are key fields of must be filled. and can be identical. If you use the WITH TABLE KEY addition in the second variant, you must also specify the key fully. Otherwise, the system searches according to the sequence of fields that you have specified, using a binary search where possible. You can force the system to use a binary search with a standard table using the BINARY SEARCH addition.
In this case, you must sort the table by the corresponding fields first. The system returns the first entry that meets the selection criteria.
Similarly to when you read entries, when you change and delete entries using the key and a work area, you must specify all of the key fields.
You can prevent fields from being transported into the work area during loop processing by using the TRANSPORTING NO FIELDS addition in the WHERE condition. (You can use this to count the number of a particular kind of entry.)
Other statements for all table types
DELETE ADJACENT DUPLICATES FROM
[COMPARING .. | A L L F I E L }|ALL FIELDS}].
The system deletes all adjacent entries with the same key field contents apart from the first entry. You can prevent the system from only comparing the key field using the COMPARING addition. If you sort the table by the required fields beforehand, you can be sure that only unique entries will remain in the table after the DELETE ADJACENT DUPLICATES statement.
Searches all lines of the table for the string . If the search is successful, the system sets the fields sy-tabix and sy-fdpos.
FREE .
Unlike CLEAR, which only deletes the contents of the table, FREE releases the memory occupied by it as well.
If you want to access your data using the index and do not need your table to be kept in sorted order or to have a unique key, that is, when the sequence of the entries is the most important thing, not sorting by key or having unique entries, you should use standard tables. (If you decide you need to sort the table or access it using the key or a binary search, you can always program these functions by hand.)
This example is written to manage a waiting list.
Typical functions are:
Adding a single entry,
Deleting individual entries according to certain criteria,
Displaying and then deleting the first entry from the list,
Displaying someone's position in the list.
For simplicity, the example does not encapsulate the functions in procedures.
The first thing we do in the example is to declare line and table type, from which we can then declare a work area and our internal table. We also require an elementary field for passing explicit index values.
This example omits the user dialogs and data transport, assuming that you understand the principles involved. We really only want to concentrate on the table access:
Adding new entries
The data record for a waiting customer is only added to the table if it does not already exist in it. If the table had a unique key, you would not have had to have programmed this check yourself.
Deleting single entries according to various criteria
The criterion is the key field. However, other criteria would be possible - for example, deleting data records older than a certain insertion date reg_date.
Displaying and deleting the first entry from the list
Once a customer comes to the top of the waiting list, you can delete his or her entry. If the waiting list is empty, such an action has no effect. Consequently, you do not have to check whether there are entries in the list before attempting the deletion.
Displaying the position of a customer in the waiting list
As above, you do not need to place any data in the work area. We are only interested in the values of sy-subrc and sy-tabix. If the entry is not in the table, sy-tabix is set to zero.
At this stage, let us return to the special case of the restricted ranked list:
DATA {TYPE|LIKE} STANDARD TABLE OF ... INITIAL SIZE . ... APPEND INTO SORTED BY .
When you choose to use a sorted table, it will normally be because you want to define a unique key.
The mere fact that the table is kept in sorted order is not that significant, since you can sort any kind of internal table. However, with sorted tables (unlike hashed tables), new data records are inserted in the correct sort order. If you have a table with few entries but lots of accesses that change the contents, a sorted table may be more efficient than a hashed table in terms of runtime.
The aim of the example here is to modify the contents of a database table. The most efficient way of doing this is to create a local copy of the table in the program, make the changes to the copy, and then write all of its data back to the database table. When you are dealing with large amounts of data, this method both saves runtime and reduces the load on the database server. Since the internal table represents a database table in this case, you should ensure that its records have unique keys.
This is assured by the key definition. Automatic sorting can also bring further advantages.
When you change a group of data records, only the fields price and currency are copied from the work area.
This means that, with larger tables, the access time is reduced significantly in comparison with a binary search. In a loop, however, the hashed table has to search the entire table (full table scan). Since the table entries are stored unsorted, it would be better to use a sorted table if you needed to run a loop through a left-justified portion of the key.
It can also be worth using a hashed table but sorting it. A typical use for hashed tables is to buffer detailed information that you need repeatedly and can identify using a unique key. You should bear in mind that you can also set up table buffering for a table in the ABAP Dictionary to cover exactly the same case. However, whether the tables are buffered on the application table depends on the size of the database table.
Buffering in the program using hashed tables also allows you to restrict the dataset according to your own needs, or to buffer additional data as required.
In this example, we want to allow the user to enter the name of a city, and the system to display its geographical coordinates.
First, we fill our "buffer table" city_list with values from the database table sgeocity. Then, we read an entry from the hashed table, specifying the full key.
The details are displayed as a simple list. At this point, it is worth repeating that you should only use this buffering technique if you want to keep large amounts of data locally in the program. You must ensure that you design your hashed table so that it is possible to specify the full key when you access it from your program.
You can define internal tables either with (WITH HEADER LINE addition) or without header lines. An internal table with header line consists of a work area (header line) and the actual table body. You address both objects using the same name. The way in which the system interprets the name depends on the context. For example, the MOVE statement applies to the header line, but the SEARCH statement applies to the body of the table.
To avoid confusion, you are recommended to use internal tables without header lines. This is particularly important when you use nested tables. However, internal tables with header line do offer a shorter syntax in several statements (APPEND, INSERT, MODIFY, COLLECT, DELETE, READ, LOOP).
hope this is helpful
do reward

Internal Table Group By

Hi everyone,
I got a FM with a table parameter and i want to perform some "group by" operation(like sql group by) on it. Any suggestion??
Regards,
Kit

COLLECT
Syntax
COLLECT wa INTO itab [result].
Effect
This statement inserts the contents of a work area wa either as single row into an internal table itab or adds the values of its numeric components to the corresponding values of existing rows with the same key. As of Release 6.10, you can use result to set a reference to the inserted or changed row in the form of a field symbol or data reference.
Prerequisite for the use of this statement is that wa is compatible with the row type of itab and all components that are not part of the table key must have a numeric data type (i, p, f).
In standard tables that are only filled using COLLECT, the entry is determined by a temporarily created hash administration. The workload is independent of the number of entries in the table. The hash administration is temporary and is generally invalidated when the table is accessed for changing. If further COLLECT statements are entered 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 administration of the table and is always independent of the number of table entries.
If no line is found with an identical key, a row is inserted as described below, and filled with the content of wa:
In standard tables the line is appended.
In sorted tables, the new line is inserted in the sort sequence of the internal table according to its key values, and the table index of subsequent rows is increased by 1.
In hashed tables, the new row is inserted into the internal table by the hash administration, according to its key values.
If the internal table already contains one or more rows with an identical key, those values of the components of work area wa that are not part of the key, are added to the corresponding components of the uppermost existing row (in the case of index tables, this is the row with the lowest table index).
The COLLECT statement sets sy-tabix to the table index of the inserted or existing row, in the case of standard tables and sorted tables, and to the value 0 in the case of hashed tables.
Outside of classes, you can omit wa INTO if the internal table has an identically-named header line itab. The statement then implicitly uses the header line as the work area.
COLLECT should only be used if you want to create an internal table that is genuinely unique or compressed. In this case, COLLECT can greatly benefit performance. If uniqueness or compression are not required, or the uniqueness is guaranteed for other reasons, the INSERT statement should be used instead.
The use of COLLECT for standard tables is obsolete. COLLECT should primarily be used for hashed tables, as these have a unique table key and a stable hash administration.
If a standard table is filled using COLLECT, it should not be edited using any other statement with the exception of MODIFY. If the latter is used with the addition TRANSPORTING, you must ensure that no key fields are changed. This is the only way to guarantee that the table entries are always unique and compressed, and that the COLLECT statement functions correctly and benefits performance. The function module ABL_TABLE_HASH_STATE can be used to check whether a standard table is suitable for editing using COLLECT.
Example
Compressed insertion of data from the database table sflight into the internal table seats_tab. The rows in which the key components carrid and connid are identical are compressed by adding the number of occupied seats to the numeric component seatsocc.
DATA: BEGIN OF seats,
 carrid TYPE sflight-carrid,
 connid TYPE sflight-connid,
 seatsocc TYPE sflight-seatsocc,
 END OF seats.
DATA seats_tab LIKE HASHED TABLE OF seats
 WITH UNIQUE KEY carrid connid.
SELECT carrid connid seatsocc
 FROM sflight
 INTO seats.
COLLECT seats INTO seats_tab.
ENDSELECT.
Exceptions
Catchable Exceptions
CX_SY_ARITHMETIC_OVERFLOW
Cause: Overflow in integer field during totals formation
Runtime Error: COLLECT_OVERFLOW
Cause: Overflow in type p field during totals formation
Runtime Error: COLLECT_OVERFLOW_TYPE_P
Non-Catchable Exceptions
Cause: COLLECT used for non-numeric fields
Runtime Error: TABLE_COLLECT_CHAR_IN_FUNCTION

Start routine internal table data is inaccessible.

Hi Guru,
I have written a small code in start routine using internal tables. The internal table has 4 fields. Intially first 3 fields are populated from ods for only the records in the data package. Then the 4th field is modified using loop on internal table. Then a sort is done on internal table and deleting the adjacent records. Now the data is read from internal table in updates rules. But data is not populating for the fields in listcube. I guess the loop on internal table is not modifying the internal table, below is the code.
Types: BEGIN OF ITAB1,
doc_no LIKE /BIC/AZFGLO10100-AC_DOC_NO,
item_no LIKE /BIC/AZFGLO10100-ITEM_NUM,
taxjur LIKE /BIC/AZFGLO10100-TAXJURCODE,
z_len TYPE I,
END OF ITAB1.
DATA ITAB_01 TYPE TABLE OF ITAB1 WITH HEADER LINE.
DATA LEN TYPE I.
DATA: str1 TYPE string,
str2 TYPE string,
doc like /BIC/AZFGLO10100-AC_DOC_NO,
item like /BIC/AZFGLO10100-ITEM_NUM,
jur like /BIC/AZFGLO10100-TAXJURCODE.
***filling the internal table with the contents of
select AC_DOC_NO ITEM_NUM TAXJURCODE into
corresponding fields of itab_01
from /BIC/AZFGLO10100
FOR ALL ENTRIES IN DATA_PACKAGE
WHERE AC_DOC_NO = DATA_PACKAGE-AC_DOC_NO
AND ITEM_NUM = DATA_PACKAGE-ITEM_NUM.
endselect.
SORT ITAB_01 ASCENDING BY doc_no ITEM_NO ASCENDING.
loop at itab_01.
doc = itab_01-doc_no.
item = itab_01-item_no.
TAX = itab_01-taxjur.
len = STRLEN(tax).
itab_01-z_len = len.
modify itab_01 transporting z_len where
doc_no = doc and item_no = item.
ENDLOOP.
***what I am doing here I am keep only the records in itab which has minimum
tax jurisdiction length for a line item in a document*****
SORT ITAB_01 DESCENDING BY doc_no z_len ASCENDING.
DELETE ADJACENT DUPLICATES FROM itab_01 comparing doc_no.
and for zlenght object I am writing the followoing code in update rules.
read table itab_01 with key doc_no = COMM_STRUCTURE-AC_DOC_NO
BINARY SEARCH.
if sy-subrc = 0.
RESULT = itab_01-z_len.
endif.
But the field z_len field is blank for all fields.
Any help is really appreciated.
Thanks,
Raj

hi Ravi,
try to give same field name in internal table and /BIC/AZFGLO10100, change the code accordingly
Types: BEGIN OF ITAB1,
AC_DOC_NO LIKE /BIC/AZFGLO10100-AC_DOC_NO,
ITEM_NUM LIKE /BIC/AZFGLO10100-ITEM_NUM,
TAXJURCODE LIKE /BIC/AZFGLO10100-TAXJURCODE,
z_len TYPE I,
END OF ITAB1.
DATA ITAB_01 TYPE TABLE OF ITAB1 WITH HEADER LINE.
***filling the internal table with the contents of
select AC_DOC_NO ITEM_NUM TAXJURCODE into
corresponding fields of itab_01
from /BIC/AZFGLO10100
FOR ALL ENTRIES IN DATA_PACKAGE
WHERE AC_DOC_NO = DATA_PACKAGE-AC_DOC_NO
AND ITEM_NUM = DATA_PACKAGE-ITEM_NUM.
endselect.

SORT INTERNAL TABLE USING NON KEY OF THE INTERNAL TABLE

HI,
i have one query for the cdpos table of abap.
What i am looking is i want the latest CHANENR of the cdpos for that
objectid and tabname and fname in my internal table.
what i thought of doing was to sort my internal table with objectid changnr tabname fname in descending order
and than use delete adjacent duplicates command
BUt that is not sorting based on all field , its sorting on changnr only
please let me know what can i do

no, that is not what i am looking at,
I am saying say i have internal table cdpos
OBJECTCLAS      OBJECTID    CHANGENR   TABNAME                        FNAME
RECN_RECN      |0100TEST1   0000384409|    VICN01                        |RECNEND
RECN_RECN       0100TEST1   0000383462    VICN01                          RECNLIFNR
RECN_RECN       0100TEST1    0000360190   VICN01                         RECNEND
RECN_RECN        0100TEST1   0000340630    VICN01                         RECNEND
this is my debug output after sorting on objectid changenr tabname fname in descending
i wanted line 2nd to be at last so when i use delete adjacent command i can get 2 line item i.e 1st and 2nd line ...

Primary Key in Internal tables?

Hi all,
Im doing a ABAP- certification, so I need an exact answer , not the 'I think...' or 'it should...' answers.
I often heard the sentence 'every internal Table has a key, even if you dont define one!'. OK, I was told, that SAP takes the non-numeric fields, and bind them to the prim.-key.
But now I wrote this little program:
Report ZYX.
DATA: Begin of wa,
one type i,
two type i,
three type i,
End of wa.
DATA: it LIKE table of wa,
temp type i.
Do 100 times.
temp = temp + 1.
wa-one = temp.
wa-two = temp + 1.
wa-three = temp + 2.
enddo.
sort it descending.
WRITE: / wa-one,wa-two,wa-three.
Why doesnt it sort the table in ANY way descending?
why doesnt this table seems to have a primary key?
Is that a mistake by the SAP?

I think it means both
I copy here what I found in SAPHelp and you understand:
Die Standardschlüsselfelder eines strukturierten Zeilentyps sind alle Felder, die weder numerisch (i, p, f) noch selbst Tabellentypen sind. Der Standardschlüssel bei nicht-strukturiertem Zeilentyp ist die gesamte Tabellenzeile, falls der Zeilentyp selbst kein Tabellentyp ist. Falls es keine entsprechende Komponente gibt bzw. der Zeilentyp selbst ein Tabellentyp ist, bleibt der Standardschlüssel leer, was aber nur bei Standardtabellen möglich ist.

Default key in internal tables

what is 'Default key'? for what type of internal tables it is used? Can you please explain with examples?
Thanks a lot.

Key
The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.
At tables with structured row type, the standard key is formed from all character-type columns of the internal table. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty. At tables with non-structured row type, the standard key consists of the entire row. If the row type is also a table, an empty key is defined.
The user-defined key can contain any columns of the internal table that are no internal table themselves, and do not contain internal tables. References are allowed as table keys. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.
Regards,
Rich Heilman

Read Internal Table based on Multiple Values for Key Field

Hi Gurus,
i have one query can you tell me how read an internal table it_kna1 for multiple values of land1 DE US IND etc.
i had tried as below but i could not can you try and let me knwo at the earliest.
here i want read the values with DE or US and want further prosess them.
REPORT YC001.
tables kna1.
select-options: cust for kna1-kunnr.
data: begin of it_kna1 occurs 0,
 kunnr like kna1-kunnr,
 name1 like kna1-name1,
 land1 like kna1-land1,
 end of it_kna1.
select kunnr name1 land1 into table it_kna1 from kna1 where kunnr in cust.
read table it_kna1 with key land1 = ( 'DE' OR 'US' ) .
can anybody suggest me some solution.
Thanks,
Jeevi.

This should be what you need:
REPORT ztest NO STANDARD PAGE HEADING LINE-SIZE 80 MESSAGE-ID 00.
TABLES kna1.
SELECT-OPTIONS: cust FOR kna1-kunnr.
DATA: BEGIN OF it_kna1 OCCURS 0,
 kunnr LIKE kna1-kunnr,
 name1 LIKE kna1-name1,
 land1 LIKE kna1-land1,
 END OF it_kna1.
DATA: itab_index LIKE sy-tabix.
SELECT kunnr name1 land1
INTO TABLE it_kna1
FROM kna1
WHERE kunnr IN cust.
SORT it_kna1 BY land1.
READ TABLE it_kna1 WITH KEY
land1 = 'DE'
BINARY SEARCH.
itab_index = sy-tabix.
WHILE sy-subrc = 0.
itab_index = itab_index + 1.
WRITE: /001 it_kna1-kunnr, it_kna1-land1, it_kna1-name1.
READ TABLE it_kna1 INDEX itab_index.
IF it_kna1-land1 <> 'DE'.
 sy-subrc = 99.
ENDIF.
ENDWHILE.
SKIP 1.
READ TABLE it_kna1 WITH KEY
land1 = 'US'
BINARY SEARCH.
itab_index = sy-tabix.
WHILE sy-subrc = 0.
itab_index = itab_index + 1.
WRITE: /001 it_kna1-kunnr, it_kna1-land1, it_kna1-name1.
READ TABLE it_kna1 INDEX itab_index.
IF it_kna1-land1 <> 'US'.
 sy-subrc = 99.
ENDIF.
ENDWHILE.
Rob

How to read an internal table with more than one (2 or 3) key field(s).

how to read an internal table with more than one (2 or 3) key field(s). in ecc 6.0 version

hi ,
check this..
report.
tables: marc,mard.
data: begin of itab occurs 0,
      matnr like marc-matnr,
      werks like marc-werks,
      pstat like marc-pstat,
      end of itab.
data: begin of itab1 occurs 0,
      matnr like mard-matnr,
      werks like mard-werks,
      lgort like mard-lgort,
      end of itab1.
parameters:p_matnr like marc-matnr.
select matnr
       werks
       pstat
       from marc
       into table itab
       where matnr = p_matnr.
sort itab by matnr werks.
select matnr
       werks
       lgort
       from mard
       into table itab1
       for all entries in itab
       where matnr = itab-matnr
       and werks = itab-werks.
sort itab1 by matnr werks.
loop at itab.
read table itab1 with key matnr = itab-matnr
                          werks = itab-werks.
endloop.
regards,
venkat.

How to sort an internal table with a header line?

hi all,
i have declared table i_bseg type standard table of bseg with header line.
now i have populated data in i_bseg.
now i am sorting it by bukrs
ie i am writing sort i_bseg by bukrs.
before sorting all i_bseg-belnrs were populated...
but after sorting the contents of the i_bseg is changing.
some of the belnrs are getting deleted..
is there any special way to sort an internal table with header line...?

hi,
SORT <itab> [ASCENDING|DESCENDING] [AS TEXT] [STABLE].
The statement sorts the internal table <itab> in ascending order by its key. The statement always applies to the table itself, not to the header line.
If you have an internal table with a structured line type that you want sort by a different key, you can specify the key in the SORT statement:
SORT <itab> [ASCENDING|DESCENDING] [AS TEXT] [STABLE]
BY <f1> [ASCENDING|DESCENDING] [AS TEXT]
<fn> [ASCENDING|DESCENDING] [AS TEXT].
this is your sort statement: sort i_bseg by bukrs.
you try with this statement: sort i_bseg by bukrs STABLE.
regards,
Ashokreddy

How to read from an internal table with multiple key fields.

Hi All!!
I want to read from an internal table having keys as k1,k2,k3.
How can I use read statement to read an entry having this as the key fields.
Thanks in adavance..
Prabhas Jha

hi there
use:
sort itab by K1 K2 K3.
read table itab into wa with key K1 = value 1
                                              K2 = value2
                                              K3 = value 3
                                               BINARY SEARCH.
where:
itab is ur internal table
wa is the work area with the same line type as the itab
cheers
shivika

Key column in an internal table?

Hi all,
Can somebody tell me, if it is possible to create an internal table with a key-column?
I think it is, but I do not know how? So, How can I make it? Does this keys work exactly like DB table keys?
Thanks,
MPM

I'm not sure if it is correct that sorted tables can only have unique keys.
The table keys are important for access:
1. Every table with character fields have got a key by (SAP) definition. An unsorted standard table's key consists of all non-numeric fields. In this case the access will be sequential except for a binary search.
2. Sorted tables may have one unique or non-unique key consisting odf one or more fields. If the key is not unique, the entry with the lowest index is accessed.
3. Only Hash tables require a unique key
4. Only one key per internal table is allowed (no secondary keys as in other programming languages or database definitions).
5. See also:
http://help.sap.com/saphelp_47x200/helpdata/en/90/8d7325b1af11d194f600a0c929b3c3/frameset.htm
regards,
Clemens

Hashed & sorted internal tables

hi all,
 can any body help me to understand the concept of hashed & sorted internal table & how they can be used for improve the performance of report.
regards
Deepak

Hi Deepak,
If you have an internal table in your program which is used solely for lookup, it is good programming practice to use a hash table. The example below shows this, in combination with a method for buffering SELECT SINGLE results.
Code
*& Form select_dispo
 Get MRP controller and in-house production time from material
 and plant
 --> MATNR Material
 --> RESWK Plant
 <-- DISPO MRP controller
 <-- DZEIT In-house production time
form select_from_marc using matnr werks dispo dzeit.
types: begin of mrp_lookup_type,
 matnr like marc-matnr,
 werks like marc-werks,
 dispo like marc-dispo,
 dzeit like marc-dzeit,
 end of mrp_lookup_type.
Define static hashed table to hold results
statics: st_mrp type hashed table of mrp_lookup_type
 with unique key matnr werks.
data: l_wa_mrp type mrp_lookup_type.
clear dzeit.
See if data is in the table
read table st_mrp into l_wa_mrp with table key matnr = matnr
 werks = werks.
If not in table, get it from the database
if not sy-subrc is initial.
 select single dispo dzeit from marc
 into corresponding fields of l_wa_mrp-dispo
 where matnr eq matnr
 and werks eq werks.
Insert into table
 l_wa_mrp-matnr = matnr.
 l_wa_mrp-werks = werks.
 insert l_wa_mrp into table st_mrp.
endif.
dispo = l_wa_mrp-dispo. " MRP Controller
dzeit = l_wa_mrp-dzeit. " Inhouse production time
endform. " select_from_marc

Sorting by various keys internal table

Similar Messages

Maybe you are looking for