Internal table Comparison

Hi,
I hav 2 internal tables with some values . I want to compare the 2 tables and elimate
duplicate entries.Wht logic i hav to use in looping ?
Rgds,
SAPUser100

Sam's got the right idea if you want to delete the "duplicates" out of itab2. If it is the other way around, then you would do the same thing swapping the itab names. If you want to do get rid of the duplicates in both itabs and keep both itabs you will have to do it twice.
LOOP AT itab1.
READ TABLE itab2 WITH KEY val = itab1-val.
IF sy-subrc = 0.
    DELETE itab2 INDEX sy-tabix.
ENDIF.
CLEAR: itab1,
         itab2.
ENDLOOP.
LOOP AT itab2.
READ TABLE itab1 WITH KEY val = itab2-val.
IF sy-subrc = 0.
    DELETE itab1 INDEX sy-tabix.
ENDIF.
CLEAR: itab1,
         itab2.
ENDLOOP.
Regards,
Rich Heilman

Similar Messages

Reg. comparison of two types of Internal tables.

Hi friends!
I have a doubt while declaring a internal table. whether to declare with header line or without header line. Can all types of manipulations be done after retrieving data from DB table to the Inernal table with headerline. Which of these two is more efficient. I would like to know the clear comparison between these two types.
regards,
prasad

Hi,
Incase of declaring an Internal table with header line will make the processing looks simple as with in a loop and endloop statement your internal manipulations namely AT NEW, AT LAST, COLLECT and other similar statements will work out, but still clearing of the respective header needs to be done whenever there is exit happens to the application after successful completion. As because I have encountered errors due to failure in clearing header as in case of batch applications and BDC applications. Also as mentioned memory management also needs to be considered.
Incase of declaring with work area except for the internal manipulations being pointed above, for all other cases it works out effectively and also more safer way to code your application.
Also the declaration with or without header line also accounts whenever there is a call to a function module at which if we require to receive or pass some data through TABLES option then we need to look for the specified table type being used.
So in all it depends the process in your application where in the type of declaration accounts.
Regards,
Jagath.

Reg comparison of two internal tables

hi friends,
please help me solving this.
there are two internal tables t_zvs38 and t_value
1.t_value like seahlpres
2.t_zvs38 like zvs38.
values in t_value will be like this.
first line wil contain zmdtype(mandatory document) and second line will contain
zmdtypet (the description for zmdtype).
eg.
D001 -
-zmdtype
internal----
zmdtypet
D002
external
D003
renewal
values in t_zvs38.
for a particular sales.org the zmdtype is filled.
select vkorg zmdtype into corrsponding fields of table t_zvs38
where vkorg = p_vkorg.
Now i want to compare t_value and t_zvs38 with field zmdtype
and delete the contents of t_value which are not in t_zvs38.
i have written like this.
loop at t_value.
read table t_zvs38 with key zmdtype = t_value-string.
if sy-subrc ne 0.
delete t_value. "to delete zmdtype
sy-tabix = sy-tabix + 1.
delete t_value. " to delete zmdtypet
else.
sy-tabix = sy-tabix +2. "to go to next zmdtype.
endif.
endloop.
but it is deleting all the contents of t_value.
points are assured.

CLEAR zvs32t.
SELECT zvs32tzmdtype zvs32tzmdtypet
    INTO (zvs32t-zmdtype, zvs32t-zmdtypet)
    FROM zvs32t
    JOIN zvs32
    ON   zvs32tzmdtype = zvs32zmdtype
    WHERE zvs32t~spras    = sy-langu
    AND   zvs32~zfrenewal = space.
     WRITE zvs32t-zmdtype TO t_value.
    APPEND t_value.
    WRITE zvs32t-zmdtypet TO t_value.
    APPEND t_value.
ENDSELECT.
SELECT vkorg vkbur zmdtype FROM zvs38 INTO CORRESPONDING FIELDS OF TABLE t_zvs38
WHERE vkorg = p_vkorg
AND vkbur = p_vkbur.
LOOP AT t_value INTO wa_area1.
    v_index = sy-tabix.
    READ TABLE t_zvs38 INTO wa_area2 WITH KEY zmdtype = wa_area1-string
BINARY SEARCH.
   IF sy-subrc NE 0.
      IF l_flag IS INITIAL.
        DELETE t_value INDEX v_index.
       ELSE.
        CLEAR l_flag.
      ENDIF.
   ELSE.
      l_flag = 'X'.
   ENDIF.
ENDLOOP.
Using this code ,i am unable to ge the correct output.Thank u all for ur help.

Data comparison in an internal table

hi all,
i have a requirement like i have to print the data in the followin fashion
material   stype   sutype   XXXX     XXX      XXXXXX
123          ku         ok       *****      ***        ***********
               ku         ok        ******   **            ********
i have all the data in final internal table the problem is like if the material no is same then the out put should be in the above fashion and im unable to compare the material in an internal table so can any one can solve this ill be much thankful
bye
anupama

Hi,
do these steps.
1. Sort ur internal table by MATNR
   SORT Itab by matnr.
2. Then use this logic.
Loop at itab.
at new matnr.
    Write itab-matnr.
endat.
     Write ..remaining field.
endloop.
regards,
Venkat.O

Efficiently deleting lines from internal table based on column comparison

