Internal table sort

Dear All,
I am facing problem in internal sort command.
While executing the program in Fore ground sort happens properly where as in back ground is not which i can absorb in spool.
Table type is Standard.
SORT int_s711_a BY gross_p DESCENDING umsmng DESCENDING.
Both gross_p & umsmng fields are of curr type with length 19.
Thanks and Regards
Joseph

Use.....SORT int_s711_a BY gross_p umsmng DESCENDING
Also, while sorting currency fields sometimes it happens that sort might not be proper. But it will work...If possible try to use some other key field also.
Close duplicate threads by awarding points.

Similar Messages

How to check internal table sorted or not

Hi all
I need to check internal table sorted or not which is without header line and having only one field and six values. please let me know how to check it is sorted or not because i need to display message if it is not sorted.
thanks,
Minal

Hi Minal,
Go through this info.
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.
Stable sort
The option
SORT <itab> ... STABLE.
allows you to perform a stable sort, that is, the relative sequence of lines that are unchanged by the sort is not changed. If you do not use the STABLE option, the sort sequence is not preserved. If you sort a table several times by the same key, the sequence of the table entries will change in each sort. However, a stable sort takes longer than an unstable sort.
Examples
DATA: BEGIN OF LINE,
 LAND(3) TYPE C,
 NAME(10) TYPE C,
 AGE TYPE I,
 WEIGHT TYPE P DECIMALS 2,
 END OF LINE.
DATA ITAB LIKE STANDARD TABLE OF LINE WITH NON-UNIQUE KEY LAND.
LINE-LAND = 'G'. LINE-NAME = 'Hans'.
LINE-AGE = 20. LINE-WEIGHT = '80.00'.
APPEND LINE TO ITAB.
LINE-LAND = 'USA'. LINE-NAME = 'Nancy'.
LINE-AGE = 35. LINE-WEIGHT = '45.00'.
APPEND LINE TO ITAB.
LINE-LAND = 'USA'. LINE-NAME = 'Howard'.
LINE-AGE = 40. LINE-WEIGHT = '95.00'.
APPEND LINE TO ITAB.
LINE-LAND = 'GB'. LINE-NAME = 'Jenny'.
LINE-AGE = 18. LINE-WEIGHT = '50.00'.
APPEND LINE TO ITAB.
LINE-LAND = 'F'. LINE-NAME = 'Michele'.
LINE-AGE = 30. LINE-WEIGHT = '60.00'.
APPEND LINE TO ITAB.
LINE-LAND = 'G'. LINE-NAME = 'Karl'.
LINE-AGE = 60. LINE-WEIGHT = '75.00'.
APPEND LINE TO ITAB.
PERFORM LOOP_AT_ITAB.
SORT ITAB.
PERFORM LOOP_AT_ITAB.
SORT ITAB.
PERFORM LOOP_AT_ITAB.
SORT ITAB STABLE.
PERFORM LOOP_AT_ITAB.
SORT ITAB DESCENDING BY LAND WEIGHT ASCENDING.
PERFORM LOOP_AT_ITAB.
FORM LOOP_AT_ITAB.
LOOP AT ITAB INTO LINE.
 WRITE: / LINE-LAND, LINE-NAME, LINE-AGE, LINE-WEIGHT.
ENDLOOP.
SKIP.
ENDFORM.
************rewords some points if it is helpful.
Rgds,
P.Naganjana Reddy

Internal Table Sorts following an Upgrade

Hi,
We are in the middle of upgrading our 4.6c system to ECC 5.0, and as part of this have had to do the codepage conversion and upgrade in a test environment. Mostly this seems fine, however, our application support people are running some tests, and are getting different results to Live. This looks to be down to a function called SORT, which is transferring data to an internal table. However, having compared the data at iSeries level in both ASCII and EBCDIC, I can see that the tables are arranged differently i.e. Numbers first, then alphanumeric second.
Does anyone know if it is possible to change the order that SAP reads this data, so that it continues to read it as if it was arranged as per EBCDIC?
Thanks in advance,
Dan

Hi Dan,
I know, that you might have been the first ECC 5.0 customer - but I would STRONGLY recommend, that you upgrade the next systems to ECC 6.0 now - that is an environment with a lot more support ...
PLEASE: Rethink your decision on ECC 5.0 to 6.0 !!!
Now to your topic:
Digits are "bigger" in EBCDIC and lower in ASCII than characters - unfortunately this is always the case in SORT - this is one of the changes of the ASCII CPC - that you cannot change - => if your programs rely on that, you have to change them ;-(
If your users are used to the order, you should "retrain" them ...
Sorry,
Volker Gueldenpfennig, consolut.gmbh
http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Internal Table Sorting: Order alphabetic letters first then Numarics

Hello Guys,
I am guessing this might be very simple.
After sorting my internal table looks like
TS1
TS2
TS3
TSA
TSB
TSC
I want it to be like
TSA
TSB
TBC
TS1
TS2
TS3
Any ideas.
Thank you.
Sharat.

Dear Sharat,
No explicit option in SORT is available for your requirement.
Separate records of Alphabetic letters and Numbers. Sort them individually and move them into final internal table.
Write some code as below
DATA: BEGIN OF itab OCCURS 0,
      str TYPE string,
      END OF itab,
      wa LIKE itab,
      l_len TYPE i,
      itab1 LIKE itab OCCURS 0,
      l_sytabix TYPE sy-tabix.
wa-str = 'TSB'. APPEND wa TO itab.
wa-str = 'TS2'. APPEND wa TO itab.
wa-str = 'TS3'. APPEND wa TO itab.
wa-str = 'TSA'. APPEND wa TO itab.
wa-str = 'TSC'. APPEND wa TO itab.
wa-str = 'TS1'. APPEND wa TO itab.
*Separate records of Alphabetic letters and Numbers
LOOP AT itab INTO wa.   " ITAB contains all records
l_sytabix = sy-tabix.
l_len = STRLEN( wa-str ).
l_len = l_len - 1.
IF wa-str+l_len(1) CA '0123456789'.
    APPEND wa TO itab1.
    DELETE itab INDEX l_sytabix.
ENDIF.
ENDLOOP.
SORT itab.   " Sort records of Alphabetic letters
SORT itab1. " Sort records of Numbers
APPEND LINES OF itab1 TO itab. " After sorting, move into final table

Help with basic ABAP code (merge internal tables, sort of...)

Hello,
Can someone please help write some basic code for a Basis guy with limited ABAP knowledge?
Should be some easy points for an experienced ABAPer!
I have identicaly structured internal tables I_A and I_B and I_C which have already been filled by function models I called.
How will I code the following?:
I want to read all the data of I_A into a new internal table I_MASTER (structured the same as I_A,I_B and I_C).
Then I want to read I_B and:
1)Update I_MASTER with NEW records
2)Update existing records if the value of field MYFIELD in I_B is smaller than the value of MYFIELD in I_MASTER.
Then I want to read I_C and:
1)Update I_MASTER with NEW records
2)Update existing records if the value of field MYFIELD in I_C is smaller than the value of MYFIELD in I_MASTER.
Let me know if I can provide anymore information.
Thanks in advance for you help!
Adriaan
Message was edited by: Adriaan
Message was edited by: Adriaan

