Is it important to use INITIAL SIZE 0 in internal table

Hi Friends,
I want to know, is it important to use INITIAL SIZE 0 in the time of internal table deceleration.
TYPES:       BEGIN OF L_TYP_TAB_VBELN,
                     VBELN    LIKE VBAK-VBELN,         
              END   OF L_TYP_TAB_VBELN.
DATA:  L_TAB_VBELN  TYPE STANDARD TABLE OF L_TYP_TAB_VBELN.
                                                                                OR
DATA:  L_TAB_VBELN TYPE STANDARD TABLE OF L_TYP_TAB_VBELN INITIAL SIZE 0.
In these two internal tables which one is good as a code and performance?
Please explain also.
Regards
Amit

Hi Amit,
After the optional addition INITIAL SIZE, you can specify a number of rows n as a numeric literal or numeric constant to adjust the size of the first block in the memory that is reserved by the system for an internal table of the table type. Without this addition, if the number 0 is entered, or the value of n exceeds a maximum value, the system automatically allocates an appropriate memory area. If this is no longer sufficient, the system creates an additional block twice the size of the first block as long as this size does not exceed 8 KB. Additional areas are created where necessary with a size of 12 KB. The maximum value is calculated as 8 KB divided by the memory required for a row. In the case of larger values, a block size of 12 KB is automatically selected.
You are advised to specify the initial memory requirements only when the number of entries in the table has already been specified and the initial main memory requirement has an adequate value. This can be especially important for internal tables that are components of table types and only contain a few rows.
Hope this helps
Regds,