Hi all,
let's assume, I have the following internal table MY_TAB:
COL_1 | COL_2 | COL_3
A       1       1
B       2       2
C       3       3
D       3       4
E       3       5
I'd like to delete all rows, where the values in COL_2 and COL_3 are equal. That is, in the above table, the rows for A, B and C.
What's the most performant / fastest and efficient way to do this?
Thanks for any hints in advance!
Best regards,
Philipp

I do not understand other proposal.
The are two solutions possible
LOOP AT itab INTO wa.
   IF ( wa-col2 = wa-col3).
     DELETE itab INDEX sy-tabix.
   ENDIF.
ENDLOOP.
If memory is not an issue and if many lines are to be deleted, then the APPEND in a new table is better.#
I would use that one in all cases where the conditions are complicated.
LOOP AT itab INTO wa.
   IF ( wa-col2 <> wa-col3).
     APPEND wa TO itab2.
   ENDIF.
ENDLOOP.
refresh itab.
itab[] = itab2[].
Siegfried

How to find number of lines in an internal table

Dear all,
how to find number of records present in an internal table.

DESCRIBE TABLE
Syntax
DESCRIBE TABLE itab [KIND knd] [LINES lin] [OCCURS n].
Extras:
1. ... KIND knd
2. ... LINES lin
3. ... OCCURS n
Effect
This statement determines some properties of the internal table itab and assigns them to the specified variables. The various additions enable you to determine the table type, the number of currently filled rows and the initial memory requirement.
In addition, the system fields sy-tfill and sy-tleng are filled with the current number of table rows and the length of a table row in bytes.
Notes
For detailed information about an internal table, you should use the methods of RTTS of the DESCRIBE TABLE statement.
Without the specification of an addition, the statement DESCRIBE TABLE only sets the system fields sy-tfill and sy-tleng.
Addition 1
... KIND knd
Effect
The table type of the internal table itab is determined and a corresponding one-digit identification is assigned to the data object knd. A character-type data type is expected for the data object. The identifications are "T" for standard tables, "S" for sorted tables and "H" for hashed tables. These values are also defined as constants sydes_kind-standard, sydes_kind-sorted, and sydes_kind-hashed in the type group SYDES.
Addition 2
... LINES lin
Effect
The current number of table rows of the internal table itab is determined and is assigned to the data object lin.The data type i is expected for the data object.
Note
As of release 6.10, the current number of rows of an internal table can also be determined using the in-built function lines.
Addition 3
... OCCURS n
Effect
The initial memory requirement defined during the creation of the internal table with the addition INITIAL SIZE or the obsolete addition OCCURS is determined and assigned to the data object n. The data type i is expected for the data object.
Example
Descending sorting of a generically typed internal table in a subprogram. Since sorted tables cannot be sorted in a descending order, the table type is checked to avoid an exception that cannot be handled.
TYPE-POOLS sydes.
FORM sort_descending CHANGING itab TYPE ANY TABLE.
DATA tabkind(1) TYPE c.
DESCRIBE TABLE itab KIND tabkind.
IF tabkind = sydes_kind-standard OR
     tabkind = sydes_kind-hashed.
    SORT itab DESCENDING.
ELSEIF tabkind = sydes_kind-sorted.
    MESSAGE '...' TYPE 'E'.
ELSE.
    MESSAGE '...' TYPE 'E'.
ENDIF.
ENDFORM.
DESCRIBE FIELD INTO
Note
This statement is for internal use only.
It cannot be used in application programs.
Syntax
DESCRIBE FIELD dobj INTO td.
Effect
All characteristics of the field f, its components , sub-components etc. are displayed in the field td (type description). td has to be of the type SYDES_DESC, defined in Type Group SYDES. Because of this, the type group SYDES must be integrated into the ABAP-program with a TYPE-POOLS statement .
The structure SYDES_DESC has two table-type components TYPES and NAMES:
In TYPES, the tree structure of the type belonging to f is displayed. The components of a node are stored in the table TYPES in a continuous manner. Beginning and end of the line area that represents the components are stored in TYPES-FROM and TYPES-TO. The reference to the superior node can be found in TYPES-BACK. If no superior resp. subordinate node exists, then this is marked by the value 0 (For the relevance of further components, refer to the following sections).
The names of components, types etc. are not stored directly in TYPES. Instead, the components TYPES-IDX_... hold an index in the name table NAMES. The value 0 indicates that there is no reference to the name table.
NAMES contains the possibly fragmented names in the component NAMES-NAME. If a name continues in the following line, this is indicated by an asterisk ('*') in the component NAMES-CONTINUE.
The type description table (TYPES) not only stores information about the tree structure but also further information about the type of f resp. its components. This includes especially all information that can be determined using the usual additions to DESCRIBE FIELD. In detail, TYPES contains the following columns:
IDX_NAME
Component Name
IDX_USER_TYPE
Name of a user-defined type, i.e., a type that was defined through its TYPES-statement. Derived types (... TYPE A-B) and structures from the ABAP-Dictionary are not considered to be user-defined types.
CONTEXT
For user-defined types only: The context, in which the type is defined. Possible values are defined in the constant SYDES_CONTEXT of the type group SYDES. Please only use these constants to carry out a comparison. In detail, we distinguish between the following type contexts:
SYDES_CONTEXT-PROGRAM: Program-global type
SYDES_CONTEXT-FORM   : FORM-local type
SYDES_CONTEXT-FUNCTION: FUNCTION-local type
SYDES_CONTEXT-METHOD : METHOD-local type
IDX_CONTEXT_NAME
For user-defined types only:
With a local context: The name of the FORM or FUNCTION, whose type was defined. The name of the associated program is then the first entry in the name table.
With a global context: The name of the program in which the type was defined.
IDX_EDIT_MASK
Conversion routine from the ABAP-Dictionary, is in accordance with the addition EDIT MASK at simple DESCRIBE.
IDX_HELP_ID
Help-Id when referencing to fields from the ABAP-Dictionary
LENGTH
Internal length, corresponds to the addition LENGTH at simple DESCRIBE
OUTPUT_LENGTH
Output length, corresponds to the addition OUTPUT-LENGTH at simple DESCRIBE
DECIMALS
Number of decimal digits, corresponds to the addition DECIMALS at simple DESCRIBE
TYPE
ABAP-Type, corresponds to the addition TYPE at simple DESCRIBE
TABLE_KIND
A table type is stored here for the components which represent an internal table. The same values are returned as with the variant DESCRIBE TABLE itab KIND k. Components which do not represent a table get the return value set to SYDES_KIND-UNDEFINED (see type group SYDES).
Example
Example definition of the complex data type EMPLOYEE_STRUC:
PROGRAM DESCTEST.
TYPES: BEGIN OF name_struc,
         first TYPE c LENGTH 20,
         last   TYPE c LENGTH 20,
       END OF name_struc,
       BEGIN OF absence_time_struc,
         day        TYPE d,
         from       TYPE t,
         to         TYPE t,
       END OF absence_time_struc,
       phone_number TYPE n LENGTH 20,
       BEGIN OF employee_struc,
         id         LIKE sbook-customid,
         name       TYPE name_struc,
         BEGIN OF address,
           street TYPE c LENGTH 30,
           zipcode TYPE n LENGTH 4,
           place   TYPE c LENGTH 30,
         END OF address,
         salary_per_month TYPE p LENGTH 10 DECIMALS 3,
         absent           TYPE STANDARD TABLE OF absence_time_struc
                               WITH NON-UNIQUE DEFAULT KEY,
         phone            TYPE STANDARD TABLE OF phone_number
                               WITH NON-UNIQUE DEFAULT KEY,
       END OF employee_struc.
