How to get common datas from two int.tables

Question

hi,
please tell me , how to i will get the common datas between two int. tables
& place them in third int. table.
give me syntax.
regards
subhasis.

Answer 1

Hi Subhasis,
<b>SORT :</b></u>
SORT itab.
Extras:
1. ... BY f1 f2 ... fn
2. ... ASCENDING
3. ... DESCENDING
4. ... AS TEXT
5. ... STABLE
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Field symbols not allowed as sort criterion.
Effect
The entries in the internal table are sorted in ascending order using the key from the table definition (DATA, TYPES).
Addition 1
... BY f1 f2 ... fn
Effect
Uses the sort key defined by the sub-fields f1, f2, ..., fn of the table itab instead of the table key. The fields can be of any type; even number fields and tables are allowed.
You can also specify the sort fields dynamically in the form (name). If name is blank at runtime, the sort field is ignored. If itab is a table with a header line, you can also use a field symbol pointing to the header line of itab as a dynamic sort criterion. A field symbol that is not assigned is ignored. If a field symbol is assigned, but does not point to the header line of the internal table, a runtime error occurs.
If the line type of the internal table contains object reference variables as components, or the entire line type is a reference variable, you can use the attributes of the object to which a reference is pointing in a line as sort criteria (see Attributes of Objects as the Key of an Internal Table.
You can address the entire line of an internal table as the key using the pseudocomponent TABLE_LINE. This is particularly relevant for tables with a non-structured line type when you want to address the whole line as the key of the table (see also Pseudocomponent TABLE_LINE With Internal Tables).
If you use one of the additions 2 to 5 before BY, it applies to all fields of the sort key by default. You can also specify these additions after each individual sort field f1, f2, ..., fn. For each key field, this defines an individual sort rule which overrides the default.
Addition 2
... ASCENDING
Effect
Sorts in ascending order. This is also the default if no sort order is specified directly after SORT. For this reason, it is not necessary to specify ASCENDING explicitly as the default sort order.
With the addition BY, you can also specify ASCENDING directly after a sort field to define ascending order explicitly as the sort sequence for this field.
Addition 3
... DESCENDING
Effect
Sorts in descending order. If the addition comes right after SORT, DESCENDING is taken as the default for all fields of the sort key.
With the addition BY, you can also specify DESCENDING directly after a sort field.
Addition 4
... AS TEXT
Effect
Text fields are sorted appropriate to the locale. This means that the relative order of characters is defined according to the text environment being used.
When an internal mode is opened (in other words, when a roll area is opened), the text environment is automatically set to the logon language specified in the user master record. If necessary, however, you can change the text environment explicitly in your program by using a SET-LOCALE statement.
If the addition comes directly after itab, locale-specific rules are used for all fields of the sort key where the type of these fields is C or W. After the sort, the sequence of entries usually does not match the sequence which results otherwise, without using the addition AS TEXT, i.e. with binary sorting.
With the addition BY, you can also specify AS TEXT directly after a sort field, provided it is of type C or W, or a structured type. Otherwise, a runtime error occurs. In sort fields with a structured type, AS TEXT only affects subcomponents with type C or W.
In case of an invalid character, a SYSLOG message is written, and the respective record is inserted at the end.
Note
Please keep the rules for site-specific sorting in mind.
Example
Sort a name table with different keys:
TYPES: BEGIN OF PERSON_TYPE,
         NAME(10)   TYPE C,
         AGE        TYPE I,
         COUNTRY(3) TYPE C,
       END OF PERSON_TYPE.
DATA: PERSON TYPE STANDARD TABLE OF PERSON_TYPE WITH
                  NON-UNIQUE DEFAULT KEY INITIAL SIZE 5,
      WA_PERSON TYPE PERSON_TYPE.
WA_PERSON-NAME    = 'Muller'. WA_PERSON-AGE = 22.
WA_PERSON-COUNTRY = 'USA'.
APPEND WA_PERSON TO PERSON.
WA_PERSON-NAME    = 'Moller'. WA_PERSON-AGE = 25.
WA_PERSON-COUNTRY = 'FRG'.
APPEND WA_PERSON TO PERSON.
WA_PERSON-NAME    = 'Möller'. WA_PERSON-AGE = 22.
WA_PERSON-COUNTRY = 'USA'.
APPEND WA_PERSON TO PERSON.
WA_PERSON-NAME    = 'Miller'. WA_PERSON-AGE = 23.
WA_PERSON-COUNTRY = 'USA'.
APPEND WA_PERSON TO PERSON.
SORT PERSON.
Now, the sequence of the table entries is as follows:
Miller  23  USA
Moller  25  FRG
Muller  22  USA
Möller  22  USA
If, for example, you apply German sort rules where the umlaut comes directly after the letter 'o' in the sort, the data record beginning with 'Möller' would not be in the right place in this sequence. It should come second.
Provided a German-language locale is set (e.g. sorting is according to German grammatical rules, see also SET LOCALE), you can sort the names according to German rules as follows:
SORT PERSON BY NAME AS TEXT.
Now, the sequence of table entries is as follows:
Miller  23  USA
Moller  25  FRG
Möller  22  USA
Muller  22  USA
Further examples:
SORT PERSON DESCENDING BY COUNTRY AGE NAME.
Now, the sequence of table entries is as follows:
Miller  23  USA
Möller  22  USA
Muller  22  USA
Moller  25  FRG
SORT PERSON DESCENDING BY AGE ASCENDING NAME AS TEXT.
Now, the sequence of table entries is as follows:
Muller  22  USA
Möller  22  USA
Miller  23  USA
Moller  25  FRG
Addition 5
... STABLE
Effect
Uses a stable sort, that is, the relative sequence of entries that have the same sort key remains unchanged.
Unlike additions 2 to 4, you cannot use this addition directly after a sort field.
Notes
General:
The number of sort fields is restricted to 250.
The sort process is only stable if you use the STABLE addition. Otherwise, a predefined sequence of fields used to sort a list is not usually retained.
It does not make sense to use the SORT command for a SORTED TABLE. If the table type is statically declared, the system returns a syntax error if you try to SORT the table. If the table type is not statically declared (for example, because the table was passed to a FORM routine as an INDEX TABLE in a parameter), and the system can interpret the SORT statement as an empty operation, it ignores the statement. This is the case when the key in the BY clause corresponds to the beginning of the table key. Otherwise, a runtime error occurs.
To delete all duplicate entries from a sorted internal table (e.g. just after SORT), you can use the DELETE ADJACENT DUPLICATES FROM itab statement.
When using the addition AS TEXT, the sequence of entries after the sort does not usually match the sequence resulting from a binary sort, i.e. if the addition AS TEXT is not specified. The consequence of this is that after the SORT, you are not allowed to access with the READ TABLE itab ... BINARY SEARCH statement.
If you still want to access data sorted apppropriate to the locale with a binary search, you can do this by including an additional component in the table where you can explictly store the data formatted using the CONVERT TEXT ... INTO SORTABLE CODE statement. This is also recommended for performance reasons if you have to re-sort the table several times according to locale-specific criteria.
If the internal table has more than 2^19 lines or is larger than 12 MB, the system sorts it physically using an external auxiliary file. You can specify the directory in which the file should be created using the SAP profile parameter DIR_SORTTMP. By default, the system uses the SAP data directory (SAP profile parameter DIR_DATA).
Notes
Performance:
The runtime required to sort an internal table increases with the number of entries and the length of the sort key.
Sorting an internal table with 100 entries with a 50 byte key requires about 1300 msn (standardized microseconds). Using a 30-byte key, the runtime is about 950 msn.
If one of the specified sort criteria is itself an internal table, SORT may sometimes take much longer.
The runtime increases if you use a stable sort.
Physical sorting reduces the runtime required for subsequent sequential processing.
Reward If Useful.
Regards,
Chitra