Internal Table Line Operations - Collect Statement
Hello Gurus,
I have an internal table with data in it. The fields of the internal table are
Location - Matnr - Qty - Flag.
Same material can be at different locations with different quantities. I need to get material and total quantity of the material in all the locations in a new internal table.
If the table (it_tab) contains -
Location - matnr - qty - flag
1200 abc 10 S
1201 abc 20 S
1205 abc 30 S
1207 abc 50 S
1200 xyz 20 S
1201 xyz 25 S
1300 xyz 22 S
From this table, I need to get the result int table (it_res) as below -
Matnr - qty
abc 110
xyz 67
110 = 102030+50
67 = 252220
My idea is we can use collect statement looping the it_tab table.
Please help me how to do this.
Regards,
Balu
Hi balu,
1. Simple
2. Create one another internal table STAB,
with only two fields
a) MATNR
b) QTY
3. Now,
4.
Loop at Itab.
Move-corresponding itab to STAB.
COLLECT STAB.
Endloop.
regards,
amit m.
Similar Messages
-
How to join THREE different tables into internal table using one select statement .
How to join THREE different tables into internal table using one select statement .
Hi experts,
I would like to request your guidance in solving the problem of joining the data from three different database tables into one internal table
Scenario:
Database tables:
SPFLI
SFLIGHT
SBOOK.
Table Fields:
SPFLI - CARRID CONNID COUNTRYFR CITYFRM COUNTRYTO CITYTO
SFLIGHT - CARRID CONNID FLDATE SEATSMAX SEATSOCC SEATSMAX_C
SEATSOCC_C SEATSMAX_F SEATSOCC_F
SBOOK - CARRID CONNID CLASS
MY INTERNAL TABLE IS IT_XX.
Your help much appreciated.
Thanks in advance.
Pawan.Hi Pawan,
please check below codes. hope it can help you.
TYPES: BEGIN OF ty_xx,
carrid TYPE spfli-carrid ,
connid TYPE spfli-connid ,
countryfr TYPE spfli-countryfr,
cityfrom TYPE spfli-cityfrom ,
countryto TYPE spfli-countryto,
cityto TYPE spfli-cityto ,
fldate TYPE sflight-fldate ,
seatsmax TYPE sflight-seatsmax ,
seatsocc TYPE sflight-seatsocc ,
seatsmax_b TYPE sflight-seatsmax_b,
seatsocc_b TYPE sflight-seatsocc_b,
seatsmax_f TYPE sflight-seatsmax_f,
seatsocc_f TYPE sflight-seatsocc_f,
class TYPE sbook-class,
END OF ty_xx,
t_xx TYPE STANDARD TABLE OF ty_xx.
DATA: it_xx TYPE t_xx.
SELECT spfli~carrid
spfli~connid
spfli~countryfr
spfli~cityfrom
spfli~countryto
spfli~cityto
sflight~fldate
sflight~seatsmax
sflight~seatsocc
sflight~seatsmax_b
sflight~seatsocc_b
sflight~seatsmax_f
sflight~seatsocc_f
sbook~class
INTO TABLE it_xx
FROM spfli INNER JOIN sflight
ON spfli~carrid = sflight~carrid
AND spfli~connid = sflight~connid
INNER JOIN sbook
ON spfli~carrid = sbook~carrid
AND spfli~connid = sbook~connid.
Thanks,
Yawa -
Internal table name which hide statement uses
Hi,
To hide several variables, use chain HIDE statement.
As soon as the user selects a line for which you stored HIDE fields, the system fills the variables in the program with the values stored. A line can be selected.
¨ By an interactive event.
For each interactive event, the HIDE fields of the line on which the cursor is positioned during the event are filled with the stored values.
The HIDE area is a table, in which the system stores the names and values of all HIDE fields for each list and line number. As soon as they are needed, the system reads the values from the table.
I want to know how can we find the name of that internal table.
Regards,
maqsoodHi,
i think it is system defined.
The HIDE Technique
You use the HIDE technique while creating a list level to store line-specific information for later use. To do so, use the HIDE statement as follows:
HIDE <f>.
This statement places the contents of the variable <f> for the current output line (system field SY-LINNO) into the HIDE area. The variable <f> must not necessarily appear on the current line.
To make your program more readable, always place the HIDE statement directly after the output statement for the variable <f> or after the last output statement for the current line.
As soon as the user selects a line for which you stored HIDE fields, the system fills the variables in the program with the values stored. A line can be selected
by an interactive event.
For each interactive event, the HIDE fields of the line on which the cursor is positioned during the event are filled with the stored values.
by the READ LINE statement.
<b>You can think of the HIDE area as a table, in which the system stores the names and values of all HIDE fields for each list and line number. As soon as they are needed, the system reads the values from the table.</b>
Thanks&Regards,
Ruthra.R -
Dynamic internal table and dynamic read statements.
Hi,
My Scenario :
I have two dynamic internal tables.
I am looping at one internal table and trying to read another table.
In the read statement how do I mention the key dyamically.
Example code below :
LOOP AT <dyn_table> ASSIGNING <dyn_wa>.
read second dynamic internal table.
enloop.
The key which I want use for reading say it is keyed in the selection criteria....
Also based on the value I read I want to modify the first internal table field value.
Remember I dont want to explicity mention the key
How do I do that?
Thanks
Krishna.Hi
U need to use the field-symbol, but u can't use a WHERE option, but u need to use the CHECK statament into the second loop:
LOOP AT <dyn_table> ASSIGNING <dyn_wa>.
LOOP AT <DYN_TABLE2> ASSIGNING <DYN_WA2>.
ASSIGN COMPONENT <COMPONENT> OF STRUCTURE <DYN_WA2> TO <FS>.
CHECK <FS> IN (=) .......
ASSIGN COMPONENT <COMPONENT> OF STRUCTURE <DYN_WA> TO <FS2>.
<FS2> = .......
EXIT.
ENDLOOP.
ENDLOOP.
Max -
Problem in the internal table of open dataset statement
Hi abapers,
I am using the open dataset command to download my file at application server into an internal table.
But some colums of the internal table are string since i do not want to truncate any of the long text present in the file.
The open dataset command does not allow the internal table to have string components.
Is there any workaround by which i can download all the text components of the file without truncating them .
Regards,
Adityatry to use field symbols:-
FORM download_file .
DATA: l_file TYPE rlgrap-filename,
l_line TYPE string.
DATA: v_excel_string(1000) TYPE c,
v_len TYPE i,
v_zover TYPE i .
FIELD-SYMBOLS: <f> TYPE ANY .
CLEAR wa_fin.
*--- Seting File path
CONCATENATE p_cfile v_file sy-datum INTO l_file.
*--- Open data set
OPEN DATASET l_file FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.
IF sy-subrc = 0.
LOOP AT it_down INTO wa_down.
CLEAR : v_excel_string, v_zover, v_len.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE wa_down TO <f>.
IF sy-subrc <> 0.
EXIT. "exits do loop and process next record in itab
ENDIF.
DESCRIBE FIELD <f> LENGTH v_len IN CHARACTER MODE.
v_excel_string+v_zover(v_len) = <f> .
v_zover = v_zover + v_len .
ENDDO.
TRANSFER v_excel_string TO l_file.
CLEAR : v_excel_string,
wa_down ,
v_zover .
ENDLOOP.
*--- Close data set
CLOSE DATASET l_file.
IF sy-subrc = 0.
*--- Success Message
MESSAGE s000(000) WITH text-018.
ENDIF.
ELSE.
*--- Error unable to open file.
MESSAGE e000(000) WITH text-017.
ENDIF.
ENDFORM. " DOWNLOAD_FILE
Thanks ,
Ruchi Tiwari -
How does the (ABAP) AS handle unused internal tables? (garbage collection?)
Hi,
Let's suppose i have a class, which contains a simple method like follow:
method do_this.
data lt_table type something_tab.
"do some manipulation on the lt_table.
endmethod.
So during runtime, at the moment when we leave the method "do_this", will the lt_table memory space be freed? Or is it still allocated? Do we need to use an explicit "free lt_table" statement?
I want to optimise memory usage in my code, and was wondering if such explicit calls to "free" is necessary.
Thank you,
Edited by: Huynh Van Du Tran on Mar 16, 2009 6:38 PMHi,
I would say it would be better use FREE itab at the end of the processing in your code. In the end-of-selection in your code, you can FREE all your itabs that were used in the program. This is one of the good approach of optimizing the memory.
Regards
Vimal -
Control statement in internal tables
hi experts,
can any body will provide me the control statement of internal table.
thank youHi,
check this link
http://help.sap.com/saphelp_nw2004s/helpdata/en/9f/db9f1f35c111d1829f0000e829fbfe/content.htm
Control Break Statements
Control break statements are used to create statement blocks which process only specific table lines the LOOP ENDLOOP block.
You open such a statement block with the control level statement AT and close it with the control level statement ENDAT. The syntax is as follows:
Table should be sorted when you use control-break statements
You can break the sequential access of internal tables by using these statements.
Syntax:
At first.
<Statement block>
Endat.
This is the first statement to get executed inside the loop (remember control break statements are applicable only inside the loop)
So in this block you can write or process those statements which you want to get executed when the loop starts.
At New carrid.
Write:/ carrid.
Endat.
In this case whenever the new carrid is reached, carrid will be written.
At End of carrid.
Uline.
Endat.
In this case whenever the end of carrid is reached, a line will be drawn.
At Last.
Write:/ Last Record is reached.
Endat.
Processing of statements within this block is done when entire processing of entire internal table is over. Usually used to display grand totals.
You can use either all or one of the above control break statements with in the loop for processing internal table.
At end of carrid.
Sum.
Endat.
In above case the statement SUM (applicable only within AT-ENDAT) will sum up all the numeric fields in internal table and result is stored in same internal table variable.
Regards,
Sruthi -
Three select statement data in to One Internal table
HI All,
By using 3 select statement, data is displying by using work area (classical report). Now i want define three internal table for three select statements, and finally get the data in one final itab, and pass this to function module (ALV Report).
looking for responsehi,
just go through this simple example. no need of declaring 3 itabs.
data: begin of st1,
a1 type c,
a11 type i,
end of st1.
data: begin of st2,
a2 type i,
a22 type c,
end of st2.
data: begin of st3,
a3 type i,
a33 type i,
end of st3.
data: begin of fin_struct.
include structure st1.
include structure st2.
include structure st3.
data: end of fin_struct.
data: fin_itab like table of fin_struct with header line.
*1st structure values
move 'a' to fin_itab-a1.
move 1 to fin_itab-a11.
*2nd structure values
move 11 to fin_itab-a2.
move 'b' to fin_itab-a22.
*3rd structure values
move 15 to fin_itab-a3.
move 12 to fin_itab-a33.
*appending 1st record.
append fin_itab.
*1st strcuct values
move 'b' to fin_itab-a1.
move 3 to fin_itab-a11.
*2nd structure values
move 22 to fin_itab-a2.
move 'c' to fin_itab-a22.
*3rd structure values
move 20 to fin_itab-a3.
move 30 to fin_itab-a33.
*appending 2nd record.
append fin_itab.
loop at fin_itab.
write:/ fin_itab-a1, fin_itab-a11, fin_itab-a2, fin_itab-a22, fin_itab-a3, fin_itab-a33.
endloop.
here structre1,2,3...
i used move statement.
here u write select statement.. into struct1,2,3....
using move u move all the values ...
finally append it to final itab...
rest of and all common for ALV...
Regards,
Shankar. -
Internal tables whose line type contains further internal tables
Hi,
can you please demonstrate through a code sniplet the follwing topics .
structures containing internal tables as components (deep structures)
Internal tables whose line type contains further internal tables.
Thx in advance
Regards
sasHi,
Check the code
TYPES : BEGIN OF t_gr,
wrbtr TYPE ekbe-wrbtr,
menge TYPE ekbe-menge,
bwart TYPE ekbe-bwart,
END OF t_gr.
DATA : i_gr TYPE TABLE OF t_gr.
TYPES : BEGIN OF t_ekbe,
ebeln TYPE ekbe-ebeln,
ebelp TYPE ekbe-ebelp,
*llggr LIKE i_gr,*
END OF t_ekbe.
DATA : i_ekbe TYPE TABLE OF t_ekbe.
SELECT ebeln
ebelp
wrbtr
FROM ekbe
INTO TABLE i_ekbe1
FOR ALL ENTRIES IN i_data1
WHERE ebeln = i_data1-ebeln AND
ebelp = i_data1-ebelp AND
bewtp = c_e AND
( bwart = c_101 OR
bwart = c_102 OR
bwart = c_103 OR
bwart = c_104 ).
loop at i_ekbe1 into wa_ekbe1.
wa_ekbe = wa_ekbe1.
wa_gr-wrbtr = wa_ekbe-wrbtr
append wa_gr to i_gr.
on change of wa_ekbe1-ebeln.
*INSERT LINES OF i_gr INTO wa_ekbe-llggr INDEX 1.*
*APPEND wa_ekbe TO i_ekbe.*
endon.
edloop.
the above code the ekbe table is having one move itab l_gr
l_gr is updated in each loop and and each change the i_ekbe is updated with one set of l_gr data as internal table line for i_ekbe.
regards,
Nandha -
Summarizing records in a internal table
hi
what is meant by summarizing records in an internal table
vamsiHI
please go through this:
u will get some idea.
Appending Summarized Lines
The following statement allows you to summate entries in an internal table:
COLLECT <wa> INTO <itab>.
<itab> must have a flat line type, and all of the fields that are not part of the table key must have
a numeric type (F, I, or P). You specify the line that you want to add in a work area that is
compatible with the line type.
When the line is inserted, the system checks whether there is already a table entry that matches
the key. If there is no corresponding entry already in the table, the COLLECT statement has the
same effect as inserting the new line [Page 282]. If an entry with the same key already exists, the
COLLECT statement does not append a new line, but adds the contents of the numeric fields in
the work area to the contents of the numeric fields in the existing entry.
You should only use the COLLECT statement if you want to create summarized tables. If you
use other statements to insert table entries, you may end up with duplicate entries.
Lines are added to internal tables as follows:
Standard tables
If the COLLECT statement is the first statement to fill the standard table, the system
creates a temporary hash administration that identifies existing entries in the table. The
hash administration is retained until another statement changes the contents of key fields
or changes the sequence of the lines in the internal table. After this, the system finds
existing entries using a linear search. The runtime for this operation increases in linear
relation to the number of existing table entries. The system field SY-TABIX contains the
index of the line inserted or modified in the COLLECT statement.
Sorted tables
The system uses a binary search to locate existing lines. The runtime for the operation
increases logarithmically with the number of existing lines. The system field SY-TABIX
contains the index of the line inserted or modified in the COLLECT statement.
Hashed tables
The system finds existing lines using the hash algorithm of the internal table. After the
COLLECT statement, the system field SY-TABIX has the value 0, since hashed tables
have no linear index.
Example
DATA: BEGIN OF LINE,
COL1(3) TYPE C,
COL2(2) TYPE N,
COL3 TYPE I,
END OF LINE.
DATA ITAB LIKE SORTED TABLE OF LINE
WITH NON-UNIQUE KEY COL1 COL2.
BC - ABAP Programming SAP AG
Appending Summarized Lines
286 April 2001
LINE-COL1 = 'abc'. LINE-COL2 = '12'. LINE-COL3 = 3.
COLLECT LINE INTO ITAB.
WRITE / SY-TABIX.
LINE-COL1 = 'def'. LINE-COL2 = '34'. LINE-COL3 = 5.
COLLECT LINE INTO ITAB.
WRITE / SY-TABIX.
LINE-COL1 = 'abc'. LINE-COL2 = '12'. LINE-COL3 = 7.
COLLECT LINE INTO ITAB.
WRITE / SY-TABIX.
LOOP AT ITAB INTO LINE.
WRITE: / LINE-COL1, LINE-COL2, LINE-COL3.
ENDLOOP.
Thanks
Shiva -
Importing internal table from one program to another program
Hi everybody,
i have one small doubt.
i am using submit statement and passing the values from this program to another program selection screen. in that program logic is written.In that program one internal table values are being exported to the memory id of that program. now i have to import that internal table values into my program by using import statement. i am using the following syntax
import itab from menory id 'program name'.
but i am getting an error saying program name is unknown.
what is the exat syntax for this .
thanking you,
giri.hi,
check these statements.
IMPORT - Get data
Variants:
1. IMPORT obj1 ... objn FROM DATA BUFFER f.
2. IMPORT obj1 ... objn FROM INTERNAL TABLE itab.
2. IMPORT obj1 ... objn FROM MEMORY.
3. IMPORT obj1 ... objn FROM SHARED MEMORY itab(ar) ID key.
4. IMPORT obj1 ... objn FROM SHARED BUFFER itab(ar) ID key.
5. IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.
6. IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.
7. IMPORT obj1 ... objn FROM LOGFILE ID key.
8. IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.
9. IMPORT (itab) FROM ... .
In some cases, the syntax rules that apply to Unicode programs are different than those for non-Unicode programs. For more details, see Storing Cluster Tables.
Variant 1
IMPORT obj1 ... objn FROM DATA BUFFER f.
Extras:
1. ... = f (for each object to be imported)
2. ... TO f (for each object to be imported)
3. ... ACCEPTING PADDING
4. ... ACCEPTING TRUNCATION
5. ... IGNORING STRUCTURE BOUNDARIES
6. ... IGNORING CONVERSION ERRORS
7. ... REPLACEMENT CHARACTER c
8. ... IN CHAR-TO-HEX MODE
9. ... CODE PAGE INTO f1
10. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See You Cannot Use Implicit Field Names in Clusters.
Effect
Imports the data objects obj1 ... objn from the data buffer declared. The data buffer must be of type XSTRING . The data objects obj1 ... objn can be fields, structures, complex structures, or tables. The system imports all the data that has been stored in the data buffer f using the EXPORT ... TO DATA BUFFER statement and is listed here. It also checks that the structure used in the IMPORT statement matches the one in the EXPORT statement.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged. (In some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported. The contents of all the objects remain unchanged.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is stored in the field f.
Addition 3
... ACCEPTING PADDING
Effect
This addition allows you to append new fields to the end
of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 4
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR
fields, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 5
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is
relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 3 (enlarge structure) or addition 4 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Addition 6
...IGNORING CONVERSION ERRORS
Effect
This addition prevents the system from triggering a
runtime error, if an error occurs when the character set is converted. '#' is used as a replacement character.
Addition 7
... REPLACEMENT CHARACTER c
Effect
The replacement character is used if a particular
character cannot be converted when the character set is converted.
This addition can only be used in conjunction with addition 6.
Addition 8
... IN CHAR-TO-HEX MODE
Effect
Not all character-type fields are converted. To convert
a field, you must create a field (or structure) that is identical to the exported field or structure, except that all its character-type components must be replaced with hexadecimal fields.
You can only use this addition in Unicode programs, to allow you to import camouflaged binary data as single-byte characters.
Moreover, you cannot use this addition in conjunction with the additions 3, 4, 5, 6, or 7.
Addition 9
... CODE PAGE INTO f1
Effect
The code page of the exported data is stored in the
character-type field f1 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition.
Addition 10
... ENDIAN INTO f2
Effect
The byte order (LITTLE or BIG) of the
exported data is stored in the field f2 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition. The field f2 must have the type ABAP_ENDIAN, which is defined in the type group ABAP. For this reason, the type group ABAP must be included in the ABAP program using a TYPE-POOLS statement.
Variant 2
IMPORT obj1 ... objn FROM INTERNAL TABLE itab.
Extras:
1. ... = f (for each object to be imported)
2. ... TO f (for each object to be imported)
3. ... ACCEPTING PADDING
4. ... ACCEPTING TRUNCATION
5. ... IGNORING STRUCTURE BOUNDARIES
6. ... IGNORING CONVERSION ERRORS
7. ... REPLACEMENT CHARACTER c
8. ... IN CHAR-TO-HEX MODE
9. ... CODE PAGE INTO f1
10. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See No implicit field names in cluster.
Effect
Imports the data objects obj1 ... objn (fields, structures, complex structures, or tables) from the specified internal table itab. The first column in the internal table must be of the predefined type INT2 and the second must be type X. To define the first column you must refer to a data element in the ABAP Dictionary that has the predefined type INT2.
All data that was stored in the internal table itab using EXPORT ... TO INTERNAL TABLE and listed, is imported. The system checks that the EXPORT and IMPORT structures match.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the specified data cluster were imported, the rest remain unchanged (it is possible that no data object was imported).
SY-SUBRC = 4:
The data objects could not be imported.
The contents of all listed objects remain unchanged
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
Places the object in the field f.
Addition 3
... ACCEPTING PADDING
Effect
This addition allows you to add new fields to the ends
of structures, even to substructures and internal tables (the additional fields are filled with initial value during the IMPORT). It also allows you to increase the size of existing fields (C, N, X, P, I1, and I2) and to map Char fields to STRING type fields or byte fields to XSTRING type fields.
Addition 4
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR
field or omit the last component on the highest level (till Release 4.6 this was possible without specifying an addition).
Addition 5
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the page order is
relevant, that is any substructures match. With this addition, the system also ignores alignment changes arising from the Unicode conversion (for example, due to subsequent insertion of named includes).
This addition rules out any subsequent structural enhancements (addition 3) or structural shortening (addition 4) because with this addition it is the structural limits and include limits that are to be ignored.
As from Release 6.10, the include information will also be stored in the dataset, so that it is possible to also check whether the includes match, that is substructures and includes (named or unnamed) are treated the same. When importing data that was exported in a Release lower than 6.10, the includes are not checked.
Addition 6
...IGNORING CONVERSION ERRORS
Effect
This addition has the effect that an error in the
character set conversion does not cause a runtime error. The system uses "#" as a replacement character.
Addition 7
... REPLACEMENT CHARACTER c
Effect
The system uses the specified replacement character if a
character cannot be converted during a character set conversion. If this addition is not specified, the system uses "#" as a replacement character.
This addition can only be used in conjunction with addition 6.
Addition 8
... IN CHAR-TO-HEX MODE
Effect
No character type fields are converted. For this you
must create a field or structure that is identical to the exported field or exported structure, except that all character type fields must be replaced with hexadecimal fields.
This addition, which is only allowed in programs with a set Unicode flag, allows you to import binary data disguised as single byte characters. This addition cannot be used in conjunction with additions 3, 4, 5, 6, and 7.
Addition 9
... CODE PAGE INTO f1
Effect
The codepage of the exported data is stored in the
character-type field f1 (for example, to be able to analyze the data imported with the addition IN CHAR-TO-HEX MODE).
Addition 10
... ENDIAN INTO f2
Effect
The byte order (LITTLE or BIG) of the
exported data is stored in the field f2 (for example, to be able analyze the data imported using the addition IN CHAR-TO-HEX MODE). The field f2 must be of type ABAP_ENDIAN, defined in type group ABAP. You must therefore include the type group ABAP in the ABAP program with a TYPE-POOLS statement.
Variant 3
IMPORT obj1 ... objn FROM MEMORY.
Extras:
1. ... = f (for each object to be imported) 2. ... TO f (for each object to be imported)
3. ... ID key
4. ... ACCEPTING PADDING
5. ... ACCEPTING TRUNCATION
6. ... IGNORING STRUCTURE BOUNDARIES
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See You Must Enter Identification and Cannot Use Implicit Field Names inClusters
Effect
Imports data objects obj1 ... objn (fields, structures, complex structures or tables) from a data cluster in the ABAP memory (see EXPORT). Reads in all data without an ID that was exported to memory with "EXPORT ... TO MEMORY.". In contrast to the variant IMPORT FROM DATABASE, it does not check that the structure matches in EXPORT and IMPORT.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because the ABAP memory was empty.
The contents of all objects remain unchanged.
Note
You should always use the addition 3 (... ID key) with the statement. Otherwise, the effect of the variant is not certain (EXPORT statements in different parts of a program overwrite each other in the ABAP memory), since it exists only for reasons of compatibility with R/2.
Additional methods for selecting and deleting data clusters in the ABAP memory are provided by the system class CL_ABAP_EXPIMP_MEM.
Please consult Data Area and Modularization Unit Organization documentation as well.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in field f.
Addition 3
... ID key
Effect
Imports only data stored in ABAP memory under the ID key.
Notes
The key, key, must be a character-type data object (but not a string).
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.
Addition 4
... ACCEPTING PADDING
Effect
This addition allows you to append new fields to the end of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 5
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR field, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 6
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 3 (enlarge structure) or addition 4 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Related
EXPORT TO MEMORY, DELETE FROM MEMORY, FREE MEMORY
Variant 4
IMPORT obj1 ... objn FROM SHARED MEMORY itab(ar) ID key.
Extras:
1. ... = f (for each object to be exported) 2. ... TO f (for each object to be exported)
3. ... CLIENT g (before ID key)
4. ... TO wa (after itab(ar) or ID key )
5. ... ACCEPTING PADDING
6. ... ACCEPTING TRUNCATION
7. ... IGNORING STRUCTURE BOUNDARIES
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See You Cannot Use Implicit Field Names in Clusters and You Cannot Use Table Work Areas.
Effect
Imports the data objects obj1 ... objn (fields, structures, complex structures, or tables) from shared memory. The data objects are read using the ID key from the area ar in the table itab - c.f. EXPORT TO SHARED MEMORY). You must use itab to specify a database table although the system reads from a memory table with the appropriate structure.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged. (In some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported. You may have used the wrong ID. The contents of all the objects remain unchanged.
Notes
The table dbtab named according to SHARED MEMORY must be declared using TABLES (except in addition 2).
The structure of fields (field symbols and internal tables) to be imported must match the structure of the objects exported in the dataset. The objects must be imported under the same names as those under which they were exported. Otherwise, they will not be imported.
The key length consists of: the client (3 digits, but only if tab is client-specific); area (2 characters); ID; and line number (4 bytes). It must not exceed 64 bytes - that is, the ID must not be longer than 55 characters, if the table is client- specific.
The key, key, must be a character-type data object (but not a string).
Additional methods for selecting and deleting data clusters in the shared memory are provided by the system class CL_ABAP_EXPIMP_SHMEM.
Please consult Data Area and Modularization Unit Organization documentation as well.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is stored in the field f.
Addition 3
... CLIENT g (before ID key)
Effect
The data is imported from client g (provided the import/export table is tab client-specific). The client, g must be a character-type data object (but not a string).
Addition 4
... TO wa (after itab(ar) or ID key)
Effect
You need to use this addition if user data fields have been stored in the application buffer and are to be read from there. The work area wa is used instead of the table work area. The target area must correspond to the structure of the called table tab.
Addition 5
... ACCEPTING PADDING
Effect
This addition allows you to: append new fields to the end of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 6
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR fields, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 7
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 4 (enlarge structure) or addition 5 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Related
EXPORT TO SHARED MEMORY, DELETE FROM SHARED MEMORY
Variant 5
IMPORT obj1 ... objn FROM SHARED BUFFER itab(ar) ID key.
Extras:
1. ... = f (for each object to be exported) 2. ... TO f (for each object to be exported)
3. ... CLIENT g (before ID key)
4. ... TO wa (last addition or after itab(ar))
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See Cannot Use Implicit Fieldnames in Clusters und Cannot Use Table Work Areas.
Effect
Imports data objects obj1 ... objn (fields or
tables) from the cross-transaction application buffer. The data objects are read in the application buffer using the ID key of the area ar of the buffer area for the table itab (see EXPORT TO SHARED BUFFER). You must use dbtab to specify a database table although the system reads from a memory table with an appropriate structure.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this means that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.
Example
Import two fields and an internal table from the application buffer with the structure INDX:
TYPES: BEGIN OF ITAB3_LINE,
CONT(4),
END OF ITAB3_LINE.
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',
F1(4),
F2(8) TYPE P DECIMALS 0,
ITAB3 TYPE STANDARD TABLE OF ITAB3_LINE,
INDX_WA TYPE INDX.
Import data.
IMPORT F1 = F1 F2 = F2 ITAB3 = ITAB3
FROM SHARED BUFFER INDX(ST) ID INDXKEY TO INDX_WA.
After import, the data fields INDX-AEDAT and
INDX-USERA in front of CLUSTR are filled with
the values in the fields before the EXPORT
statement.
Notes
You must declare the table dbtab, named after DATABASE using a TABLES statement.
The structure of the fields, structures, and internal tables to be imported must match the structure of the objects exported to the dataset. Moreover, the objects must be imported with the same name used to export them. Otherwise, the import is not performed.
The maximum total key length is 64 bytes. It must include: a client if the table is client-specific (3 characters); an area (2 characters); identification; and line counter (4 bytes). This means that the number of characters available for the identification of a client-specific table is 55 characters.
The key, key, must be a character-type data object (but not a string).
Additional methods for selecting and deleting data clusters in the cross-transaction application buffer are provided by the system class CL_ABAP_EXPIMP_SHBUF.
Please consult Data Area and Modularization Unit Organization documentation as well.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in the field f
Addition 3
... CLIENT g (after dbtab(ar))
Effect
Takes the data from the client g (if the import/export table dbtab is client-specific). The client g must be a character-type data object (but not a string).
Addition 4
... TO wa (as the last addition or after itab(ar))
Effect
You need to use this addition if you want to save user data fields in the application buffer and then read them from there later. The system uses a work area wa instead of a table work area. The target area must have the same structure as the table tab.
Example
DATA: INDX_WA TYPE INDX,
F1.
IMPORT F1 = F1 FROM SHARED BUFFER INDX(AR)
CLIENT '001' ID 'TEST'
TO INDX_WA.
WRITE: / 'AEDAT:', INDX_WA-AEDAT,
/ 'USERA:', INDX_WA-USERA,
/ 'PGMID:', INDX_WA-PGMID.
Variant 6
IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.
Extras:
1. ... = f (for each object to be imported)
2. ... TO f (for each object to be imported)
3. ... CLIENT g (before ID key )
4. ... USING form
5. ... TO wa (last addition or after dbtab(ar))
6. ... MAJOR-ID id1 (instead of ID key)
7. ... MINOR-ID id2 (with MAJOR-ID id1 )
8. ... ACCEPTING PADDING
9. ... ACCEPTING TRUNCATION
10. ... IGNORING STRUCTURE BOUNDARIES
11. ... IGNORING CONVERSION ERRORS
12. ... REPLACEMENT CHARACTER c
13. ... IN CHAR-TO-HEX MODE
14. ... CODE PAGE INTO f1
15. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Implicit Fieldnames in Clusters and Cannot Use Table Work Areas.
Effect
Imports data objects obj1 ... objn (fields, structures, complex structures, or tables) from the data cluster with ID key in area ar of the database table dbtab (see EXPORT TO DATABASE).
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that not data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.
Example
Import two fields and an internal table:
TYPES: BEGIN OF TAB3_TYPE,
CONT(4),
END OF TAB3_TYPE.
DATA: INDXKEY LIKE INDX-SRTFD,
F1(4), F2 TYPE P,
TAB3 TYPE STANDARD TABLE OF TAB3_TYPE WITH
NON-UNIQUE DEFAULT KEY,
WA_INDX TYPE INDX.
INDXKEY = 'INDXKEY'.
IMPORT F1 = F1
F2 = F2
TAB3 = TAB3 FROM DATABASE INDX(ST) ID INDXKEY
TO WA_INDX.
Notes
You must declare the table dbtab, named after DATABASE, using the TABLES statement (except in addition 5).
The structure of fields, field strings and internal tables to be imported must match the structure of the objects exported to the dataset. In addition, the objects must be imported under the same name used to export them. If this is not the case, either a runtime error occurs or no import takes place.
Exception: You can lengthen or shorten the last field if it is of type CHAR, or add/omit CHAR fields at the end of the structure.
The key, key, must be a character-type data object (but not a string).
Additional methods for selecting and deleting data clusters in the database table specified are provided by the system class CL_ABAP_EXPIMP_DB.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in field f.
Addition 3
... CLIENT g (before the ID key)
Effect
Data is taken from the client g (in client-specific import/export databases only). Client g must be a character-type data object (but not a string).
Example
DATA: F1,
WA_INDX TYPE INDX.
IMPORT F1 = F1 FROM DATABASE INDX(AR) CLIENT '002' ID 'TEST'
TO WA_INDX.
Addition 4
... USING form
Note
This statement is for internal use only.
Incompatible changes or further developments may occur at any time without warning or notice.
Effect
Does not read the data from the database. Instead, calls the FORM routine form for each record read from the database without this addition. This routine can take the data key of the data to be retrieved from the database table work area and write the retrieved data to this work area. The name of the routine has the format <name of database table>_<name of form>; it has one parameter which describes the operation (READ, UPDATE or INSERT). The routine must set the field SY-SUBRC in order to show whether the function was successfully performed.
Addition 5
... TO wa (after key or after dbtab(ar))
Effect
You need to use this addition if you want to save user data fields in the cluster database and then read from there. The system uses the work area wa instead of a table work area. The target area entered must have the same structure as the table dbtab.
Example
DATA WA LIKE INDX.
DATA F1.
IMPORT F1 = F1 FROM DATABASE INDX(AR)
CLIENT '002' ID 'TEST'
TO WA.
WRITE: / 'AEDAT:', WA-AEDAT,
/ 'USERA:', WA-USERA,
/ 'PGMID:', WA-PGMID.
Addition 6
... MAJOR-ID id1 (instead of the ID key).
Addition 7
... MINOR-ID id2 (with MAJOR-ID id1)
This addition is not allowed in an ABAP Objects context. See Cannot Use Generic Identification.
Effect
Searches for a record the first part of whose ID (length of id1) matches id1 and whose second part - if MINOR-ID id2 is also declared - is greater than or equal to id2.
Addition 8
... ACCEPTING PADDING
Effect
This addition allows you to append new fields to the end of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 9
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR fields, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 10
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 8 (enlarge structure) or addition 9 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Addition 11
...IGNORING CONVERSION ERRORS
Effect
This addition prevents the system from triggering a runtime error, if an error occurs when the character set is converted. '#' is used as a replacement character.
Addition 12
... REPLACEMENT CHARACTER c
Effect
The replacement character is used if a particular character cannot be converted when the character set is converted. If you do not use this addition, '#' is used as a replacement character.
This addition can only be used in conjunction with addition 11.
Addition 13
... IN CHAR-TO-HEX MODE
Effect
All character-type fields are not converted. To convert a field, you must create a field (or structure) that is identical to the exported field or structure, except that all its character-type components must be replaced with hexadecimal fields.
You can only use this addition in Unicode programs, to allow you to import camouflaged binary data as single-byte characters. Moreover, you cannot use this addition in conjunction with the additions 8, 9, 10, 11, and 12.
Addition 14
... CODE PAGE INTO f1
Effect
The code page of the exported data is stored in the character-type field f1 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition.
Addition 15
... ENDIAN INTO f2
Effect
The byte order(LITTLE or BIG) of the exported data is stored in the field f2 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition. The field f2 must have the type ABAP_ENDIAN, which is defined in the type group ABAP. For this reason, the type group ABAP must be included in the ABAP program using a TYPE-POOLS statement.
Variant 7
IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.
This variant is not allowed in an ABAP Objects context. See Cannot Use Clusters in Files
Note
This variant is no longer supported and cannot be used.
Variant 8
IMPORT obj1 ... objn FROM LOGFILE ID key.
Note
This statement is for internal use only.
Incompatible changes or further developments may occur at any time without warning or notice.
Extras:
1. ... = f (for each field f to be imported) 2. ... TO f (for each field f to be imported)
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Implicit Field Names in Clusters
Effect
Imports data objects (fields, field strings or internal tables) from the update data. You must specify the update key assigned by the system (with current request number) as the key.
The key, key, must be a character-type data object (but not a string).
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported. An incorrect ID may have been used.
The contents of all objects remain unchanged.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in field f.
Variant 9
IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.
Extras:
1. ... CLIENT g (after dbtab(ar)) 2. ... TO wa (last addition or after dbtab(ar))
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Table Work Areas.
Effect
Imports an object directory stored under the specified ID with EXPORT TO DATABASE into the table itab. The internal table itab may not have the type HASHED TABLE or ANY TABLE.
The key, key, must be a character-type data object (but not a string).
The Return Code is set as follows:
SY-SUBRC = 0:
The directory was successfully imported.
SY-SUBRC = 4:
The directory could not be imported, probably because an incorrect ID was used.
The internal table itab must have the same structure as the Dictionary structure CDIR (INCLUDE STRUCTURE).
Addition 1
... CLIENT g (before ID key)
Effect
Takes data from the client g (only with client-specific import/export databases). Client g must be a character-type data object (but not a string).
Addition 2
... TO wa (last addition or after dbtab(ar))
Effect
Uses the work area wa instead of the table work area. When you use this addition, you do not need to declare the table dbtab, named after DATABASE using a TABLES statement. The work area entered must have the same structure as the table dbtab.
Example
Directory of a cluster consisting of two fields and an internal table:
TYPES: BEGIN OF TAB3_LINE,
CONT(4),
END OF TAB3_LINE,
BEGIN OF DIRTAB_LINE.
INCLUDE STRUCTURE CDIR.
TYPES END OF DIRTAB_LINE.
DATA: INDXKEY LIKE INDX-SRTFD,
F1(4),
F2(8) TYPE P decimals 0,
TAB3 TYPE STANDARD TABLE OF TAB3_LINE,
DIRTAB TYPE STANDARD TABLE OF DIRTAB_LINE,
INDX_WA TYPE INDX.
INDXKEY = 'INDXKEY'.
EXPORT F1 = F1
F2 = F2
TAB3 = TAB3
TO DATABASE INDX(ST) ID INDXKEY " TAB3 has 17 entries
FROM INDX_WA.
IMPORT DIRECTORY INTO DIRTAB FROM DATABASE INDX(ST) ID INDXKEY
TO INDX_WA.
Then, the table DIRTAB contains the following:
NAME OTYPE FTYPE TFILL FLENG
F1 F C 0 4
F2 F P 0 8
TAB3 T C 17 4
The meaning of the individual fields is as follows:
NAME:
Name of stored object
OTYPE:
Object type (F: Field, R: Field string / Dictionary struc -
Report in which collect statement .
report in which collect statement is used and also its purpose.
COLLECT
Basic form
COLLECT [wa INTO] itab.
Addition
... SORTED BY f
Effect
COLLECT is used to create unique or compressed datsets. The key fields are the default key fields of the internal table itab .
If you use only COLLECT to fill an internal table, COLLECT makes sure that the internal table does not contain two entries with the same default key fields.
If, besides its default key fields, the internal table contains number fields (see also ABAP/4 number types ), the contents of these number fields are added together if the internal table already contains an entry with the same key fields.
If the default key of an internal table processed with COLLECT is blank, all the values are added up in the first table line.
If you specify wa INTO , the entry to be processed is taken from the explicitly specified work area wa . If not, it comes from the header line of the internal table itab .
After COLLECT , the system field SY-TABIX contains the index of the - existing or new - table entry with default key fields which match those of the entry to be processed.
Notes
COLLECT can create unique or compressed datasets and should be used precisely for this purpose. If uniqueness or compression are unimportant, or two values with identical default key field values could not possibly occur in your particular task, you should use APPEND instead. However, for a unique or compressed dataset which is also efficient, COLLECT is the statement to use.
If you process a table with COLLECT , you should also use COLLECT to fill it. Only by doing this can you guarantee that
the internal table will actually be unique or compressed, as described above and
COLLECT will run very efficiently.
If you use COLLECT with an explicitly specified work area, it must be compatible with the line type of the internal table.
Example
Compressed sales figures for each company
DATA: BEGIN OF COMPANIES OCCURS 10,
NAME(20),
SALES TYPE I,
END OF COMPANIES.
COMPANIES-NAME = 'Duck'. COMPANIES-SALES = 10.
COLLECT COMPANIES.
COMPANIES-NAME = 'Tiger'. COMPANIES-SALES = 20.
COLLECT COMPANIES.
COMPANIES-NAME = 'Duck'. COMPANIES-SALES = 30.
COLLECT COMPANIES.
The table COMPANIES now has the following appearance:
NAME SALES
Duck 40
Tiger 20
Addition
... SORTED BY f
Effect
COLLECT ... SORTED BY f is obsolete and should no longer be used. Use APPEND ... SORTED BY f which has the same meaning.
Note
Performance
The cost of a COLLECT in terms of performance increases with the width of the default key needed in the search for table entries and the number of numeric fields with values which have to be added up, if an entry is found in the internal table to match the default key fields.
If no such entry is found, the cost is reduced to that required to append a new entry to the end of the table.
A COLLECT statement used on a table which is 100 bytes wide and has a key which is 60 bytes wide and seven numeric fields is about approx. 50 msn (standardized microseconds).
Note
Runtime errors
COLLECT_OVERFLOW : Overflow in integer field when calculating totals.
COLLECT_OVERFLOW_TYPE_P : Overflow in type P field when calculating totals. -
HI SDN,
I am bringing the data into internal table like this
TYPES: BEGIN OF ty_EKAB,
i_CONTRACT LIKE /BIC/AZPUR_OAP00-CONTRACT,
i_CONT_ITEM LIKE /BIC/AZPUR_OAP00-CONT_ITEM,
i_ZNET_VAL LIKE /BIC/AZPUR_OAP00-/BIC/ZNET_VAL,
i_ZORDR_QTY LIKE /BIC/AZPUR_OAP00-/BIC/ZORDR_QTY,
END OF ty_EKAB.
DATA: IT_EKAB TYPE SORTED TABLE OF ty_EKAB
WITH NON-UNIQUE KEY i_CONTRACT i_CONT_ITEM ,
WA_EKAB TYPE ty_EKAB.
SELECT CONTRACT CONT_ITEM /BIC/ZNET_VAL /BIC/ZORDR_QTY INTO
TABLE IT_EKAB FROM /BIC/AZPUR_OAP00.
and Data looks like this
4600000000 00040 54,635.00 1.000
4600000000 00040 40,365.00 1.000
4600000002 00010 0.00 0.000
4600000002 00010 91,200.00 1.000
4600000002 00010 31,554.00 1.000
My question : Is there any statement on Internal table which aggregate the values with same CONTRACT CONT_ITEM .
Thankssome ways to perform
- Loop at the internal table and use [COLLECT|https://www.sdn.sap.com/irj/scn/advancedsearch?query=collect&cat=sdn_all] statement into another table of same structure (also look help.sap.com at [Appending Summarized Lines|http://help.sap.com/erp2005_ehp_03/helpdata/EN/fc/eb36d5358411d1829f0000e829fbfe/frameset.htm])
- Sort the internal table and APPEND to another table using [SUM in a AT END OF|https://www.sdn.sap.com/irj/scn/advancedsearch?cat=sdn_all&query=sumATEND+OF&adv=false&sortby=cm_rnd_rankvalue] block (also look help.sap.com at [Processing Table Entries in Loops|http://help.sap.com/erp2005_ehp_03/helpdata/EN/fc/eb381a358411d1829f0000e829fbfe/frameset.htm])
- use a GROUP BY clause in your [SELECT INTO TABLE|https://www.sdn.sap.com/irj/scn/advancedsearch?cat=sdn_all&query=selectINTOTABLEGROUPBY&adv=false&sortby=cm_rnd_rankvalue] (also look help.sap.com at [Reading Data|http://help.sap.com/erp2005_ehp_03/helpdata/EN/fc/eb3983358411d1829f0000e829fbfe/frameset.htm])
Regards -
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 ..
ThnksStandard 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 -
Hi,
I am a beginer. I know how to create a structure and how to create an internal table using ABAP/4. My problem is, i don't understand where to use internal table and structure, also i find myself very confused about the explicit work areas.
Plese someone show me a program by explaining all of this clearly.Hi
Internal tables are the core of ABAP. They are like soul of a body. For any program we use
internal tables extensively. We can use Internal tables like normal data base tables only, but the
basic difference is the memory allocated for internal tables is temporary. Once the program is
closed the memory allocated for internal tables will also be out of memory.
But while using the internal tables, there are many performance issues to be considered. i.e which
type of internal table to be used for the program..like standard internal table, hashed internal
table or sorted internal table etc..
Internal tables
Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by
line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data
objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables
whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for
storing and formatting data from a database table within a program. They are also a good way of including very complicated data
structures in an ABAP program.
Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract
description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The
data type is also an attribute of an existing data object.
Internal Tables as Data Types
Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type,
key, and table type.
Line type
The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the
structure is a column in the internal table. However, the line type may also be elementary or another internal table.
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.
If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves
internal tables. 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.
The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. 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.
Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In
this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access
records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table.
The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled
very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the
table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system
uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether
the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of
table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique.
When you define the table, you must specify the key as UNIQUE.
Generic Internal Tables
Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a
generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic
internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data
objects.
Internal Tables as Dynamic Data Objects
Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in
respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects,
since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are
the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration)
is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more
than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The
individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the
internal table.
Choosing a Table Type
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most
frequently executed.
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.
Creating Internal Tables
Like other elements in the ABAP type concept, you can declare internal tables as abstract data
types in programs or in the ABAP Dictionary, and then use them to define data objects.
Alternatively, you can define them directly as data objects. When you create an internal table as a
data object, you should ensure that only the administration entry which belongs to an internal
table is declared statically. The minimum size of an internal table is 256 bytes. This is important if an
internal table occurs as a component of an aggregated data object, since even empty internal
tables within tables can lead to high memory usage. (In the next functional release, the size of the
table header for an initial table will be reduced to 8 bytes). Unlike all other ABAP data objects, you
do not have to specify the memory required for an internal table. Table rows are added to and
deleted from the table dynamically at runtime by the various statements for adding and deleting
records.
You can create internal tables in different types.
You can create standard internal table and then make it sort in side the program.
The same way you can change to hashed internal tables also.
There will be some performance issues with regard to standard internal tables/ hashed internal
tables/ sorted internal tables.
Internal table types
This section describes how to define internal tables locally in a program. You can also define internal tables globally as data types in the
ABAP Dictionary.
Like all local data types in programs , you define internal tables using the TYPES statement. If you do not refer to an existing table type
using the TYPE or LIKE addition, you can use the TYPES statement to construct a new local internal table in your program.
TYPES <t> TYPE|LIKE <tabkind> OF <linetype> [WITH <key>]
[INITIAL SIZE <n>].
After TYPE or LIKE, there is no reference to an existing data type. Instead, the type constructor occurs:
<tabkind> OF <linetype> [WITH <key>]
The type constructor defines the table type <tabkind>, the line type <linetype>, and the key <key> of the internal table <t>.
You can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
Table type
You can specify the table type <tabkind> as follows:
Generic table types
INDEX TABLE
For creating a generic table type with index access.
ANY TABLE
For creating a fully-generic table type.
Data types defined using generic types can currently only be used for field symbols and for interface parameters in procedures . The generic
type INDEX TABLE includes standard tables and sorted tables. These are the two table types for which index access is allowed. You cannot
pass hashed tables to field symbols or interface parameters defined in this way. The generic type ANY TABLE can represent any table. You
can pass tables of all three types to field symbols and interface parameters defined in this way. However, these field symbols and
parameters will then only allow operations that are possible for all tables, that is, index operations are not allowed.
Fully-Specified Table Types
STANDARD TABLE or TABLE
For creating standard tables.
SORTED TABLE
For creating sorted tables.
HASHED TABLE
For creating hashed tables.
Fully-specified table types determine how the system will access the entries in the table in key operations. It uses a linear search for
standard tables, a binary search for sorted tables, and a search using a hash algorithm for hashed tables.
Line type
For the line type <linetype>, you can specify:
Any data type if you are using the TYPE addition. This can be a predefined ABAP type, a local type in the program, or a data type from the
ABAP Dictionary. If you specify any of the generic elementary types C, N, P, or X, any attributes that you fail to specify (field length, number
of decimal places) are automatically filled with the default values. You cannot specify any other generic types.
Any data object recognized within the program at that point if you are using the LIKE addition. The line type adopts the fully-specified data
type of the data object to which you refer. Except for within classes, you can still use the LIKE addition to refer to database tables and
structures in the ABAP Dictionary (for compatibility reasons).
All of the lines in the internal table have the fully-specified technical attributes of the specified data type.
Key
You can specify the key <key> of an internal table as follows:
[UNIQUE|NON-UNIQUE] KEY <col1> ... <col n>
In tables with a structured line type, all of the components <coli> belong to the key as long as they are not internal tables or references,
and do not contain internal tables or references. Key fields can be nested structures. The substructures are expanded component by
component when you access the table using the key. The system follows the sequence of the key fields.
[UNIQUE|NON-UNIQUE] KEY TABLE LINE
If a table has an elementary line type (C, D, F, I, N, P, T, X), you can define the entire line as the key. If you try this for a table whose line
type is itself a table, a syntax error occurs. If a table has a structured line type, it is possible to specify the entire line as the key. However,
you should remember that this is often not suitable.
[UNIQUE|NON-UNIQUE] DEFAULT KEY
This declares the fields of the default key as the key fields. If the table has a structured line type, the default key contains all non-numeric
columns of the internal table that are not and do not contain references or internal tables. If the 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.
Specifying a key is optional. If you do not specify a key, the system defines a table type with an arbitrary key. You can only use this to
define the types of field symbols and the interface parameters of procedures . For exceptions, refer to Special Features of Standard Tables.
The optional additions UNIQUE or NON-UNIQUE determine whether the key is to be unique or non-unique, that is, whether the table can
accept duplicate entries. If you do not specify UNIQUE or NON-UNIQUE for the key, the table type is generic in this respect. As such, it can
only be used for specifying types. When you specify the table type simultaneously, you must note the following restrictions:
You cannot use the UNIQUE addition for standard tables. The system always generates the NON-UNIQUE addition automatically.
You must always specify the UNIQUE option when you create a hashed table.
Initial Memory Requirement
You can specify the initial amount of main memory assigned to an internal table object when you define the data type using the following
addition:
INITIAL SIZE <n>
This size does not belong to the data type of the internal table, and does not affect the type check. You can use the above addition to
reserve memory space for <n> table lines when you declare the table object.
When this initial area is full, the system makes twice as much extra space available up to a limit of 8KB. Further memory areas of 12KB each
are then allocated.
You can usually leave it to the system to work out the initial memory requirement. The first time you fill the table, little memory is used. The
space occupied, depending on the line width, is 16 <= <n> <= 100.
It only makes sense to specify a concrete value of <n> if you can specify a precise number of table entries when you create the table and
need to allocate exactly that amount of memory (exception: Appending table lines to ranked lists). This can be particularly important for
deep-structured internal tables where the inner table only has a few entries (less than 5, for example).
To avoid excessive requests for memory, large values of <n> are treated as follows: The largest possible value of <n> is 8KB divided by the
length of the line. If you specify a larger value of <n>, the system calculates a new value so that n times the line width is around 12KB.
Examples
TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.
TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
The program defines a table type ITAB. It is a sorted table, with line type of the structure LINE and a unique key of the component
COLUMN1.
TYPES VECTOR TYPE HASHED TABLE OF I WITH UNIQUE KEY TABLE LINE.
TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.
TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
TYPES: BEGIN OF DEEPLINE,
FIELD TYPE C,
TABLE1 TYPE VECTOR,
TABLE2 TYPE ITAB,
END OF DEEPLINE.
TYPES DEEPTABLE TYPE STANDARD TABLE OF DEEPLINE
WITH DEFAULT KEY.
The program defines a table type VECTOR with type hashed table, the elementary line type I and a unique key of the entire table line. The
second table type is the same as in the previous example. The structure DEEPLINE contains the internal table as a component. The table
type DEEPTABLE has the line type DEEPLINE. Therefore, the elements of this internal table are themselves internal tables. The key is the
default key - in this case the column FIELD. The key is non-unique, since the table is a standard table.
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.
Declaring New Internal Tables
You can use the DATA statement to construct new internal tables as well as using the LIKE or TYPE addition to refer to existing types or
objects. The table type that you construct does not exist in its own right; instead, it is only an attribute of the table object. You can refer to
it using the LIKE addition, but not using TYPE. The syntax for constructing a table object in the DATA statement is similar to that for defining
a table type in the TYPES statement.
DATA <itab> TYPE|LIKE <tabkind> OF <linetype> WITH <key>
[INITIAL SIZE <n>]
[WITH HEADER LINE].
As when you define a table type , the type constructor
<tabkind> OF <linetype> WITH <key>
defines the table type <tabkind>, the line type <linekind>, and the key <key> of the internal table <itab>. Since the technical attributes of
data objects are always fully specified, the table must be fully specified in the DATA statement. You cannot create generic table types (ANY
TABLE, INDEX TABLE), only fully-typed tables (STANDARD TABLE, SORTED TABLE, HASHED TABLE). You must also specify the key and whether
it is to be unique (for exceptions, refer to Special Features of Standard Tables).
As in the TYPES statement, you can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
You can create an internal table with a header line using the WITH HEADER LINE addition. The header line is created under the same
conditions as apply when you refer to an existing table type.
DATA ITAB TYPE HASHED TABLE OF SPFLI
WITH UNIQUE KEY CARRID CONNID.
The table object ITAB has the type hashed table, a line type corresponding to the flat structure SPFLI from the ABAP Dictionary, and a
unique key with the key fields CARRID and CONNID. The internal table ITAB can be regarded as an internal template for the database table
SPFLI. It is therefore particularly suitable for working with data from this database table as long as you only access it using the key.
Maybe you are looking for
-
Facebook and Email wont connect on C3
I recently bought a Nokia c3. I can connect to all the internet services ie opera browser, facebook, email, msn messenger via WLAN. When I want to connect through o2 Wap, I can only access the Opera browser. None of the other services like facebook o
-
How can i change my apple ID account to and MobileMe Account and will i lose all my purchases ?
how can i change my apple ID account to and MobileMe Account and will i lose all my purchases ?
-
Deferred task date change problem
Hi, Every user in IDM has a deferred task as shown below. The requirement is to change the 'Date' value to set the time as 23:59:59.00Z. At the moment different users have different times set for them. All need to be same as mentioned above. Please a
-
I just updated my iPhone and all my Macs to the new MobileMe, but I am having a problem getting my Notes to sync onto my other macs. I won't get started on how stupid it is for Notes and ToDos not to sync to their corresponding iPhone native apps (ie
-
Currency Decimal issues in BI Explorer
Hi, We have a reporting issue for key figures in multiple currencies when using BI Explorer. We have currencies defined in the system which are in the following 3 models: - Having 2 decimal places (UAE, QATAR...) - Having 3 decimal places (OMAN, BAHR