You can determine the structure of the type EMPLOYEE_STRUC by collecting the type group SYDES as follows:
TYPE-POOLS: sydes.
DATA: employee TYPE employee_struc,
      td       TYPE sydes_desc.
DESCRIBE FIELD employee INTO td.
The following table shows a few selected columns of the type description table TD-TYPES. For a better overview, the names of the columns IDX_NAME, IDX_UERR_TYPE and IDX_EDIT_MASK have been shortened:
    |FROM| TO |BACK|NAME|UTYP|EMSK|TYPE
|--||||||--
1 | 2 | 7 | 0 | 0 | 2 | 0 | v
2 | 0 | 0 | 1 | 6 | 0 | 4 | N
3 | 8 | 9 | 1 | 7 | 5 | 0 | u
4 | 10 | 12 | 1 | 8 | 0 | 0 | u
5 | 0 | 0 | 1 | 9 | 0 | 0 | P
6 | 13 | 13 | 1 | 11 | 0 | 0 | h
7 | 17 | 17 | 1 | 12 | 0 | 0 | h
8 | 0 | 0 | 3 | 13 | 0 | 0 | C
9 | 0 | 0 | 3 | 14 | 0 | 0 | C
10 | 0 | 0 | 4 | 15 | 0 | 0 | C
11 | 0 | 0 | 4 | 16 | 0 | 0 | N
12 | 0 | 0 | 4 | 17 | 0 | 0 | C
13 | 14 | 16 | 6 | 0 | 18 | 0 | u
14 | 0 | 0 | 13 | 20 | 0 | 0 | D
15 | 0 | 0 | 13 | 21 | 0 | 0 | T
16 | 0 | 0 | 13 | 22 | 0 | 0 | T
17 | 0 | 0 | 7 | 0 | 0 | 0 | N
Please note that the entries in rows 6 and 7 represent internal tables (ABAP-Type h). There is always an entry for the corresponding row type (rows 13 and 17) to an internal table.
The indices in the rows 5 to 7 refer to entries in the name table TD-NAMES. If you look, e.g., at row 3, you find the corresponding component name in TD-NAMES from row 7 (NAME) onward and the corresponding user type from row 5 (NAME_STRUC) onward.
In the name table TD-NAMES you find the following entries. Note that the names SALARY_PER_MONTH and ABSENCE_TIME_STRUC are stored in two parts:
    |CONTINUE|NAME                   |CONTINUE|NAME
|--|     -||--
1 |        |DESCTEST            12 |        |PHONE
2 |        |EMPLOYEE_STRUC      13 |        |FIRST
3 |        |SBOOK-CUSTOMID      14 |        |LAST
4 |        |==ALPHA             15 |        |STREET
5 |        |NAME_STRUC          16 |        |ZIPCODE
6 |        |ID                  17 |        |PLACE
7 |        |NAME                18 |   *    |ABSENCE_TIME_ST
8 |        |ADDRESS             19 |        |RUC
9 |   *    |SALARY_PER_MONT     20 |        |DAY
10 |        |H                   21 |        |FROM
11 |        |ABSENT              22 |        |TO

Comparing Application server file and internal table

hi all
Iam new to the world of ABAP. I have a requirement wherein i need to compare data in a internal table and that of the file. I need to extract the delta records( ie the record is found in the internal table but not in the file and vice versa ) and put it in another internal table. Which is the best way to do it?
Awaiting quick reply. Thanks
Nirmal.