Hi Adriaan ,
I want to read all the data of I_A into a new internal table I_MASTER (structured the same as I_A,I_B and I_C).
i_master[] = i_a[] .
loop at i_b .
read table i_master with key myfiled < i_b-myfield .
if sy-subrc = 0 .
append i_master from i_b .
endif.
endloop.
loop at i_c .
read table i_master with key myfiled < i_c-myfield .
if sy-subrc = 0 .
append i_master from i_c .
endif.
endloop.
Let me know if this helped .
Regards,
Varun .
Message was edited by: varun sonu

Loop using index read ( internal table)

Hi,
I thought of impelementing loop at ITAB using read statements, Here it goes.
REPORT Z_LOOP_IMPROVE.
DATA : T_OUTPUT TYPE STANDARD TABLE OF MARC WITH HEADER LINE,
L_TABIX TYPE SY-TABIX.
DEFINE ILOOP.
DO.
IF SY-INDEX EQ '1'.
READ TABLE &1 WITH KEY &2 = &3 BINARY SEARCH.
IF SY-SUBRC <> 0.
EXIT.
ENDIF.
ELSE.
L_TABIX = SY-TABIX + 1.
READ TABLE &1 INDEX L_TABIX.
IF SY-SUBRC NE 0 OR &1-&2 NE &3.
EXIT.
ENDIF.
ENDIF.
END-OF-DEFINITION.
DEFINE IENDLOOP.
ENDDO.
END-OF-DEFINITION.
DATA : T1 TYPE I, T2 TYPE I.
SELECT * FROM MARC INTO TABLE T_OUTPUT.
SORT T_OUTPUT BY WERKS.
GET RUN TIME FIELD T1.
ILOOP T_OUTPUT WERKS '0001'.
WRITE : / T_OUTPUT-MATNR, T_OUTPUT-WERKS.
IENDLOOP.
GET RUN TIME FIELD T2.
T2 = T2 - T1.
WRITE : / T2.
*C----
But sadly it takes more time than a normal loop with
where condition.
can anyone suggest some ideas to improve execution speed?

You can use a binary read to get the first record. Then read each record sequentially until you have proccessed all the records that meet your critera. You will have to have the internal table sorted so that the binary search and subsequent reads will work:
 READ TABLE itab WITH KEY
 field = whatever
 BINARY SEARCH.
 IF sy-subrc = 0.
 itab_index = sy-tabix.
 DO.
 IF sy-subrc = 0.
 IF itab_data-field = whatever
 itab_index = itab_index + 1.
 READ TABLE itab_data INDEX itab_index.
 ELSE.
 EXIT.
 ENDIF.
 ELSE.
 EXIT.
 ENDIF.
 ENDDO.
 ENDIF.
Rob

Internal Table Data to XML

Hi
I have a requirement of writing internal table data to XML. Any idea where i should start.
I have pretty good experience with ABAP and basic knowledge in XML.
There are good blogs which talk about transformations and other stuff but they are not able to give me clear path to my solution.
Could somebody give me a basic example or some reference material where i can move the data in internal table (assume Sales order details of a day) to XML.
Thanks

Refer the program -
In this implementation we will only focus on the creation of the XML file and the transfer to the user. You can not create a XML document directly. You have to use a so called ixml factory first.
TYPE-POOLS: ixml.
DATA: l_ixml TYPE REF TO if_ixml.
l_ixml = cl_ixml=>create( ).
This iXML factory can create an empty XML document object named l_document.
DATA: l_document TYPE REF TO if_ixml_document.
 l_document = l_ixml->create_document( ).
At this point you can add the nodes (elements, attributes) into the document. First you have to declare the root element node.
DATA: l_element_root TYPE REF TO if_ixml_element.
This node we have to give a name and add it (create_simple_node) to the document object l_document, which will be the parent of this node.
l_element_root = l_document->create_simple_element(
 name = 'flights'
 parent = l_document ).
Next we can add child nodes to there parent node using the same method of the document object.
DATA: l_element_airline TYPE REF TO if_ixml_element,
l_element_airline = l_document->create_simple_element(
 name = 'airline'
 parent = l_element_root ).
An attribute can be add easily using the method set_attribute of the element node.
l_rc = l_element_airline->set_attribute( name = 'code' value = 'LH401' ).
Now we have finished the document object. Regretfully it can not be displayed in any form due to the fact that it is a binary object.
The next step is to convert the created document to a flat file. To achieve this we have to create a stream factory, which will help us to create an output stream.
DATA: l_streamfactory TYPE REF TO if_ixml_stream_factory.
l_streamfactory = l_ixml->create_stream_factory( ).
In this case, we will convert the document into an output stream which is based on an internal table of type x.
TYPES: BEGIN OF xml_line,
 data(256) TYPE x,
 END OF xml_line.
DATA: l_xml_table TYPE TABLE OF xml_line,
 l_xml_size TYPE i,
 l_rc TYPE i,
 l_ostream TYPE REF TO if_ixml_ostream.
l_ostream = l_streamfactory->create_ostream_itable( table = l_xml_table ).
When we have created the output stream we can do the rendering from the document into the stream. The XML data will be stored in the internal table automatically.
DATA: l_renderer TYPE REF TO if_ixml_renderer.
l_renderer = l_ixml->create_renderer( ostream = l_ostream
 & nbsp; document = l_document ).
l_rc = l_renderer->render( ).
In the last step we upload the file to the sapgui
l_xml_size = l_ostream->get_num_written_raw( ).
CALL METHOD cl_gui_frontend_services=>gui_download
 EXPORTING
 bin_filesize = l_xml_size
 filename = 'c:\temp\flights.xml'
 filetype = 'BIN'
 CHANGING
 data_tab = l_xml_table
 EXCEPTIONS
 OTHERS = 24.
This finished the first step-of-three. As mentioned before the next log will focus on the conversion from xml files (back) to abap tables.
REPORT z_xit_xml_dom_create.
TYPE-POOLS: ixml.
TYPES: BEGIN OF xml_line,
 data(256) TYPE x,
 END OF xml_line.
DATA: l_ixml TYPE REF TO if_ixml,
 l_streamfactory TYPE REF TO if_ixml_stream_factory,
 l_ostream TYPE REF TO if_ixml_ostream,
 l_renderer TYPE REF TO if_ixml_renderer,
 l_document TYPE REF TO if_ixml_document.