Similar Messages

  • Limit on the memory/size of the internal table

    Hi,
    Is there any limit on the size of internal table....?
    we are having some select statements that are fetching huge no. of records into the internal tables...
    can some of the records be missed  or is there any limit on the no. of records or size of the internal table...
    The code that we are using is logically correct and it is working fine for small inputs but for the large selections, some of the records are getting missed as we are displaying the data from these internal tables only...
    We can not debug the code coz for the large inputs, code is taking around 2 to 3 hours of processing
    We are using this code in BI in the end routines
    We are doing the operation like
    itab1 = itab2
    where itab2 contains around 25000 records and itab1 is initial(no entries)
    If there is a limit , then how can we increase the size
    Please suggest..
    Thanks
    Tarun Brijwani
    Edited by: Tarun Brijwani on Apr 23, 2009 6:06 PM
    Edited by: Tarun Brijwani on Apr 23, 2009 6:06 PM

    Hello Tarun
    You can limit the number of records selected by your SELECT statement by adding the addition "UP TO n ROWS" to your SELECT statement.
    Example:
    SELECT * FROM TABLEXYZ UP TO 5000 ROWS WHERE .........
    Hope this helps you.
    Thanks and best regards
    Anand.

  • Size of the internal table

    Hi Experts,
    I would like to ask about the size limit of internal table?
    How many records can I fetch into an internal table?
    iam not getting the correct answer,plz any one can tell me pin point answer.
    Thanks,

    hi ,
    there is no limit for records to the internal table ,its depends on your server memory available.
    internal table is a temporary memory ,so its totally dependent on the memory.
    thanks
    siddharth

  • Using where condition with dynamic internal table

    Hi Friends.
    How to use where condition with dynamic internal table ?
    Regards,
    Amit Raut

    Hai Amit
    REPORT  ZDYNAMIC_SELECT                         .
    TABLES: VBAK.
    DATA: CONDITION TYPE STRING.
    DATA: BEGIN OF ITAB OCCURS 0,
    VBELN LIKE VBAK-VBELN,
    POSNR LIKE VBAP-POSNR,
    END OF ITAB.
    SELECT-OPTIONS: S_VBELN FOR VBAK-VBELN.
    CONCATENATE 'VBELN' 'IN' 'S_VBELN.'
    INTO CONDITION SEPARATED BY SPACE.
    SELECT VBELN POSNR FROM VBAP INTO TABLE ITAB
    WHERE (CONDITION).
    LOOP AT ITAB.
    WRITE 'hello'.
    ENDLOOP.
    Thanks & Regards
    Sreenivasulu P

  • Using submit to put to internal table

    Dear experts,
    I am willing to run transaction MB51 within my se38 program using Submit.Its corresponding program name is
    RM07DOCS.
    Further i want to declare an internal table ,structure of which should be same as the output.I want to capture the output to this internal table.How can i achieve this ?

    Hi Aditya,
    In RM07DOCS program, you have to find exit/enhancement point to EXPORT  the output to memory.
    And in your zprogram, after submit RM07DOCS program you add code to IMPORT from memory to your itab.
    Hope it's give you an idea.
    Thanks,
    Victor.

  • SORT INTERNAL TABLE USING NON KEY OF THE INTERNAL TABLE

    HI,
    i have one query for the cdpos table of abap.
    What i am looking is i want the latest CHANENR of the cdpos for that
    objectid  and tabname and fname in my internal table.
    what i thought of doing was to sort my internal table with objectid changnr tabname fname in descending order
    and than use delete adjacent duplicates command
    BUt that is not sorting based on all field , its sorting on changnr only
    please let me know what can i do

    no, that is not what i am looking at,
    I am saying say i have internal table cdpos
    OBJECTCLAS      OBJECTID    CHANGENR   TABNAME                        FNAME
    RECN_RECN      |0100TEST1   0000384409|    VICN01                        |RECNEND
    RECN_RECN       0100TEST1   0000383462    VICN01                          RECNLIFNR 
    RECN_RECN       0100TEST1    0000360190   VICN01                         RECNEND
    RECN_RECN        0100TEST1   0000340630    VICN01                         RECNEND
    this is my debug output after sorting on objectid changenr tabname fname in descending
    i wanted line 2nd to be at last so when i use delete adjacent command i can get 2 line item i.e 1st and 2nd line ...

  • Using abap code data from internal table to XML file create

    Hi ALL,
    i am using methods
      L_VALUE = GS_DOCUMENT-U_MITARBEITER.
      L_RC = L_ELEMENT_FLIGHTS->SET_ATTRIBUTE( NAME = 'U_Mitarbeiter' VALUE = L_VALUE ).
      CLEAR: L_VALUE,
             L_RC.
      L_VALUE = GS_DOCUMENT-VORNAME .
      L_RC = L_ELEMENT_FLIGHTS->SET_ATTRIBUTE( NAME = 'Vorname' VALUE = L_VALUE ).
         ENDLOOP.
      LOOP AT GS_DOCUMENT-GI_TIMETABLE INTO GS_TIMETABLE.
        L_ELEMENT_AIRLINE  = L_DOCUMENT->CREATE_SIMPLE_ELEMENT(
            NAME = 'Timetable'
            PARENT = L_ELEMENT_FLIGHTS  ).
          Create attribute 'code' of node 'airline'
        L_VALUE = GS_TIMETABLE-BEGINNUHRZEIT.
        L_RC = L_ELEMENT_AIRLINE->SET_ATTRIBUTE( NAME = 'Beginnuhrzeit' VALUE = L_VALUE ).
        L_VALUE = GS_TIMETABLE-BEMERKUNGEN.
        L_RC = L_ELEMENT_AIRLINE->SET_ATTRIBUTE( NAME = 'Bemerkungen' VALUE = L_VALUE ).
        L_VALUE = GS_TIMETABLE-ENDEUHRZEIT  .
        L_RC = L_ELEMENT_AIRLINE->SET_ATTRIBUTE( NAME = 'Endeuhrzeit' VALUE = L_VALUE ).
        L_VALUE = GS_TIMETABLE-BUCHUNGSDATUM.
        L_RC = L_ELEMENT_AIRLINE->SET_ATTRIBUTE( NAME = 'Buchungsdatum' VALUE = L_VALUE ).
      ENDLOOP.
      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( ).
    i am geting the output,
    line1
    <?xml version="1.0"?><Head Document="002_TMA1_KW1_SAP.XML" Innenauftragsnummer="008004000800" Kalenderwoche="17" MonatJahr="04/2008" Name="" Personalnummer="91003139" Projektnummer="1400000700" Regionalstelle="B" U_Entleiher="1" U_Mitarbeiter="1" Vorname=
    line 2
    Ricky"><Timetable Beginnuhrzeit="08:00" Bemerkungen="" Endeuhrzeit="16:30" Buchungsdatum="21.04.2008"/><Timetable Beginnuhrzeit="08:00" Bemerkungen="" Endeuhrzeit="16:30" Buchungsdatum="22.04.2008"/><Timetable Beginnuhrzeit="08:00" Bemerkungen="" Endeuhrz
    line 3
    it="16:30" Buchungsdatum="23.04.2008"/><Timetable Beginnuhrzeit="08:00" Bemerkungen="" Endeuhrzeit="16:30" Buchungsdatum="24.04.2008"/><Timetable Beginnuhrzeit="08:00" Bemerkungen="" Endeuhrzeit="16:30" Buchungsdatum="25.04.2008"/></Head>
    but i want this type line by line
    <?xml version="1.0" encoding="ISO-8859-1"?>
    <Document Dokumentnummer="001_TMA7_KW2_MAN" Dokumenttyp="TN_HE" Innenauftragsnummer="8004750104" Kalenderwoche="15" MonatJahr="04/2008" Name="Banana" Personalnummer="166326" Projektnummer="1400000203" Regionalstelle="RV1" U_Entleiher="1" U_Mitarbeiter="1" Vorname="Sepp">
    <TimeTable Beginnuhrzeit="08:00" Bemerkungen="" Buchungsdatum="07.04.2008" Endeuhrzeit="16:00"/>
    <TimeTable Beginnuhrzeit="08:00" Bemerkungen="" Buchungsdatum="08.04.2008" Endeuhrzeit="16:00"/>
    <TimeTable Beginnuhrzeit="08:00" Bemerkungen="" Buchungsdatum="09.04.2008" Endeuhrzeit="16:30"/>
    <TimeTable Beginnuhrzeit="08:00" Bemerkungen="" Buchungsdatum="10.04.2008" Endeuhrzeit="16:30"/>
    <TimeTable Beginnuhrzeit="08:00" Bemerkungen="" Buchungsdatum="11.04.2008" Endeuhrzeit=""/>
    </Document>
    for line breaking, please give me solution
    Regards,
    Santha

    Hi,
    Please give me more inforamtion, how to use this
    CLASS cl_abap_char_utilities DEFINITION LOAD.
    cl_abap_char_utilities=>newline
    Regards,
    Santha

  • Initializing values in an internal table

    hi
    how to initialize values in a internal table
    according to my requirement i need to initialize (both character and currency) values present in the internal table based on certain conditions
    vamsi

    hi
    As i understood you want to clear only selected fileds not the complet record..
    create a Field symobl the loop at the table.. inside the loop check the condtion the just clear the filed.
    example: you have itab type mara.
    then
    FIELD-SYMOBOLS <FS_WA_ITAB> TYPE MARA.
    LOOP AT ITAB ASSIGNING <FS_WA_ITAB>.
    IF X = XXX (YOUR CONDITION)
    CLEAR: <FS_WA_ITAB>-FIELD2,
                 <FS_WA_ITAB>-FIELD3. (If u want to clear only filed2 and field3)
    clear <FS_WA_ITAB>. (if you want to cleatr the complete record)
    ENDIF.
    ENDLOOP.
    Why iam suggestin the filed-symobol is.. it is direcltly work on internal table body so u no need to update the table agian
    Please Close this thread.. when u r problem is solved
    Reward if Helpful
    Regards
    Naresh Reddy K

  • What is the difference b/t  Initial Size 0 and Occurs 0 ?

    Hi SAP-ABAP Experts .
    I have created a internal table like this
    TYPES: BEGIN OF it_pa0001,
    ename TYPE pa0001-ename,
    END OF it_pa0001.
    (1) DATA: it_pa0001 TYPE STANDARD TABLE OF it_pa0001   INITIAL   SIZE 0,
    (2) DATA: it_pa0001 TYPE STANDARD TABLE OF pa0001 with header line  .
    (3) DATA: it_pa0001 like pa0001 occurs 0 with header line  .
    what is difference b/t Initial 0 and Occurs 0 ????
    PLease explain it .
    Best regards : rajneesh

    hi
    good
    Both are same...they define the initial size for the internal table..
    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,
    f1...,
    f2...,
    END OF itab.
    This statement declared an internal table itabwith 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,
    f1...,
    f2...,
    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 itabis created. Instead, the line type only exists as an attribute of the data object itab.
    thanks
    mrutyun^

  • 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

  • Import from internal table

    Dear Experts,
    I need a solution for importing from an internal table.
    Two variables I_EXP01 and I_EXP02 containing an xml stream have been exported to the database using the following syntax
    and depending on the size of I_EXP01 and I_EXP02 two or more entries are created in table LTEX.
    EXPORT
             L_SAPRL
             I_EXP01
             I_EXP02
    TO    DATABASE LTEX(LT)
                           ID LS_LTEXKEY.
    But now i have a few entries of table LTEX in an internal table and they need to be imported from the internal table.
    What would be the syntax to import from internal table so that after importing I can de-serialise the data from XML to ABAP.
    Thanks & Regards,
    Ashwini

    Try this and let me know if it works:
    IMPORT
    L_SAPRL
    I_EXP01
    I_EXP02
    To
    L_SAPRL1 (same type as above)
    I_EXP011 (same type as above)
    I_EXP021 (same type as above)
    FROM DATABASE LTEX(LT)
    ID LS_LTEXKEY.
    if it is not working. try using seperate statements for each internal table and see.
    Thanks,
    Venkatesh.
    Edited by: venkatesh333 on Jul 27, 2011 6:23 AM

  • Import an open office spreadsheet into internal table

    hi all,
            i have one requirment to import excel into sap but  i dont have MS office on my system     
              is  there any way to import an open office spreadsheet into internal table
                by using  ALSM_EXCEL_TO_INTERNAL_TABLE fm  or any other ways.

    Hi,
    You can use this function module 'ALSM_EXCEL_TO_INTERNAL_TABLE',
    It works fine, Here is a sample code hwich I developed and working fine.
      FIELD-SYMBOLS: <FS1>.
    Variables
      DATA: LV_BEGCOL TYPE I VALUE 1,
            LV_BEGROW TYPE I VALUE 1,
            LV_ENDCOL TYPE I VALUE 100,
            LV_ENDROW TYPE I VALUE 32000.
      DATA: LV_FILENAME LIKE RLGRAP-FILENAME.
      DATA: LV_ZWLEN TYPE I,
            LV_ZWLINES TYPE I.
      DATA: LV_TIND(4) TYPE N.
      DATA: LV_ZWFELD(30).
      DATA: KZHEADER TYPE XFELD.
    Internal Tables
      DATA: BEGIN OF LT_INTERN OCCURS 0.
              INCLUDE STRUCTURE  ALSMEX_TABLINE.
      DATA: END OF LT_INTERN.
      DATA: BEGIN OF LT_INTERN1 OCCURS 0.
              INCLUDE STRUCTURE  ALSMEX_TABLINE.
      DATA: END OF LT_INTERN1.
      DATA: BEGIN OF LT_COL OCCURS 0,
             COL LIKE ALSMEX_TABLINE-COL,
             SIZE TYPE I.
      DATA: END OF LT_COL.
      DATA: BEGIN OF LT_FIELDNAMES OCCURS 3,
              TITLE(60),
              TABLE(6),
              FIELD(10),
              KZ(1),
            END OF LT_FIELDNAMES.
    No of columns
      DATA: BEGIN OF LT_DATA_TAB OCCURS 0,
             VALUE_0001(50),
             VALUE_0002(50),
             VALUE_0003(50),
             VALUE_0004(50),
             VALUE_0005(50),
             VALUE_0006(50),
             VALUE_0007(50),
             VALUE_0008(50),
             VALUE_0009(50),
             VALUE_0010(50).
      DATA: END OF LT_DATA_TAB.
    Initialization
      LV_FILENAME = P_UFILE.
      CALL FUNCTION 'ALSM_EXCEL_TO_INTERNAL_TABLE'
        EXPORTING
          FILENAME                = LV_FILENAME
          I_BEGIN_COL             = LV_BEGCOL
          I_BEGIN_ROW             = LV_BEGROW
          I_END_COL               = LV_ENDCOL
          I_END_ROW               = LV_ENDROW
        TABLES
          INTERN                  = LT_INTERN
        EXCEPTIONS
          INCONSISTENT_PARAMETERS = 1
          UPLOAD_OLE              = 2
          OTHERS                  = 3.
      IF SY-SUBRC <> 0.
        WRITE:/ 'Uploading Error'(019), SY-SUBRC.
      ENDIF.
    Arrange Data
      LOOP AT LT_INTERN.
        LT_INTERN1 = LT_INTERN.
        CLEAR LT_INTERN1-ROW.
        APPEND LT_INTERN1.
      ENDLOOP.
      SORT LT_INTERN1 BY COL.
      LOOP AT LT_INTERN1.
        AT NEW COL.
          LT_COL-COL = LT_INTERN1-COL.
          APPEND LT_COL.
        ENDAT.
        LV_ZWLEN = STRLEN( LT_INTERN1-VALUE ).
        READ TABLE LT_COL WITH KEY COL = LT_INTERN1-COL.
        IF SY-SUBRC EQ 0.
          IF LV_ZWLEN > LT_COL-SIZE.
            LT_COL-SIZE = LV_ZWLEN.
    Internal Table, Current Row Index
            MODIFY LT_COL INDEX SY-TABIX.
          ENDIF.
        ENDIF.
      ENDLOOP.
      DESCRIBE TABLE LT_COL LINES LV_ZWLINES.
      SORT LT_INTERN BY ROW COL.
      IF KZHEADER = 'X'.
        LOOP AT LT_INTERN.
          LT_FIELDNAMES-TITLE = LT_INTERN-VALUE.
          APPEND LT_FIELDNAMES.
          AT END OF ROW.
            EXIT.
          ENDAT.
        ENDLOOP.
      ELSE.
        DO LV_ZWLINES TIMES.
          WRITE SY-INDEX TO LT_FIELDNAMES-TITLE.
          APPEND LT_FIELDNAMES.
        ENDDO.
      ENDIF.
      SORT LT_INTERN BY ROW COL.
      LOOP AT LT_INTERN.
        IF KZHEADER = 'X'
        AND LT_INTERN-ROW = 1.
          CONTINUE.
        ENDIF.
        LV_TIND = LT_INTERN-COL.
        CONCATENATE 'LT_DATA_TAB-VALUE_' LV_TIND INTO LV_ZWFELD.
        ASSIGN (LV_ZWFELD) TO <FS1>.
        <FS1> = LT_INTERN-VALUE.
        AT END OF ROW.
          APPEND LT_DATA_TAB.
          CLEAR LT_DATA_TAB.
        ENDAT.
      ENDLOOP.
    Thanks & Regards,
    Dileep .C

  • HOW TO USE A SINGLE PERFORM FOR VARIOUS TABLES ?

    perform test TABLES t_header.
    select
           KONH~KNUMH
           konh~datab
           konh~datbi
           konp~kbetr
           konp~konwa
           konp~kpein
           konp~kmein
           KONP~KRECH
           FROM konh INNER JOIN konp
                  ON konpknumh = konhknumh
           into table iTABXXX
            "ANY TEMPERARY INTERNAL TABLE.
           for all entries in t_header
           where
                 konh~kschl = t_header-kschl
             AND konh~knumh = t_header-knumh.
    endform.
    how can I use above perform for various internal tables of DIFFERENT LINE TYPES but having the fields KSCHL & KNUMH.

    u can use single perform....
    just see this example......hope this is what u r expecting....
    tables : pa0001.
    parameters : p_pernr like pa0001-pernr.
    data : itab1 like pa0001 occurs 0 with header line.
    data : itab2 like pa0002 occurs 0 with header line.
    perform get_data tables itab1 itab2.
    if not itab1[] is initial.
    loop at itab1.
    write :/ itab1-pernr.
    endloop.
    endif.
    if not itab2[] is initial.
    loop at itab2.
    write :/ itab2-pernr.
    endloop.
    endif.
    *&      Form  get_data
          text
         -->P_ITAB1  text
         -->P_ITAB2  text
    form get_data  tables   itab1 structure pa0001
                            itab2 structure pa0002.
    select * from pa0001 into table itab1 where pernr = p_pernr and begda le sy-datum and endda ge sy-datum.
    select * from pa0002 into table itab2 where pernr = p_pernr and begda le sy-datum and endda ge sy-datum.
    endform.                    " get_data
    Regards
    vasu

  • Passing values to an internal table and use it with the table painter

    Hi,
    I have seen this topic here before but the answers didn't help me. Maybe I,m doing something wrong.
    The problem is that I defined the following structure on the |Types| tab of the |Global Definitions| section:
    TYPES: BEGIN OF DETAILS,
           EBELP  TYPE EKPO-EBELP,
           BSMNG  TYPE EBAN-BSMNG,
           LFDAT  TYPE RM06P-LFDAT,
    END OF DETAILS.
    Then defined the following definition on the |Global Data| section:
    WA_DETAILS TYPE STANDARD TABLE OF DETAILS WITH HEADER LINE
    The problem is that when I try to assign a value to one of the fields in the program code like this:
    LOOP AT WA_EKPO.
         WA_DETAILS-EBELP = WA_EKPO-EBELP.
         WA_DETAILS-EMATN = WA_EKPO-EMATN.
         MODIFY WA_DETAILS.
    ENDLOOP.
    gives me the following error:
    "WA_DETAILS" is not an internal table -the "OCCURS n" specification is missing.
    Then if I add the "OCCURS 10" to the definition of the Global Data the error "OCCURS 10" is not expected.
    How can I define, assign values and use as a parameter an internal table defined with types for use it with the table painter?

    Hi,
    if it is one record in wa_details. you can directly write as follows..
    REPORT  ZCR_TEST1                               .
    TYPES: BEGIN OF details,
              ebelp TYPE ekpo-ebelp,
              bsmng TYPE eban-bsmng,
              lfdat TYPE rm06p-lfdat,
              ematn TYPE ekpo-ematn,
           END OF details.
    DATA: wa_details TYPE STANDARD TABLE OF details WITH HEADER LINE,
          wa_ekpo    TYPE STANDARD TABLE OF details WITH HEADER LINE.
    wa_details-ebelp = '1'.
    append wa_details.
    wa_ekpo-ebelp = '3'.
    append wa_ekpo.
    LOOP AT wa_ekpo.
      wa_ekpo-ebelp = wa_details-ebelp.
      wa_ekpo-ematn = wa_details-ematn.
      modify wa_ekpo.
    endloop.
    Normally it wont be one record, so u need to put <b>read statement with key</b> in LOOP and ENDLOOP.
    Regards,
    Sriram

  • Use secondary index in internal tables.

    what are the uses of secondary index in internal table?

    http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eb47446011d189700000e8322d00/content.htm
    Creating Secondary Indexes
    Proceed as follows to create a secondary index on a table:
    In the field maintenance screen for the table, choose Goto --> Indexes.
    1. If you went to the field maintenance screen of the table in display mode, only correct the index (and not the table).
    If indexes already exist on the table, a list of these indexes is displayed. Choose Create. A dialog box appears in which you must enter the three-place index identifier. If there are no indexes, go directly to the dialog box.
    2. Enter the index identifier and choose Continue.
    You will go to the maintenance screen for indexes.
    3. Enter an explanatory short text in the field Short text.
    Choose TabFields.
    4. A list of all the fields of the table is displayed.
    5. Select the fields which you want to copy to the index.
    6. Choose Copy.
    The selected fields are copied to the index.
    7. If the values in the index fields already uniquely identify each record of the table, select Unique index.
    A unique index is automatically created on the database during activation because a unique index also has a functional meaning (prevents double entries of the index fields).
    8. If it is not a unique index, leave Non-unique index selected. In this case you can use the corresponding radio buttons to define whether the index should be created automatically on the database for all database systems, for selected database systems or for no database system.
    9. If you chose For selected database systems, you must specify these systems.
    You have two possibilities here:
    List of inclusions: The index is only created automatically during activation for the database systems specified in the list. The index is not created on the database for the other database systems.
    List of exclusions: The index is not created automatically on the database during activation for the specified database systems. The index is automatically created on the database for the other database systems.
    Click on the arrow symbol behind the radio buttons. A dialog box appears in which you can define up to 4 database systems. Use the corresponding radio buttons to decide whether this list should be treated as a list of inclusions or exclusions.
    10. Activate the index with Index ® Activate. The activation log tells you about the flow of the activation. Call it with Utilities ® Act.log. If an error occurred when activating the secondary index, you will automatically go to this log.
    The secondary index is automatically created on the database during activation if the corresponding table has already been created there and index creation was not excluded for the database system.
    Reward points if useful.

Maybe you are looking for