Hello Nimal
First read the file into your itab. For comparison you can use the same logic as change documents are prepared. Assuming both of your itabs are of structure struc_a. Then define the following type:
TYPES: BEGIN OF ty_s_itab_di.
INCLUDE TYPE struc_a.
TYPES: CHIND TYPE bu_chind.
TYPES: END OF ty_s_itab_di.
TYPES: ty_t_itab_di TYPE STANDARD TABLE OF ty_s_itab_di
WITH DEFAULT KEY.
DATA:
gt_itab_old TYPE ty_t_itab_di,
gt_itab_new TYPE ty_t_itab_di.
Fill itabs gt_Itab_old with the corresponding data of itab1 and gt_itab_new with the corresponding data of itab2.
Very important: sort you itabs either by all key fields or by all fields.
Call function CHANGEDOCUMENT_PREPARE_TABLES with the following parameters:
- CHECK_INDICATOR = ' '
- TABLE_NEW = gt_Itab_new
- TABLE_OLD = gt_itab_old
The function module will remove identical lines from both itabs. New entries in gt_itab_New will have CHIND = 'I' and deleted entries in gt_itab_old will have CHIND = 'D'.
Read the documentation of the function module and play around with it. You will see that this a quite easy yet powerful approach for comparing itabs.
Regards
Uwe

MODIFY ALL LINES IN INTERNAL TABLE

Hi,
How to modify more than one line in an internal table? I tried using update, failed as update is not for internal tables. Your help is appriciated .
thank you,
surya.

To change one or more lines using a condition, use the following statement:
<b>MODIFY itab FROM wa TRANSPORTING f1 f2 ... WHERE cond.</b>
This processes all of the lines that meet the logical condition cond. The logical expression cond can consist of more than one comparison. In each comparison, the first operand must be a component of the line structure. If the table lines are not structured, the first operand can also be the expression TABLE_LINE. The comparison then applies to the entire line. If the line type of the internal table contains object reference variables as component comp or if the entire line type is a reference variable, the attributes of the attr object to which the respective line reference points can be specified as comparison values using comp->attr or table_line->attr.
The work area wa, which must be compatible with the line type of the internal table, contains the new contents, which in turn will be assigned to the relevant table line using the TRANSPORTING addition. Unlike the above MODIFYstatement, the TRANSPORTING addition is not optional here. Furthermore, you can only modify the key fields of the internal table if it is a standard table. If at least one line is changed, the system sets sy-subrc to 0, otherwise to 4.
REPORT demo_int_tables_modify .
DATA: BEGIN OF line,
        col1 TYPE i,
        col2 TYPE i,
      END OF line.
DATA itab LIKE HASHED TABLE OF line WITH UNIQUE KEY col1.
DO 4 TIMES.
line-col1 = sy-index.
line-col2 = sy-index ** 2.
INSERT line INTO TABLE itab.
ENDDO.
line-col1 = 2.
line-col2 = 100.
MODIFY TABLE itab FROM line.
LOOP AT itab INTO line.
WRITE: / line-col1, line-col2.
ENDLOOP.
The list output is:
         1        1
         2      100
         3        9
         4       16
The program fills a hashed table with a list of square numbers. The MODIFY statement changes the line of the table in which the key field col1 has the value 2.
I hope it helps.
Best Regards,
Vibha
*Please mark all the helpful answers

How to use dynamic internal table with FOR ALL ENTRIES

Hello SDNers,
I am having a dynamic internal table & want to use FOR ALL ENTRIES(FAE) using this dyn. table.
This works fine for me:
IF <lt_tmp> IS NOT INITIAL. "<lt_tmp> is my dyn. internal table
        SELECT field1 field2
          FROM TABLE ztable
          INTO TABLE itab "Itab is a static table
          FOR ALL ENTRIES IN <lt_tmp>
          WHERE (lv_dynwhere). "lv_dynwhere -> dynamic where clause
      ENDIF.
SAP documentation says:
"The logical expression sql_cond of the WHERE condition can be comprised of several logical expressions using AND and OR. However, if FOR ALL ENTRIES is specified, there must be at least one comparison with a column of the internal table itab that can be specified statically or dynamically. "
How do we specify the column of the internal table dynamically ? Can we do something like this:
IF <lt_tmp> IS NOT INITIAL. "<lt_tmp> is my dyn. internal table
        SELECT field1 field2
          FROM TABLE
          INTO TABLE itab "Itab is a static table
          FOR ALL ENTRIES IN <lt_tmp>
          WHERE key_field1 = (dynamic token for column1 of <lt_tmp>)
                       key_field2 = (dynamic token for column2 of <lt_tmp>)
      ENDIF.
      ENDIF.
Let me know if i am not clear about my requirement.
BR,
Suhas

Hello Thomas,
What i meant was something like this:
WHERE key_field1 = ('<LT_TMP-COL1>') AND
      key_field2 = ('<LT_TMP-COL2>')
I am confused by what SAP means with "dynamic representation of internal table columns" in FAE ?
@Rob: I was referring to SAPNW 7.0 documentation & the phrase (release 6.40 & higher) is missing. Anyways fyi i am on ECC5.0 ABAP release 6.40.
@Subhankar: This is what Marcin had proposed in For all entries and dynamic table.
Thanks,
Suhas
Edited by: Suhas Saha on Apr 6, 2010 11:53 AM