DATA: l_element_flights TYPE REF TO if_ixml_element,
 l_element_airline TYPE REF TO if_ixml_element,
 l_element_flight TYPE REF TO if_ixml_element,
 l_element_from TYPE REF TO if_ixml_element,
 l_element_to TYPE REF TO if_ixml_element,
 l_element_dummy TYPE REF TO if_ixml_element,
 l_value TYPE string.
DATA: l_xml_table TYPE TABLE OF xml_line,
 l_xml_size TYPE i,
 l_rc TYPE i.
DATA: lt_spfli TYPE TABLE OF spfli.
DATA: l_spfli TYPE spfli.
START-OF-SELECTION.
Fill the internal table
 SELECT * FROM spfli INTO TABLE lt_spfli.
Sort internal table
 SORT lt_spfli BY carrid.
Start filling xml dom object from internal table
 LOOP AT lt_spfli INTO l_spfli.
 AT FIRST.
 Creating a ixml factory
 l_ixml = cl_ixml=>create( ).
 Creating the dom object model
 l_document = l_ixml->create_document( ).
 Fill root node with value flights
 l_element_flights = l_document->create_simple_element(
 name = 'flights'
 parent = l_document ).
 ENDAT.
 AT NEW carrid.
 Create element 'airline' as child of 'flights'
 l_element_airline = l_document->create_simple_element(
 name = 'airline'
 parent = l_element_flights ).
 Create attribute 'code' of node 'airline'
 l_value = l_spfli-carrid.
 l_rc = l_element_airline->set_attribute( name = 'code' value = l_value ).
 Create attribute 'name' of node 'airline'
 SELECT SINGLE carrname FROM scarr INTO l_value WHERE carrid EQ l_spfli-carrid.
 l_rc = l_element_airline->set_attribute( name = 'name' value = l_value ).
 ENDAT.
 AT NEW connid.
 Create element 'flight' as child of 'airline'
 l_element_flight = l_document->create_simple_element(
 name = 'flight'
 parent = l_element_airline ).
 Create attribute 'number' of node 'flight'
 l_value = l_spfli-connid.
 l_rc = l_element_flight->set_attribute( name = 'number' value = l_value ).
 ENDAT.
 Create element 'from' as child of 'flight'
 CONCATENATE l_spfli-cityfrom ',' l_spfli-countryfr INTO l_value.
 l_element_from = l_document->create_simple_element(
 name = 'from'
 value = l_value
 parent = l_element_flight ).
 Create attribute 'airport' of node 'from'
 l_value = l_spfli-airpfrom.
 l_rc = l_element_from->set_attribute( name = 'airport' value = l_value ).
 Create element 'to' as child of 'flight'
 CONCATENATE l_spfli-cityto ',' l_spfli-countryto INTO l_value.
 l_element_to = l_document->create_simple_element(
 name = 'to'
 value = l_value
 parent = l_element_flight ).
 Create attribute 'airport' of node 'from'
 l_value = l_spfli-airpto.
 l_rc = l_element_to->set_attribute( name = 'airport' value = l_value ).
 Create element 'departure' as child of 'flight'
 l_value = l_spfli-deptime.
 l_element_dummy = l_document->create_simple_element(
 name = 'departure'
 value = l_value
 parent = l_element_flight ).
 Create element 'arrival' as child of 'flight'
 l_value = l_spfli-arrtime.
 l_element_dummy = l_document->create_simple_element(
 name = 'arrival'
 value = l_value
 parent = l_element_flight ).
 Create element 'type' as child of 'flight'
 CASE l_spfli-fltype.
 WHEN 'X'.
 l_value = 'Charter'.
 WHEN OTHERS.
 l_value = 'Scheduled'.
 ENDCASE.
 l_element_dummy = l_document->create_simple_element(
 name = 'type'
 value = l_value
 parent = l_element_flight ).
 ENDLOOP.
 IF sy-subrc NE 0.
 MESSAGE 'No data into db table ''spfli'', please run program ''SAPBC_DATA_GENERATOR'' with transaction ''SA38''' TYPE 'E'.
 ENDIF.
Creating a stream factory
 l_streamfactory = l_ixml->create_stream_factory( ).
Connect internal XML table to stream factory
 l_ostream = l_streamfactory->create_ostream_itable( table = l_xml_table ).
Rendering the document
 l_renderer = l_ixml->create_renderer( ostream = l_ostream
 document = l_document ).
 l_rc = l_renderer->render( ).
Saving the XML document
 l_xml_size = l_ostream->get_num_written_raw( ).
 CALL METHOD cl_gui_frontend_services=>gui_download
 EXPORTING
 bin_filesize = l_xml_size
 filename = 'c:\temp\flights.xml'
 filetype = 'BIN'
 CHANGING
 data_tab = l_xml_table
 EXCEPTIONS
 OTHERS = 24.
 IF sy-subrc <> 0.
 MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
 WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
 ENDIF.
