how to get common datas from two int.tables

[Former Member]

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.

[Former Member]

Hi Sahoo,

Try this logic.

sort itab1 , itab2.

loop at itab1 to wa_itab1.

loop at itab2 to wa-itab2.

if wa_itab1= wa_itab2.

append wa_itab1 to itab3.

endif.

endloop.

Endloop.

rewards if find useful!

regards

Antony Thomas

[Former Member]

hi,

please tell something about sort keyward.

thanks

[Former Member]

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

[Former Member]

Hi

Read the 2nd ITAB within the loop of 1st Itab and move the data into third ITAB

LOOP AT ITAB1.

Read table itab2 with key f1 = itab1-f1.

if sy-subrc = 0.

if itab2-date =itab1-date.

move -cooresponding to itab3.

endif.

endif.

append itab3.

ENDLOOP.

Regards

Anji

[Former Member]

Try this...

data: itab1 like table of itab,

ITAB2 like table of itab,

itab3 like table of itab.

loop at itab1 into wa.

read table itab2 WITH KEY field1 = wa-field1 into wa.

if sy-subrc = 0.

append wa to itab3.

endif.

endloop.

Message was edited by:

Muthurajan Ramkumar

Message was edited by:

Muthurajan Ramkumar

[Former Member]

Hi,

If you're talking about two identical itabs, use this code:

LOOP AT itab1.

READ TABLE itab2 WITH KEY column1 = itab1-column1

column2 = itab1-column2

column3 = itab1-column3

...

columnx = itab1-columnx.

IF sy-subrc = 0.

<i>* I suppose that the itabs are with header line</i>

itab3 = itab1.

APPEND itab3.

ENDIF.

ENDLOOP.

Hope that helps.

Regards,

Amine

[Former Member]

You need to compare both internal tables :

loop at itab.

read table itab1 with key date = itab-date.

if sy-subrc eq 0.

itab2-date = itab1-date.

append itab2.

clear itab2.

endif.

clear: itab2,

itab1,

itab.

endloop.

now use itab2 ( Delete adjacent duplicate key with date field)

Thanks

Seshu

[Former Member]

Hi

Take for Eg. Internal table 1 as table - A, Internal Table 2 as Table- B & Internal table 3 as Table - C.

Try with loop endloop on table-A. With in this loop read entry of Table-B with Key fields of table-A. After reading table-B, If Sy-SUBRC is zero then Move the entry of Table-A and Table-B(common Values) in Table-C header line and then Append the same....

If this is not working for you then Performance point of view you can use "FOR ALL ENTRIES".

If it helpful then please rewards the points.....

Cheers..

Sagun Desai.....

[Former Member]

Hi,

try this one:

sort:t_tab1 by <fieldname>,

t_tab2 by <fieldname>,

loop at t_tab1 into wa_tab1.

read table t_tab2 into wa_tab2 with key fieldname = wa_tab1-fieldname binary search.

wa_total-field1 = wa_tab2-field1.

wa_total-field2 = wa_tab2-field2.

............................................

..............................................

.................................................

append wa_total to t_total. "u get data required data in t_total

endloop.

<b>reward points if useful.</b>

regards,

Vinod Samuel.