Effect of appending standard internal table to hashed one ?

hi,
in my main program i have an internal table called NAST which is hashed. i call a function module which returns an internal table called xNAST, whose records i append to NAST. since i dealt with TABLES tab of FM, i had to receive this xNAST of type standard table (and not hashed).
i appended the lines of xNAST to NAST using INSERT statement.
Now at one point, i have a statement,
READ TABLE *nast INTO *xxx WITH KEY mmm = '100'.
so when i inserted the records into NAST from xNAST, they r automatically hashed, right ? and this statement will work without any issues ?
thks

Hello,
WITH KEY
For hashed tables, the hash algorithm is used if the specified search key includes the table key. Otherwise the search is linear. The addition BINARY SEARCH is not permitted for hashed tables.
Alternative
WITH TABLE KEY
Effect:
Each component of the table key must listed either directly as comp_name1 comp_name2 ..., or as a bracketed character-type data object name1 name2 ..., which contains the name of the component when the statement is executed (before release 6.10 in upper case). If name contains spaces only, this component specification is ignored when the statement is executed. A data object must be assigned to each component, which is compatible with or can be converted to the data type of the component. The first found line of the table is read, for which the values in the columns of the table key match the values in the assigned data objects dobj1 dobj2 .... If necessary, the content of dobj1 dobj2 ... is converted to the data type of the component before the comparison.
The different table types are accessed as follows:
standard tables are searched using a linear search.
sorted tables are searched using a binary search.
For hashed tables, the hash algorithm is used.
Regards.

Doubt in internal tables

hi experts
could you please tell difference between linear search, binary search and hashed mechanism.
above 3 which is faster and why.
if i use binary search in descending order it will search the records are not could please send why.