<?xml version="1.0"?>
<flights>
 <airline code="AA" name="American Airlines">
 <flight number="0017">
 <from airport="JFK">NEW YORK,US</from>
 <to airport="SFO">SAN FRANCISCO,US</to>
 <departure>110000</departure>
 <arrival>140100</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0064">
 <from airport="SFO">SAN FRANCISCO,US</from>
 <to airport="JFK">NEW YORK,US</to>
 <departure>090000</departure>
 <arrival>172100</arrival>
 <type>Scheduled</type>
 </flight>
 </airline>
 <airline code="AZ" name="Alitalia">
 <flight number="0555">
 <from airport="FCO">ROME,IT</from>
 <to airport="FRA">FRANKFURT,DE</to>
 <departure>190000</departure>
 <arrival>210500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0788">
 <from airport="FCO">ROME,IT</from>
 <to airport="TYO">TOKYO,JP</to>
 <departure>120000</departure>
 <arrival>085500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0789">
 <from airport="TYO">TOKYO,JP</from>
 <to airport="FCO">ROME,IT</to>
 <departure>114500</departure>
 <arrival>192500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0790">
 <from airport="FCO">ROME,IT</from>
 <to airport="KIX">OSAKA,JP</to>
 <departure>103500</departure>
 <arrival>081000</arrival>
 <type>Charter</type>
 </flight>
 </airline>
 <airline code="DL" name="Delta Airlines">
 <flight number="1984">
 <from airport="SFO">SAN FRANCISCO,US</from>
 <to airport="JFK">NEW YORK,US</to>
 <departure>100000</departure>
 <arrival>182500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="1699">
 <from airport="JFK">NEW YORK,US</from>
 <to airport="SFO">SAN FRANCISCO,US</to>
 <departure>171500</departure>
 <arrival>203700</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0106">
 <from airport="JFK">NEW YORK,US</from>
 <to airport="FRA">FRANKFURT,DE</to>
 <departure>193500</departure>
 <arrival>093000</arrival>
 <type>Scheduled</type>
 </flight>
 </airline>
 <airline code="JL" name="Japan Airlines">
 <flight number="0407">
 <from airport="NRT">TOKYO,JP</from>
 <to airport="FRA">FRANKFURT,DE</to>
 <departure>133000</departure>
 <arrival>173500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0408">
 <from airport="FRA">FRANKFURT,DE</from>
 <to airport="NRT">TOKYO,JP</to>
 <departure>202500</departure>
 <arrival>154000</arrival>
 <type>Charter</type>
 </flight>
 </airline>
 <airline code="LH" name="Lufthansa">
 <flight number="2407">
 <from airport="TXL">BERLIN,DE</from>
 <to airport="FRA">FRANKFURT,DE</to>
 <departure>071000</departure>
 <arrival>081500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="2402">
 <from airport="FRA">FRANKFURT,DE</from>
 <to airport="SXF">BERLIN,DE</to>
 <departure>103000</departure>
 <arrival>113500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0402">
 <from airport="FRA">FRANKFURT,DE</from>
 <to airport="JFK">NEW YORK,US</to>
 <departure>133000</departure>
 <arrival>150500</arrival>
 <type>Charter</type>
 </flight>
 <flight number="0401">
 <from airport="JFK">NEW YORK,US</from>
 <to airport="FRA">FRANKFURT,DE</to>
 <departure>183000</departure>
 <arrival>074500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0400">
 <from airport="FRA">FRANKFURT,DE</from>
 <to airport="JFK">NEW YORK,US</to>
 <departure>101000</departure>
 <arrival>113400</arrival>
 <type>Scheduled</type>
 </flight>
 </airline>
 <airline code="QF" name="Qantas Airways">
 <flight number="0005">
 <from airport="SIN">SINGAPORE,SG</from>
 <to airport="FRA">FRANKFURT,DE</to>
 <departure>225000</departure>
 <arrival>053500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0006">
 <from airport="FRA">FRANKFURT,DE</from>
 <to airport="SIN">SINGAPORE,SG</to>
 <departure>205500</departure>
 <arrival>150500</arrival>
 <type>Scheduled</type>
 </flight>
 </airline>
 <airline code="SQ" name="Singapore Airlines">
 <flight number="0988">
 <from airport="SIN">SINGAPORE,SG</from>
 <to airport="TYO">TOKYO,JP</to>
 <departure>163500</departure>
 <arrival>001500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0158">
 <from airport="SIN">SINGAPORE,SG</from>
 <to airport="JKT">JAKARTA,ID</to>
 <departure>152500</departure>
 <arrival>160000</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0015">
 <from airport="SFO">SAN FRANCISCO,US</from>
 <to airport="SIN">SINGAPORE,SG</to>
 <departure>160000</departure>
 <arrival>024500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="0002">
 <from airport="SIN">SINGAPORE,SG</from>
 <to airport="SFO">SAN FRANCISCO,US</to>
 <departure>170000</departure>
 <arrival>192500</arrival>
 <type>Scheduled</type>
 </flight>
 </airline>
 <airline code="UA" name="United Airlines">
 <flight number="0941">
 <from airport="FRA">FRANKFURT,DE</from>
 <to airport="SFO">SAN FRANCISCO,US</to>
 <departure>143000</departure>
 <arrival>170600</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="3504">
 <from airport="SFO">SAN FRANCISCO,US</from>
 <to airport="FRA">FRANKFURT,DE</to>
 <departure>150000</departure>
 <arrival>103000</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="3516">
 <from airport="JFK">NEW YORK,US</from>
 <to airport="FRA">FRANKFURT,DE</to>
 <departure>162000</departure>
 <arrival>054500</arrival>
 <type>Scheduled</type>
 </flight>
 <flight number="3517">
 <from airport="FRA">FRANKFURT,DE</from>
 <to airport="JFK">NEW YORK,US</to>
 <departure>104000</departure>
 <arrival>125500</arrival>
 <type>Scheduled</type>
 </flight>
 </airline>
</flights>
Regards,
Amit
Reward all helpful replies.

Internal Table ! Accessing Issue!

Hello Guys!
 Internal table
 Sorted, Hashed, Standard
For accesing itab uses,
 Standard---> uses Linear Search
 Sorted ---> Binary Search
 Hashed-----> Hash Algorithm
 Can u pls tell me what is linear search, binary search, hash algorithm?
 And also,
 Why we mostly go for standard table?
PLs give ur suggestions,
Thanks for your answers
<REMOVED BY MODERATOR>
 Thanks
 Rahul.
Message was edited by:
 Alvaro Tejada Galindo

TABKIND - Internal Table Types
Alternatives:
1. STANDARD TABLE
2. SORTED TABLE
3. HASHED TABLE
4. INDEX TABLE
5. ANY TABLE
Effect
The table type - set in the DATA, TYPES, orCREATE DATA statement, specifies how the system accesses entries in the internal table in generic key operations.
(READ TABLE itab, DELETE TABLE itab, INSERT TABLE itab, MODIFY TABLE itab, COLLECT itab). As a general rule, the runtime required for key operations depends on the total length of the key.
The various table types have the following hierarchy:
 ANY TABLE
 |
 | |
 INDEX TABLE HASHED TABLE
 |
 | |
 STANDARD TABLE SORTED TABLE
Alternative 1
STANDARD TABLE
Effect
Defines the table as a standard table. Key access to a standard table uses a linear search. This means that the timne required for a search is in linear relation to the number of table entries.
You should use index operations to access standard tables.
For the sake of compatibility, you can use TABLE as a synonym of STANDARD TABLE.
Alternative 2
SORTED TABLE
Effect
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.
You can also access sorted tables by index operations. When you insert using an index, the system checks to ensure that the sort sequence has been correctly maintained. For this reason, it takes longer than inserting entries in a standard table. As a rule, you should only access sorted tables using their key.
Alternative 3
HASHED TABLE
Effect
Defines the table as one that is managed with an internal hash procedure. You can imagine a hashed table as a set, whose elements you can address using their unique key. Unlike standard and sorted tables, you cannot access hash tables using an index. All entries in the table must have a unique key. Access time using the key is constant, regardless of the number of table entries.
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.
Alternative 4
INDEX TABLE
Effect
Standard and sorted tables belong to the generic class index tables. An index table is one that you can access using an index. You can currently only use the table type INDEX TABLE to specify the type of generic parameters in a FORM or a FUNCTION. Hashed tables are not index tables, and cannot therefore be passed to parameters defined as INDEX TABLE.
Alternative 5
ANY TABLE
Effect
Like INDEX TABLE, you use ANY TABLE to specify the type of any generic table parameter. The set of permitted operations for a table with type ANY TABLE consists of the intersection of all permitted operations for STANDARD, SORTED and HASHED TABLEs, and so is identical to the set of operations permitted for hashed tables.
Note in particular that you cannot use index access for tables with this type.

Types of internal tables with regard to EFFICIENCY

Will any one tell me syntax to define each type of internal table (standard, sorted , hashed , database) . how to compare their efficincy ( access time which is more effficent) is there any documantation or programme of such type exist then please tell . i want to declare each type of above table and also to compare them w.r.t to efficeny thanks want urgent reply

Hi,
There are 3 types of Internal tables.
Standard Internal Tables:
Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.
This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to the number of table entries.
Sorted Internal Tables:
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship 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, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.
Hashed Internal Tables:
Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.
This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.
http://help.sap.com/saphelp_470/helpdata/EN/fc/eb35de358411d1829f0000e829fbfe/frameset.htm
Regards,
Kiran Sure

Error in uploading excel sheet data into internal table

Dear all,
i am facing problem when uploading data from excel. i used KD_GET_FILENAME_ON_F4.i select the file and pass on to ALSM_EXCEL_INTO_INTERNAL_TABLE.and i get the ERROR....
Illegal type when transferring an internal table to a FORM. this is my code .
types : begin of ty_mm01,
 matnr like rmmg1-matnr,
 mbrsh like rmmg1-mbrsh,
 mtart like rmmg1-mtart,
 maktx like makt-maktx,
 meins like mara-meins,
 matkl like mara-matkl,
 bismt like mara-bismt,
 spart like mara-spart,
 mtpos like mara-mtpos_mara,
 end of ty_mm01.
data : tt_mm01 type standard table of ty_mm01,
 wa_mm01 like TT_MM01.
data : t_bdcdata like standard table of bdcdata,
 t_bdcmsgcoll like standard table of bdcmsgcoll.
constants: begcol TYPE i value 1 ,
 begrow TYPE i value 1,
 endcol TYPE i value 100,
 endrow TYPE i value 32000.
selection-screen : begin of block bdc with frame.
parameter : tfile like rlgrap-filename obligatory.
selection-screen : end of block bdc.
at selection-screen on value-request for tfile.
CALL FUNCTION 'KD_GET_FILENAME_ON_F4'
EXPORTING
 PROGRAM_NAME = 'ZMM_MAT_MAS_BASIC_DATA'
 DYNPRO_NUMBER = '1000'
 FIELD_NAME = 'TFILE'
 STATIC = 'X'
MASK = ',*.xls,'
CHANGING
 FILE_NAME = tfile
start-of-selection.
CALL FUNCTION 'ALSM_EXCEL_TO_INTERNAL_TABLE'
EXPORTING
 FILENAME = tfile
 I_BEGIN_COL = begcol
 I_BEGIN_ROW = begrow
 I_END_COL = endcol
 I_END_ROW = endrow
TABLES
 INTERN = tt_mm01
EXCEPTIONS
INCONSISTENT_PARAMETERS = 1
UPLOAD_OLE = 2
OTHERS = 3
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
 WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
Thanks in advance