Hi Sayeed,
Standard table:
The key access to a standard table uses a sequential search. The time required for an access is linearly dependent on the number of entries in the internal table.
You should usually access a standard table with index operations.
Sorted table:
The table is always stored internally sorted by its key. Key access to a sorted table can therefore use a binary search. If the key is not unique, the entry with the lowest index is accessed. The time required for an access is logarithmically dependent on the number of entries in the internal table.
Index accesses to sorted tables are also allowed. You should usually access a sorted table using its key.
Hash table:
The table is internally managed with a hash procedure. All the entries must have a unique key. The time required for a key access is constant, that is it does not depend on the number of entries in the internal table.
You cannot access a hash table with an index. Accesses must use generic key operations (SORT, LOOP, etc.).
Index table:
The table can be a standard table or a sorted table.
Index access is allowed to such an index table. Index tables can be used to define the type of generic parameters of a FORM (subroutine) or a function module.
Just have a look at these links:
http://help.sap.com/saphelp_nw04/helpdata/en/90/8d7304b1af11d194f600a0c929b3c3/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/74/83015785d811d295a800a0c929b3c3/frameset.htm
Also Go through the following Document
1.1 STANDARD table
Key access to a standard table uses a linear search. This means that the time required for a search is in linear relation to the number of table entries.
You should use index operations to access standard tables.
1.2 SORTED table
Defines the table as one that is always saved correctly sorted.
Key access to a sorted table uses a binary key. If the key is not unique, the system takes the entry with the lowest index. The runtime required for key access is logarithmically related to the number of table entries.
1.3 HASHED table
Defines the table as one that is managed with an internal hash procedure
You can only access a hashed table using the generic key operations or other generic operations ( SORT, LOOP, and so on). Explicit or implicit index operations (such as LOOP ... FROM oe INSERT itab within a LOOP) are not allowed.
1.4 INDEX table
A table that can be accessed using an index.
Index table is only used to specify the type of generic parameters in a FORM or FUNCTION. That means that you can't create a table of type INDEX.
Standard tables and sorted tables are index tables.
1.5 ANY table
Any table is only used to specify the type of generic parameters in a FORM or FUNCTION. That means that you can't create a table of type ANY.
Standard, sorted and hashed tables belongs to ANY tables.
2. Defining an internal table
DATA itab TYPE table type of line type [WITH UNIQUE/NON-UNIQUE KEY <key>] [Iinitial size n] [WITH HEADER LINE]
Note: There are also other ways to define an internal table. Please refere to the documentation.
2.1 The KEY option
KEY key1,,keyn :
key1..keyn are fields in the table. The sequence in which you specify the key is significant.
DEFAULT KEY :
The key fields are the standard keys. Note that you can only specify an empty key for tables with access type STANDARD TABLE. The standard key basically comprises all tables fields with character-like types (type ( C, STRING, D, T, N, X, XSTRING). In particular, components with a numeric type (also refer to ABAP numeric types) and table components usually do not belong to the standard key.
Example:
types:
begin of t_makt,
    matnr like makt-matnr,
    maktx like makt-maktx,
end of t_makt.
data:
Define the table
gi_makt type sorted table of t_makt with unique key matnr.
Define the work area for the table if necessary
gi_makt type t_makt.
3. Reading internal tables
READ TABLE itab WITH TABLE KEY k1 = v1 k2 = v2 [additions]
Note: In case of more than one match, it is the first match that is selected.
STANDARD TABLE: The system searches from the start of the table. The response time is in linear relation to the number of table entries.
     SORTED TABLE: The response time is in logarithmic relation to the number of table entries.
     HASHED TABLE: The response time is constant
READ TABLE itab WITH KEY k1 = v1 k2 = v2 [BINARY SEARCH] [additions]
Note: In case of more than one match, it is the first match that is selected.
STANDARD TABLE: If you use the ... BINARY SEARCH addition, the system uses a binary search. Otherwise, the search is sequential. This assumes that the internal table is sorted in ascending order in the sequence of the specified key fields.
     SORTED TABLE: If the specified key fields form a left-justified extract of the table key, the search is binary, otherwise sequential.
     HASHED TABLE: Sequential search.
READ TABLE itab INDEX i [additions]
Accessing the table entry with the index i.
Additions:
INTO wa - wa is used as output area
     ASSIGNING <fs> - The field symbol <fs> is assigned to the entry. This saves the cost of copying the contents in comparison to the first addition. However, this addition does involve table administration costs, and it is therefore only worthwile for lines longer than around 300 bytes.
     COMPARING f1...fn - If the system find an entry, the system compares the subfields f1, f2, ... with the corresponding fields of the work area before they are transported into it.
     COMPARING ALL FIELDS
     TRANSPORTING f1 f2 - If the system finds an entry, it does not transfer all of the subfields (default) into the work area, but only the specified fields f1 f2 ...; the other subfields remain unchanged.
TRANSPORTING NO FIELDS
Example:
loop at gi_mseg into g_mseg.
   read table gi_makt
     with table key matnr = g_mseg-matnr
     into g_makt.
endloop.
Regards
Sreeni

Duplicate Entries in Internal Tables

Hallo Friends,
It Would be nice if some one let me know, if there is a way in ABAP to select the duplicates records in an internal tables.
Lets say I have two internal tabels, itabA have following structure:
BNAME |          WORKAREA   |   ROLES
abc |             wa1 |          ro1
cde |            wa1 |          ro1
cde |      wa3 |          rol..
abc |      wa2 |          rol2
xyz |       wa1 |          rol3
xyz |      wa3 |         rol2..
the itabB have the following structure:
WORKAREA |      ROLES|
wa1   |         rol1
wa2 |        rol1
wa3 |          rol1
wa4 |          rol1
Now problem is, I need to select the common WorkAreas from itabA ( which is commom in all BNAME ) in above example it will be workarea wa1. as it is commom in all i.e ( abc ,cde and xyz). I need to select this commom workarea, and then mark it with some flage in itabB ( to display that this workarea is common among the users...)
Would be nice if some one let me know, is there any way I can select the duplicate rows in an internal table or I have to go one by one and then do some kind of comparision.
Many thanks,
Thx in advance....
Haider

Hi marek,
below information might help you.
The first criterion for comparing internal tables is the number of lines they contain. The more lines an internal table contains, the larger it is. If two internal tables contain the same number of lines, they are compared line by line, component by component. If components of the table lines are themselves internal tables, they are compared recursively. If you are testing internal tables for anything other than equality, the comparison stops when it reaches the first pair of components that are unequal, and returns the corresponding result.
DATA: BEGIN OF LINE,
COL1 TYPE I,
COL2 TYPE I,
END OF LINE.
DATA: ITAB LIKE TABLE OF LINE,
JTAB LIKE TABLE OF LINE.
DO 3 TIMES.
LINE-COL1 = SY-INDEX.
LINE-COL2 = SY-INDEX ** 2.
APPEND LINE TO ITAB.
ENDDO.
MOVE ITAB TO JTAB.
LINE-COL1 = 10. LINE-COL2 = 20.
APPEND LINE TO ITAB.
IF ITAB GT JTAB.
WRITE / 'ITAB GT JTAB'.
ENDIF.
APPEND LINE TO JTAB.
IF ITAB EQ JTAB.
WRITE / 'ITAB EQ JTAB'.
ENDIF.
LINE-COL1 = 30. LINE-COL2 = 80.
APPEND LINE TO ITAB.
IF JTAB LE ITAB.
WRITE / 'JTAB LE ITAB'.
ENDIF.
LINE-COL1 = 50. LINE-COL2 = 60.
APPEND LINE TO JTAB.
IF ITAB NE JTAB.
WRITE / 'ITAB NE JTAB'.
ENDIF.
IF ITAB LT JTAB.
WRITE / 'ITAB LT JTAB'.
ENDIF.
The output is:
ITAB GT JTAB
ITAB EQ JTAB
JTAB LE ITAB
ITAB NE JTAB
ITAB LT JTAB
This example creates two standard tables, ITAB and JTAB. ITAB is filled with 3 lines and copied to JTAB. Then, another line is appended to ITAB and the first logical expression tests whether ITAB is greater than JTAB. After appending the same line to JTAB, the second logical expression tests whether both tables are equal. Then, another line is appended to ITAB and the third logical expressions tests whether JTAB is less than or equal to ITAB. Next, another line is appended to JTAB. Its contents are unequal to the contents of the last line of ITAB. The next logical expressions test whether ITAB is not equal to JTAB. The first table field whose contents are different in ITAB and JTAB is COL1 in the last line of the table: 30 in ITAB and 50 in JTAB. Therefore, in the last logical expression, ITAB is less than JTAB.
reward with points and close the thread if your question is solved
regards,
venu.

Making processing on an internal table generic

Hi,
I'm trying to make more generic a processing on an internal table.
Here's the idea :
"DELETE FROM TABLE T_VBAP every lines that do not exist IN table T_VBAK USING column VBELN for comparison"
You can see below the (not generic) version of this function.
I'd like to make it more generic.
It would be called this way :
     PERFORM reduire USING t_vbak t_vbap 'VBELN' 'vbak-vbeln'.
with the following code.
Here is my question :
How can I make the last statement generic too ?
DELETE <table_travail> WHERE (column) NOT IN <fs_tab> won't work...
Thanks a lot !
Jessie
Non-generic version :
FORM reduire.
DATA : liste_vbeln type range of vbak-vbeln,
               line_vbeln TYPE LINE OF liste_vbeln,
               lt_vbak TYPE TABLE OF ts_vbak,
               lt_vbap TYPE ts_vbak.
lt_vbak = t_vbak.
SORT lt_vbak BY vbeln.
DELETE ADJACENT DUPLICATES FROM lt_vbak COMPARGIN vbeln.
line_vbeln-sign = 'I'.
line_vbeln-option = 'EQ'.
LOOP AT lt_vbak INTO ls_vbak.
    line_vbeln-low = ls_vbak-vbeln.
    APPEND line_vbeln TO liste_vbeln.
ENDLOOP.
IF liste_vbeln IS INITIAL.
     CLEAR t_vbap.
ELSE.
    DELETE t_vbap WHERE vbeln NOT IN liste_vbeln.
ENDIF.
ENDFORM.
Generic version :
FORM reduire USING p_reference STANDARD TABLE
                    p_travail TYPE STANDARD TABLE
                         column TYPE lvc_name
                         column_type TYPE string.
     FIELD-SYMBOLS <table_reference> TYPE STANDARD TABLE.
     FIELD-SYMBOLS <table_reference_copy> TYPE STANDARD TABLE.
     ASSIGN p_reference to <table_reference>.
     FIELD-SYMBOLS <table_travail> TYPE STANDARD TABLE.
     ASSIGN p_travail to <table_travail>.
     FIELD-SYMBOLS <table_reference_fields> TYPE ANY.
     DATA gs_fldname TYPE REF TO DATA.
     CREATE DATA gs_fldname LIKE LINE OF <table_reference>.
     ASSIGN gs_fldname->* TO <table_reference_fields>.
     DATA position TYPE i.
     DATA dyn_table TYPE REF TO DATA.
     DATA wa_fieldcat TYPE lvc_s_fcat.
     DATA it_fieldcat TYPE lvc_t_fcat.
     DATA table_reference_copy_pre TYPE REF TO DATA.
     DATA l_descr_ref TYPE REF TO cl_abap_structdescr.
     FIELD-SYMBOLS <ls_tab> TYPE ANY.
     FIELD-SYMBOLS <field> TYPE ANY.
     FIELD-SYMBOLS <lfs_comp_wa> TYPE abap_compdescr.
     l_descr_ref ?= cl_abap_typedescr=>describe_by_data( <table_reference_fields> ).
     LOOP AT l_descr_ref->components[] ASSIGNING <lfs_comp_wa>.
          IF <lfs_comp_wa>-name = column.
               position = sy-tabix.
          ENDIF.
          CLEAR wa_fieldcat.
          wa_fieldcat-fieldname = <lfs_comp_wa>-name.
          wa_fieldcat-datatype = <lfs_comp_wa>-type_kind.
          wa_fieldcat-inttype   = <lfs_comp_wa>-type_kind.
          wa_fieldcat-intlen    = <lfs_comp_wa>-length / 2.
          wa_fieldcat-decimals = <lfs_comp_wa>-decimals.
          APPEND wa_fieldcat TO it_fieldcat.
     ENDLOOP.
     CALL METHOD cl_alv_table_create=>create_dynamic_table
          EXPORTING
               it_fieldcatalog = it_fieldcat
          IMPORTING
               ep_table = table_reference_copy_pre.
     ASSIGN table_reference_copy_pre->* TO <table_reference_copy>.
     <table_reference_copy> = p_reference.
     SORT <table_reference_copy> BY (column).
     DELETE ADJACENT DUPLICATES FROM <table_reference> COMPARING (column).
     DATA :
          gr_structdescr TYPE REF TO cl_abap_structdescr,
          gr_tabledescr TYPE REF TO cl_abap_tabledescr,
          gr_datadescr TYPE REF TO cl_abap_datadescr,
          gr_typedescr TYPE REF TO cl_abap_typedescr,
          gt_components TYPE abap_component_tab,
          gw_component TYPE LINE OF abap_component_tab,
          gr_wa TYPE REF TO DATA,
          gr_tab TYPE REF TO DATA.
     FIELD-SYMBOLS :
          <fs_wa> TYPE ANY,
          <fs_tab> TYPE TABLE.
     MOVE 'SIGN' to gw_component-name.
     gw_component-type ?= cl_abap_elemdescr=>get_c( p_length = 1 ).
     INSERT gw_component INTO TABLE gt_components.
     MOVE 'OPTION' to gw_component-name.
     gw_component-type ?= cl_abap_elemdescr=>get_c( p_length = 2 ).
     INSERT gw_component INTO TABLE gt_components.
     MOVE 'LOW' to gw_component-name.
     gw_component-type ?= cl_abap_elemdescr=>describe_by_name( column_type ).
     INSERT gw_component INTO TABLE gt_components.
     MOVE 'HIGH' to gw_component-name.
     gw_component-type ?= cl_abap_elemdescr=>describe_by_name( column_type ).
     INSERT gw_component INTO TABLE gt_components.
     gr_structdescr ?= cl_abap_structdescr=>create( gt_components ).
     CREATE DATA gr_wa TYPE HANDLE gr_structdescr.
     ASSIGN gr_wa->* to <fs_wa>.
     gr_datadescr ?= gr_structdescr.
     gr_tabledescr ?= cl_abap_tabledescr=>create( gr_datadescr ).
     CREATE DATA gr_tab TYPE HANDLE gr_datadescr.
     ASSIGN gr_tab->* TO <fs_tab>.
     LOOP AT <table_reference> ASSIGNING <ls_tab>.
          ASSIGN COMPONENT position OF STRUCTURE <ls_tab> to <field>.
          CONCATENATE 'IEQ' <field> INTO <fs_wa>.
          APPEND <fs_wa> TO <fs_tab>.
     ENDLOOP.
     DELETE t_vbap WHERE vbeln NOT IN <fs_tab>.
ENDFORM.

Hello Jessie,
Which ABAP Release are you working on? Dynamic WHERE conditions for LOOP AT itab, MODIFY itab, and DELETE itab statements are possible from Release 702.
Even if you're on 702, the statement DELETE <table_travail> WHERE (column) NOT IN <fs_tab> won't work! You need to change your coding to:
DATA lv_dyn_cond TYPE string.
CONCATENATE column `NOT IN` `<FS_TAB>` INTO lv_dyn_cond SEPARATED BY space.
DELETE <table_travail> WHERE (lv_dyn_cond).
BR,
Suhas

Comapare internal tables which are in tree format

Hi guys,
Consider internal table
     level | material-no.|quantity
      1 | mat-1 |              10
      2 |             mat-5 |             1
      3            |   mat-2    |           1
      3   |   mat-4 |      12
      2    | mat-12      | 11
      3    | mat-15      | 12
................................>mat1 ends here..it contains mat5 and mat 12 which in turn contain
.......................mat2 & 4 and mat 15 respectively.
      1    | mat-8     |    1
      2    | mat-6     |     3
      2    | mat-100    |    5
......................................>mat 8 ends here
      1 |    mat -6    |    13
.......................................>mat 6 ends here
This data is in one internal table, here there are 3 main materials (1,8,6) which are in-turn made of other materials.
material at level 1 is made of materials at level 2
and in-turn materials at level2 are made up of materials at level3 .
Now same material can exist at different levels ...
What would be the efficient way to compare two such internal tables and comparisons are done wrt quantity but level and hierarchy at which material exits matters and
comparison shuld be done at each level .
if both materials are in same hierarchy in both tables but diff in quantity then they are unequal .
if both materials are in same hierarchy in both tables and equal in quantity then they are equal .
if that material exist in one but doesnot exist in other table in similar hierarchy then its rendered as
not found.
many thanks in advance.

Hi Anurag,
Thanks for the reply but the number of levels is not always 3(it completely depends on data) .I came up with one solution --what I have done is , created one more column <b>HPATH</b> in the internal table and kept hierarchy relationship ..i.e
level| material| qty | HPATH(hierarchy path)
1 | mat-1 | 10 | mat-1
2 | mat-5 | 1 | mat-1 2 mat-5
3 | mat-2 | 1 | mat-1 2 mat-5 3 mat-2
3 | mat-4 | 12 | mat-1 2 mat-5 3 mat-4
2 | mat-12 | 11 | mat-1 2 mat-12
3 | mat-15 | 12 | mat-1 2 mat-12 3 mat-15
1 | mat-8 | 1 | mat-8
2 | mat-6 | 3 | mat-8 2 mat-6
2 | mat-100 | 5 | mat-8 2 mat-100
2 and 3 are the path seperates..which indicate the level..
Thus I get key as unique for each material depending on its position in heirarchy ..
Then I looped wrt one table and read data form other table with HPATH as key and compared it .
This solved it...
The number of levels doesnot matter in this solution...
Thanks once again for replying to my post. I would be to happy to put up the code if u want..

Compare two internal tables

hi everybody
i have two internal tables ITAB1 AND ITAB2
I WANT TO COMPARE THE CONTENTS OF THESE INTERNAL TABLES HOW TO DO THIS
REGARDS
HRIDHANJILI

Hello Hridhayanjili
The most detailed comparison is to use the same logic as change documents are prepared. Assuming both of your itabs are of structure struc_a. Then define the following type:
TYPES: BEGIN OF ty_s_itab_di.
INCLUDE TYPE struc_a.
TYPES: CHIND TYPE bu_chind.
TYPES: END OF ty_s_itab_di.
TYPES: ty_t_itab_di TYPE STANDARD TABLE OF ty_s_itab_di
WITH DEFAULT KEY.
DATA:
gt_itab_old TYPE ty_t_itab_di,
gt_itab_new TYPE ty_t_itab_di.
Fill itabs gt_Itab_old with the corresponding data of itab1 and gt_itab_new with the corresponding data of itab2.
Very important: sort you itabs either by all key fields or by all fields.
Call function CHANGEDOCUMENT_PREPARE_TABLES with the following parameters
- CHECK_INDICATOR = ' '
- TABLE_NEW = gt_Itab_new
- TABLE_OLD = gt_itab_old
The function module will remove identical lines from both itabs. New entries in gt_itab_New will have CHIND = 'I' and deleted entries in gt_itab_old will have CHIND = 'D'.
Read the documentation of the function module and play around with it. You will see that this a quite easy yet powerful approach for comparing itabs.
Regards
Uwe

Internal table Comparison

Similar Messages

Maybe you are looking for