Hi,
Check these FM : KCD_EXCEL_OLE_TO_INT_CONVERT
Report ZPSP_TEST.
data: bdc_DATA like bdcdata occurs 0 with header line,
mess_tab like bdcmsgcoll occurs 0 with header line.
DATA: BEGIN OF ITAB OCCURS 0 ,
tcnt TYPE i, "Table Counter &H0D
WERKS LIKE T001W-WERKS,
BNFPO LIKE EBAN-BNFPO,
MATNR LIKE MARA-MATNR,
MENGE LIKE EBAN-MENGE,
END OF ITAB.
start-of-selection.
PERFORM upload_data.
loop at itab.
perform bdc_dynpro using 'SAPMM06B' '0100'.
perform bdc_field using 'BDC_CURSOR'
'EBAN-BSART'.
perform bdc_field using 'BDC_OKCODE'
'/00'.
perform bdc_field using 'EBAN-BSART'
'NB'.
perform bdc_field using 'RM06B-LPEIN'
'T'.
perform bdc_field using 'EBAN-WERKS'
ITAB-WERKS.
perform bdc_dynpro using 'SAPMM06B' '0106'.
perform bdc_field using 'BDC_CURSOR'
'RM06B-EKGRP'.
perform bdc_field using 'BDC_OKCODE'
'/00'.
perform bdc_field using 'RM06B-BNFPO'
ITAB-BNFPO.
perform bdc_dynpro using 'SAPMM06B' '0106'.
perform bdc_field using 'BDC_CURSOR'
'EBAN-MENGE(01)'.
perform bdc_field using 'BDC_OKCODE'
'/00'.
perform bdc_field using 'EBAN-MATNR(01)'
ITAB-MATNR.
perform bdc_field using 'EBAN-MENGE(01)'
ITAB-MENGE.
perform bdc_dynpro using 'SAPMM06B' '0102'.
perform bdc_field using 'BDC_CURSOR'
'EBAN-MENGE'.
perform bdc_field using 'BDC_OKCODE'
'/00'.
*perform bdc_field using 'RM06B-EEIND'
record-EEIND_010.
*perform bdc_field using 'RM06B-LPEIN'
record-LPEIN_011.
*perform bdc_field using 'EBAN-EKGRP'
record-EKGRP_012.
*perform bdc_field using 'EBAN-BADAT'
record-BADAT_013.
*perform bdc_field using 'EBAN-FRGDT'
record-FRGDT_014.
*perform bdc_field using 'EBAN-PREIS'
record-PREIS_015.
*perform bdc_field using 'EBAN-WAERS'
record-WAERS_016.
*perform bdc_field using 'EBAN-PEINH'
record-PEINH_017.
*perform bdc_field using 'EBAN-REPOS'
record-REPOS_018.
perform bdc_dynpro using 'SAPMM06B' '0106'.
perform bdc_field using 'BDC_CURSOR'
'EBAN-MENGE(02)'.
perform bdc_field using 'BDC_OKCODE'
'/00'.
*perform bdc_field using 'RM06B-BNFPO'
record-BNFPO_019.
*perform bdc_field using 'EBAN-MATNR(02)'
record-MATNR_02_020.
*perform bdc_field using 'EBAN-MENGE(02)'
record-MENGE_02_021.
perform bdc_dynpro using 'SAPMM06B' '0102'.
perform bdc_field using 'BDC_CURSOR'
'EBAN-MENGE'.
perform bdc_field using 'BDC_OKCODE'
'/00'.
*perform bdc_field using 'EBAN-MENGE'
ITAB-MENGE_023.
*perform bdc_field using 'RM06B-EEIND'
record-EEIND_024.
*perform bdc_field using 'RM06B-LPEIN'
record-LPEIN_025.
*perform bdc_field using 'EBAN-EKGRP'
record-EKGRP_026.
*perform bdc_field using 'EBAN-BADAT'
record-BADAT_027.
*perform bdc_field using 'EBAN-FRGDT'
record-FRGDT_028.
*perform bdc_field using 'EBAN-PREIS'
record-PREIS_029.
*perform bdc_field using 'EBAN-WAERS'
record-WAERS_030.
*perform bdc_field using 'EBAN-PEINH'
record-PEINH_031.
*perform bdc_field using 'EBAN-REPOS'
record-REPOS_032.
perform bdc_field using 'EBAN-TXZ01'
'BEARING 2"X2"'.
perform bdc_field using 'EBAN-MENGE'
'65'.
perform bdc_field using 'RM06B-EEIND'
'2005/01/03'.
perform bdc_field using 'RM06B-LPEIN'
'D'.
perform bdc_field using 'EBAN-EKGRP'
'M11'.
perform bdc_field using 'EBAN-BADAT'
'2005/01/03'.
perform bdc_field using 'EBAN-FRGDT'
'2005/01/03'.
perform bdc_field using 'EBAN-PREIS'
' 1,120.00'.
perform bdc_field using 'EBAN-WAERS'
'EUR'.
perform bdc_field using 'EBAN-PEINH'
'1'.
perform bdc_field using 'EBAN-REPOS'
'X'.
perform bdc_dynpro using 'SAPMM06B' '0102'.
perform bdc_field using 'BDC_CURSOR'
'EBAN-MENGE'.
perform bdc_field using 'BDC_OKCODE'
'/00'.
perform bdc_field using 'EBAN-TXZ01'
'DRILLING PIPE 10"'.
perform bdc_field using 'EBAN-MENGE'
'75'.
perform bdc_field using 'RM06B-EEIND'
'2005/01/03'.
perform bdc_field using 'RM06B-LPEIN'
'D'.
perform bdc_field using 'EBAN-EKGRP'
'M11'.
perform bdc_field using 'EBAN-BADAT'
'2005/01/03'.
perform bdc_field using 'EBAN-FRGDT'
'2005/01/03'.
perform bdc_field using 'EBAN-PREIS'
' 0.53'.
perform bdc_field using 'EBAN-WAERS'
'EUR'.
perform bdc_field using 'EBAN-PEINH'
'1'.
perform bdc_field using 'EBAN-REPOS'
'X'.
perform bdc_dynpro using 'SAPMM06B' '0106'.
perform bdc_field using 'BDC_CURSOR'
'RM06B-BNFPO'
perform bdc_field using 'BDC_OKCODE'
'&H3DBU'.
*perform bdc_field using 'RM06B-BNFPO'
CALL TRANSACTION 'ME51' USING BDC_DATA MODE 'A'.
endLOOP.
FORM upload_data.
*local variable declaration
DATA : lv_index TYPE i,
l_count TYPE i.
*local constants declaration
CONSTANTS:
lc_start_col TYPE i VALUE '1' ,
lc_start_row TYPE i VALUE '2' ,
lc_end_col TYPE i VALUE '256' ,
lc_end_row TYPE i VALUE '65536'.
*local field symbol declaration
FIELD-SYMBOLS : <lf_s>.
*loacal internal table declaration
DATA : li_intern TYPE kcde_cells OCCURS 0 WITH HEADER LINE.
*refresh internal table for each loop
CLEAR: li_intern,
l_count .
REFRESH li_intern.
to upload the data in excel on the presentation server this function
module converts the data from excel file into an internal table
containing row no col no and value
CALL FUNCTION 'KCD_EXCEL_OLE_TO_INT_CONVERT'
EXPORTING
filename &H3D 'Give file location here'
i_begin_col &H3D lc_start_col
i_begin_row &H3D lc_start_row
i_end_col &H3D lc_end_col
i_end_row &H3D lc_end_row
TABLES
intern &H3D li_intern
EXCEPTIONS
inconsistent_parameters &H3D 1
upload_ole &H3D 2.
checking for data in internal table
CHECK NOT li_intern[] IS INITIAL.
sorting internal table
SORT li_intern BY row col.
collecting data into an internal table
LOOP AT li_intern.
MOVE: li_intern-col TO lv_index.
lv_index &H3D lv_index + 1.
ASSIGN COMPONENT lv_index OF STRUCTURE itab TO <lf_s>.
MOVE : li_intern-value TO <lf_s>.
AT END OF row.
l_count &H3D l_count + 1.
itab &H3D l_count.
APPEND itab.
ENDAT. " at end of row
ENDLOOP. " loop at li_intern
Reg,
Siva
Edited by: Siva Prasad on Jun 1, 2009 8:41 AM
Edited by: Siva Prasad on Jun 1, 2009 4:25 PM

Need logic in Internal table processing

Hi all,
I have requirement like this.
i cretaed three internal tables
1) first Internal table can store total uploaded data from flat file..means line by line( Here each line is one record)
2) Second internal can store all fields which are fetched based on table which is given on selction screen.
3)now i cretaed one internal table with one variable
4) i used spilt statement on first internal table ( which store all flat file recrds) into third internal table.
so , my third internal table has first records values of first internal table in one column.
Now my probelm...i need to populate bapi structre tables with values of third internal table based on field names of second internal table. i am not able to do logic.
Is there any pointers to know soultion
Note:we know which fields values from flat values needs to populate Bapi structure table..
Thanks in advance,
regards,
JBR

check this program may be u will get the logic
*& Report ZBAPI_MATERIAL_SAVEDATA
*& PURPOSE : THIS REPORT USES BAPI MATERIAL SAVE DATA TO UPDATE AND CREATE
*& THE MATERIAL
REPORT ZBAPI_MATERIAL_SAVEDATA NO STANDARD PAGE HEADING MESSAGE-ID (ZHNC).
TYPES:BEGIN OF TY_MAT,
 MATERIAL(4),
 IND_SECTOR(1),
 MATL_TYPE(4),
 MATL_GROUP(9),
 BASE_UOM(3),
 BASE_UOM_ISO(3),
 PLANT(4),
 DEL_FLAG(1),
 PUR_GROUP(3),
 BASE_QTY(13),
 STGE_LOC(4),
 MRP_IND(1),
 SALES_ORG(4),
 DISTR_CHAN(2),
 DEL_FLAG1(1),
 MIN_ORDER(13),
 LANGU(2),
 MATL_DESC(40),
 END OF TY_MAT.
DATA: IT_DATA TYPE TABLE OF TY_MAT,
 WA_DATA LIKE LINE OF IT_DATA.
*decalraing flag
data: v_flag value ''.
*DECLARING WORK AREAs TO BE PASSED TO THE FUNCTION MODULE.
DATA: BAPI_HEAD LIKE BAPIMATHEAD,
 BAPI_CLIENTDATA LIKE BAPI_MARA,
 BAPI_CLIENTDATAX LIKE BAPI_MARAX,
 BAPI_PLANTDATA LIKE BAPI_MARC,
 BAPI_PLANTDATAX LIKE BAPI_MARCX,
 BAPI_STORAGELOCATIONDATA LIKE BAPI_MARD,
 BAPI_STORAGELOCATIONDATAX LIKE BAPI_MARDX,
 BAPI_SALESDATA LIKE BAPI_MVKE,
 BAPI_SALESDATAX LIKE BAPI_MVKEX,
 BAPI_MAKT LIKE BAPI_MAKT,
 BAPI_RETURN LIKE BAPIRET2.
*INTERNAL TABLE TO HOLD THE MATERIAL DESCRIPTION
DATA: BEGIN OF IT_MAKT OCCURS 0.
INCLUDE STRUCTURE BAPI_MAKT.
DATA END OF IT_MAKT.
DATA:BEGIN OF IT_RET OCCURS 0.
INCLUDE STRUCTURE BAPIRET2.
DATA END OF IT_RET.
*INTERNAL TABLE TO HOLD HEADER DATA
DATA: IT_EXCEL TYPE ALSMEX_TABLINE OCCURS 0 WITH HEADER LINE.
*SELECTION-SCREEN ELEMENTS
SELECTION-SCREEN BEGIN OF BLOCK B1 WITH FRAME TITLE TEXT-001.
PARAMETER: FNAME TYPE RLGRAP-FILENAME OBLIGATORY DEFAULT 'C:\Documents and Settings\Administrator\Desktop\MATMAS.XLS' .
PARAMETERS: P_BEGCOL TYPE I DEFAULT 1 NO-DISPLAY,
 P_BEGROW TYPE I DEFAULT 1 NO-DISPLAY,
 P_ENDCOL TYPE I DEFAULT 100 NO-DISPLAY,
 P_ENDROW TYPE I DEFAULT 32000 NO-DISPLAY.
SELECTION-SCREEN END OF BLOCK B1.
*DECLARATION OF EXCELAL TABLE
AT SELECTION-SCREEN ON VALUE-REQUEST FOR FNAME.
PERFORM F_GET_FILE USING FNAME.
START-OF-SELECTION.
PERFORM F_XLS_ITAB USING FNAME
 CHANGING IT_EXCEL.
PERFORM F_MOVE_DATA.
perform F_GET_DATA.
*& Form F_GET_FILE
 text
 -->P_FNAME text
 <--P_SY_SUBRC text
FORM F_GET_FILE USING P_FNAME LIKE FNAME.
CALL FUNCTION 'KD_GET_FILENAME_ON_F4'
EXPORTING
 PROGRAM_NAME = SYST-REPID
 DYNPRO_NUMBER = SYST-DYNNR
FIELD_NAME = ' '
STATIC = ' '
MASK = ' '
CHANGING
 FILE_NAME = P_FNAME
EXCEPTIONS
MASK_TOO_LONG = 1
OTHERS = 2
IF SY-SUBRC <> 0.
MESSAGE E006(ZHNC).
ENDIF.
ENDFORM. " F_GET_FILE
*& Form F_XLS_ITAB
 text
 -->P_FNAME text
 <--P_IT_EXCEL text
FORM F_XLS_ITAB USING P_FNAME
 CHANGING P_IT_EXCEL.
CALL FUNCTION 'ALSM_EXCEL_TO_INTERNAL_TABLE'
EXPORTING
 FILENAME = FNAME
 I_BEGIN_COL = P_BEGCOL
 I_BEGIN_ROW = P_BEGROW
 I_END_COL = P_ENDCOL
 I_END_ROW = P_ENDROW
TABLES
 INTERN = IT_EXCEL
EXCEPTIONS
 INCONSISTENT_PARAMETERS = 1
 UPLOAD_OLE = 2
 OTHERS = 3
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
 WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDFORM. " F_XLS_ITAB
*& Form F_MOVE_DATA
 text
--> p1 text
<-- p2 text
FORM F_MOVE_DATA .
DATA : LV_INDEX TYPE I.
FIELD-SYMBOLS <FS>.
*--- Sorting the internal table
SORT IT_EXCEL BY ROW COL.
CLEAR IT_EXCEL.
LOOP AT IT_EXCEL.
MOVE IT_EXCEL-COL TO LV_INDEX.
*--- Assigning the each record to an internal table row
ASSIGN COMPONENT LV_INDEX OF STRUCTURE WA_DATA TO <FS>.
*--- Asigning the field value to a field symbol
MOVE IT_EXCEL-VALUE TO <FS>.
AT END OF ROW.
APPEND WA_DATA TO IT_DATA.
CLEAR WA_DATA.
ENDAT.
ENDLOOP.
ENDFORM. " F_MOVE_DATA
*& Form F_GET_DATA
 text
--> p1 text
<-- p2 text
FORM F_GET_DATA .
LOOP AT IT_DATA INTO WA_DATA.
MOVE-CORRESPONDING WA_DATA TO BAPI_HEAD.
BAPI_HEAD-BASIC_VIEW ='X'.
BAPI_HEAD-SALES_VIEW ='X'.
BAPI_HEAD-PURCHASE_VIEW ='X'.
BAPI_HEAD-STORAGE_VIEW ='X'.
MOVE-CORRESPONDING WA_DATA TO BAPI_CLIENTDATA.
BAPI_CLIENTDATAX-MATL_GROUP = 'X'.
BAPI_CLIENTDATAX-BASE_UOM = 'X'.
BAPI_CLIENTDATAX-BASE_UOM_ISO = 'X'.
MOVE-CORRESPONDING WA_DATA TO BAPI_PLANTDATA.
BAPI_PLANTDATAX-PLANT = BAPI_PLANTDATA-PLANT.
BAPI_PLANTDATAX-DEL_FLAG = 'X'.
BAPI_PLANTDATAX-PUR_GROUP = 'X'.
BAPI_PLANTDATAX-BASE_QTY = 'X'.
MOVE-CORRESPONDING WA_DATA TO BAPI_STORAGELOCATIONDATA.
BAPI_STORAGELOCATIONDATA-PLANT = BAPI_PLANTDATA-PLANT.
BAPI_STORAGELOCATIONDATAX-PLANT = BAPI_STORAGELOCATIONDATA-PLANT.
BAPI_STORAGELOCATIONDATAX-STGE_LOC = BAPI_STORAGELOCATIONDATA-STGE_LOC.
BAPI_STORAGELOCATIONDATAX-MRP_IND = 'X'.
MOVE-CORRESPONDING WA_DATA TO BAPI_SALESDATA.
BAPI_SALESDATAX-SALES_ORG = BAPI_SALESDATA-SALES_ORG.
BAPI_SALESDATAX-DISTR_CHAN = BAPI_SALESDATA-DISTR_CHAN.
BAPI_SALESDATAX-DEL_FLAG = BAPI_SALESDATA-DEL_FLAG.
BAPI_SALESDATAX-MIN_ORDER = 'X'.
REFRESH IT_MAKT.
IT_MAKT-LANGU = WA_DATA-LANGU.
IT_MAKT-MATL_DESC = WA_DATA-MATL_DESC.
APPEND IT_MAKT.
CLEAR IT_RET.
REFRESH IT_RET.
PERFORM F_CALL_BAPI.
READ TABLE IT_RET WITH KEY TYPE = 'S'.
IF SY-SUBRC EQ 0.
PERFORM F_BAPI_COMMIT.
WRITE:/ 'MATERIAL CREATED OR UPDATED SUCESSFULLY WITH MATERIAL NO',WA_DATA-MATERIAL.
ELSE.
MESSAGE E000(ZHNC) WITH 'ERROR IN CREATING THE MATERIAL'.
*WRITE: / 'ERROR IN CREATIN MATERIAL',IT_RET-MESSAGE.
*PERFORM F_DOWNLOAD.
ENDIF.
*ENDIF.
ENDLOOP.
ENDFORM. " F_GET_DATA
*& Form F_CALL_BAPI
 text
--> p1 text
<-- p2 text
FORM F_CALL_BAPI .
CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
EXPORTING
 HEADDATA = BAPI_HEAD
 CLIENTDATA = BAPI_CLIENTDATA
 CLIENTDATAX = BAPI_CLIENTDATAX
 PLANTDATA = BAPI_PLANTDATA
 PLANTDATAX = BAPI_PLANTDATAX
 STORAGELOCATIONDATA = BAPI_STORAGELOCATIONDATA
 STORAGELOCATIONDATAX = BAPI_STORAGELOCATIONDATAX
 SALESDATA = BAPI_SALESDATA
 SALESDATAX = BAPI_SALESDATAX
IMPORTING
 RETURN = IT_RET
TABLES
 MATERIALDESCRIPTION = IT_MAKT
UNITSOFMEASURE =
UNITSOFMEASUREX =
INTERNATIONALARTNOS =
MATERIALLONGTEXT =
TAXCLASSIFICATIONS =
RETURNMESSAGES =
PRTDATA =
PRTDATAX =
EXTENSIONIN =
EXTENSIONINX =
APPEND IT_RET.
ENDFORM. " F_CALL_BAPI
*& Form F_BAPI_COMMIT
 text
--> p1 text
<-- p2 text
FORM F_BAPI_COMMIT .
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
WAIT =
IMPORTING
RETURN =
ENDFORM. " F_BAPI_COMMIT

Application server Excel file to Internal table

Hi experts,
I have an excel file on the App server.
I need to upload it to internal tables.
Pls let me knw how this can be done....
Thanks in advance
Note : Valid answers will be rewarded!!

Gayathri,
Try with below 2 methods.
1.
DATA : l_t_intern TYPE kcde_cells OCCURS 0 WITH HEADER LINE.
DATA : l_f_index TYPE i.
DATA : l_f_start_col TYPE i VALUE '1',
l_f_start_row TYPE i VALUE '2',
l_f_end_col TYPE i VALUE '38',
l_f_end_row TYPE i VALUE '65536'.
FIELD-SYMBOLS : <l_fs>.
CALL FUNCTION 'KCD_EXCEL_OLE_TO_INT_CONVERT'
EXPORTING
filename = p_i_path
i_begin_col = l_f_start_col
i_begin_row = l_f_start_row
i_end_col = l_f_end_col
i_end_row = l_f_end_row
TABLES
intern = l_t_intern.
Assign uploaded XL fields to the fields of the target internal table
SORT l_t_intern BY row col .
LOOP AT l_t_intern .
MOVE l_t_intern-col TO l_f_index .
ASSIGN COMPONENT l_f_index OF STRUCTURE g_t_upload TO <l_fs> .
MOVE l_t_intern-value TO <l_fs> .
AT END OF row .
APPEND g_t_upload .
ENDAT .
ENDLOOP .
ENDIF .
2>
code
DATA: v_string TYPE string.
DATA: v_hex TYPE x VALUE '09'.
DATA: BEGIN OF itab OCCURS 0,
matnr TYPE matnr,
werks TYPE werks_d,
END OF itab.
OPEN DATASET '/tmp/test.xls' FOR INPUT.
CHECK sy-subrc = 0.
DO.
READ DATASET '/tmp/test.xls' INTO v_string.
IF sy-subrc 0.
EXIT.
ENDIF.
SPLIT v_string AT v_hex INTO itab-matnr itab-werks.
ENDDO.
CLOSE DATASET '/tmp/test.xls'.
Pls. reward if useful.....

Internal Table Doubt!!!

Hi!
 I ve doubt on the following,
1) Data: Begin of itab occurs 10
 ......, end of itab.
 In the above what will happen if i store records more than 10 & less than 10 records
if more than 10 where records will be stored .
if i store 5 then whats the remaining storage space.
2) Types of internal Table
 SOrted, Hashed, index, standard
 Can u pls explain in short terms(i dont want big details) good understanding
 which one from above improve performance
3) see this,
 types: begin of ty_itab occurs 0,
 mara like mara-matnr.
 end of ty_itab,
 ty_t_itab type standard table of ty_itab with default key.
Data: it_itab type ty_t_itab.
 it_itab2 like it_itab
 or it_itab2 type ty_t_itab.
i want to know,
 ty_t_itab is an internal table with header line or not
 it_itab, it_itab2 has header line or not
Pls reply guys, looking for your reply.
Thanks In Advance.
Rahul.

Hi,
if more then 10 then records will be stored in the table itself
if less than 10 then space willbe reserved for 10 records
Standard Tables:
Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.
This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to
the number of table entries.
Sorted Tables:
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship 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, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of
table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.
Hashed Tables:
Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.
This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.
it_itab, it_itab2 has header line
Regards,
ravish
plz dont forget to reward points if useful

Internal Table and Structures

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.

To access different lines in an in internal table

Hi People,
How can I access different lines of an internal table where there is not set index which I have to access? I have to write only the last occurence of each kunnr getting stored in the internal table. Can somebody help?
Thanks,
AM

Hi AM,
   You have got multiple solutions, each one of those are based on some assumptions.
   1. At end - this solution will work if kunnr is the first field in your internal table (Sorted).
   2. Edde's solution will work if all the values for kunnr in the internal table are same.
   If not of this applies then you need write a piece of logic between LOOP and ENDLOOP, but the right solution will depend on the exact nature of your problem. More you explain your problem better are the chances of getting a solution.
Regards,
Sanjeev

Internal table sort

Similar Messages

Maybe you are looking for