Import internal table in submit program via job

Hi,
I'm submitting in a backgroudn job a program wich does a CALL TRANSACTION, this program submited reads ITBDC table importing table from memory ID 'itbdc' but this is empty, why in background job processing it can´t read data from memory because It seems it reads from another place or it's not reading anything!
Thanks!!

REPORT report2.
DATA: text       TYPE c LENGTH 10,
      rspar_tab  TYPE TABLE OF rsparams,
      rspar_line LIKE LINE OF rspar_tab,
      range_tab  LIKE RANGE OF text,
      range_line LIKE LINE OF range_tab.
rspar_line-selname = 'SELCRIT1'.
rspar_line-kind    = 'S'.
rspar_line-sign    = 'I'.
rspar_line-option  = 'EQ'.
rspar_line-low     = 'ABAP'.
APPEND rspar_line TO rspar_tab.
range_line-sign   = 'E'.
range_line-option = 'EQ'.
range_line-low    = 'H'.
APPEND range_line TO range_tab.
range_line-sign   = 'E'.
range_line-option = 'EQ'.
range_line-low    = 'K'.
APPEND range_line TO range_tab.
SUBMIT report1 USING SELECTION-SCREEN '1100'
               WITH SELECTION-TABLE rspar_tab
               WITH selcrit2 BETWEEN 'H' AND 'K'
               WITH selcrit2 IN range_tab
               AND RETURN.

Similar Messages

  • SUBMIT program VIA JOB and SET/GET parameter

    Hi All
    I need to pass the content of a variable from the program 'A' to program 'B'.
    Program A uses JOB_OPEN , SUBMIT program VIA JOB jobname NUMBER jobnumber AND return, JOB_CLOSE.
    I tried to use import/export memory but it didn't work. Then I am trying to use set/get parameters but it also did not work.
    Program A is going to run in any server and program B will run in the central instance (it is determined in the FM JOB_CLOSE, parameter target_server).
    Program does not have selection-screen.
    Is it possible use set/get parameter with submit via job?
    Could you please advise?
    Thanks in advance.
    João Gaia

    Here a simple code
    *Submit report as job(i.e. in background)
    data: jobname like tbtcjob-jobname value
                                 'TRANSFER DATA'.
    data: jobcount like tbtcjob-jobcount,
          host like msxxlist-host.
    data: begin of starttime.
            include structure tbtcstrt.
    data: end of starttime.
    data: starttimeimmediate like btch0000-char1 value 'X'.
    * Job open
      call function 'JOB_OPEN'
           exporting
                delanfrep        = ' '
                jobgroup         = ' '
                jobname          = jobname
                sdlstrtdt        = sy-datum
                sdlstrttm        = sy-uzeit
           importing
                jobcount         = jobcount
           exceptions
                cant_create_job  = 01
                invalid_job_data = 02
                jobname_missing  = 03.
      if sy-subrc ne 0.
                                           "error processing
      endif.
    * Insert process into job
    SUBMIT zreport and return
                    with p_param1 = 'value'
                    with p_param2 = 'value'
                    user sy-uname
                    via job jobname
                    number jobcount.
      if sy-subrc > 0.
                                           "error processing
      endif.
    * Close job
      starttime-sdlstrtdt = sy-datum + 1.
      starttime-sdlstrttm = '220000'.
      call function 'JOB_CLOSE'
           exporting
    "            event_id             = starttime-eventid
    "            event_param          = starttime-eventparm
    "            event_periodic       = starttime-periodic
                jobcount             = jobcount
                jobname              = jobname
    "            laststrtdt           = starttime-laststrtdt
    "            laststrttm           = starttime-laststrttm
    "            prddays              = 1
    "            prdhours             = 0
    "            prdmins              = 0
    "            prdmonths            = 0
    "            prdweeks             = 0
    "            sdlstrtdt            = starttime-sdlstrtdt
    "            sdlstrttm            = starttime-sdlstrttm
                strtimmed            = starttimeimmediate
    "            targetsystem         = host
           exceptions
                cant_start_immediate = 01
                invalid_startdate    = 02
                jobname_missing      = 03
                job_close_failed     = 04
                job_nosteps          = 05
                job_notex            = 06
                lock_failed          = 07
                others               = 99.
      if sy-subrc eq 0.
                                           "error processing
      endif.
    Then... for import/export of a variable, you can use Import Memory and Export Memory function.
    Like this:
    REPORT A:
      IF NOT it_dlist_out IS INITIAL.
        EXPORT it_dlist_out TO MEMORY ID 'TEST1234'.
      ELSE.
    * Clearing memory
        FREE MEMORY ID 'TEST1234'.
      ENDIF.
    REPORT B:
    IMPORT it_dlist_out TO lt_dlist_out FROM MEMORY ID 'TEST1234'.
    Edited by: spantaleoni on Jan 11, 2011 3:21 PM
    Edited by: spantaleoni on Jan 11, 2011 3:23 PM

  • 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

  • Importing internal table from diffrent program

    HI experts,
    i have two ALV report zprograms . My requirements is i have to write a report in that report i want to pass input screen parameters to each report and get their final intarnal table without generating ALV. How is it possible.
    my question is i want to call any program and export values of thier screen parameter and get the final internal table as export.
    Pls Help. THanks in advace
    Ajay Kuamr

    Hello Ajay,
    In each of the report you can EXPORT the internal table contents to SAP memory & IMPORT the table contents in the third program.
    You have to use SUBMIT statements for each report & get back the internal table using IMPORT statements.
    For further details explore SDN.
    BR,
    Suhas

  • Export & Import internal table data across the programs

    Hi All,
    I have two different reports,let say ZPRO1 & ZPRO2. I want to export internal table data of ZPRO1  to  ZPRO2 and then I want to do some calculations in ZPRO2 with the imported internal table data(ZPRO1).
    If I use 'SUBMIT' or CALL TRANSACTION syntax ZPRO1 is displaying..but I want to use only internal table data of ZPRO1.
    Pls advise.
    Pranitha.

    Hi,
      Please follow the simple code and try to solve your issue.
    Code in program1
    types: begin of ty_itab,
           matnr type matnr,
           end of ty_itab.
    data: it_itab type table of ty_itab,
          wa_itab type ty_itab,
          it_itab1 type table of ty_itab.
    select matnr from mara into table it_itab.
    export it_itab to shared buffer indx(st) id 'ABC'.
    Code in program2
    types: begin of ty_itab,
           matnr type matnr,
           end of ty_itab.
    data: it_itab type table of ty_itab,
          wa_itab type ty_itab.
    import it_itab from shared buffer indx(st) id 'ABC'.
    loop at it_itab into wa_itab.
    write:/ wa_itab-matnr.
    endloop.
      Please delete shared buffer indx(st) id 'ABC', once we don't need the internal table data.
    Regards
    Dande

  • Passing internal table from one program to other without using IMPORT

    Hi Experts,
    I need to pass an internal table from one program to other. However i cannot use IMPORT/EXPORT due to some reason. Any idea how this can be done?
    Warm regards,
    Harshad.

    hi,
    for passing itab from one program to another u can use
    IN FIRST PROGRAM WRITE ,
    perform pass_data(SECOND_PROGRAM_NAME) using ITAB.
    in both the program declare itab with same structure.
    if u want to do some changes in that itab and if u want it back in first program then write as
    perform pass_data(SECOND_PROGRAM_NAME) using ITAB changing itab.

  • Problem in submiting standard program via job

    Hi Experts ,
       I have developed  programs for creating and posting return lots and payment lots for multiple incoming  files. For this i have submited standard  program of FPB3 and FPB5 transaction .  What happened is ,  if the child program fails due to some reason for one file , it is not coming back to the mother program and as a result other files remain unprocessed . So for this i tried with submiting the child program Via job so that if child program fails , only that job will fail and the mother program will not fail , so rest  files will be processed .
    But the problem is the child program (standard program of FPB3/FPB5 )  is not working by this i.e.  the lots are not getting created adn.
    Awaiting for any respone .

    Hi,
    If you are using Submit via Job, you need to use JOB_OPEN and JOB_CLOSE FM's.
    JOB_OPEN : Create a new job and return you the job number which you use in Submit
    JOB_CLOSE: Will set the release conditions of the job.
    Example:
    DATA: number TYPE tbtcjob-jobcount,
          name TYPE tbtcjob-jobname VALUE 'JOB_TEST',
          print_parameters TYPE pri_params.
    CALL FUNCTION 'JOB_OPEN'
      EXPORTING
        jobname          = name
      IMPORTING
        jobcount         = number
      EXCEPTIONS
        cant_create_job  = 1
        invalid_job_data = 2
        jobname_missing  = 3
        OTHERS           = 4.
    IF sy-subrc = 0.
      SUBMIT submitable TO SAP-SPOOL
                        SPOOL PARAMETERS print_parameters
                        WITHOUT SPOOL DYNPRO
                        VIA JOB name NUMBER number
                        AND RETURN.
      IF sy-subrc = 0.
        CALL FUNCTION 'JOB_CLOSE'
          EXPORTING
            jobcount             = number
            jobname              = name
            strtimmed            = 'X'
          EXCEPTIONS
            cant_start_immediate = 1
            invalid_startdate    = 2
            jobname_missing      = 3
            job_close_failed     = 4
            job_nosteps          = 5
            job_notex            = 6
            lock_failed          = 7
            OTHERS               = 8.
        IF sy-subrc <> 0.
        ENDIF.
      ENDIF.
    ENDIF.
    Regards,
    Jovito

  • Report output list to internal table using submit report

    Hello,
    I have a report that generates the output in the form of an abap list. I want this data in an internal table for further processing. the report internally does not do a export data to memory so i cannot use import later on to get the data.
    i did the following
    SUBMIT <report name> exportING LIST TO MEMORY and return.
    CALL FUNCTION 'LIST_FROM_MEMORY'
      TABLES
        listobject = itab_list
      EXCEPTIONS
        not_found  = 4
        OTHERS     = 8.
    CALL FUNCTION 'LIST_TO_ASCI'
      EXPORTING
        list_index         = -1
      TABLES
        listasci           = ascitab
        listobject         = itab_list
      EXCEPTIONS
        empty_list         = 1
        list_index_invalid = 2
        OTHERS             = 3.
    This returns the data in the ascitab, but the data contains additional unwanted info like lines and hyphens etc. Also the data is in a table with a single column, so pulling out individuals fields is again an issue. Is there a way to get this data into an internal table directly?
    best regards,
    Suraj

    hi suraj
    export the internal table  of report
    DATA: BEGIN OF SR_VBAK ,
          VBELN LIKE VBAK-VBELN,
          END OF SR_VBAK.
    DATA: IR_VBAK LIKE STANDARD TABLE OF SR_VBAK WITH HEADER LINE.
    EXPORT IR_VBAK TO MEMORY ID 'SALES'.
           SUBMIT <program name in which u want internal table records > AND RETURN.
    now import that data in submit program  .
    here u have to creat a internal table with same structure as the internal table from which u r trying to export the data
    DATA: BEGIN OF SR_VBAK,
          VBELN LIKE VBAK-VBELN,
          END OF SR_VBAK.
    DATA : IR_VBAK LIKE STANDARD TABLE OF SR_VBAK WITH HEADER LINE.
    IMPORT IR_VBAK FROM MEMORY ID 'SALES'.
    regards
    ANIL CHAUDHaRY

  • Passing internal table through Submit

    Hi,
    How do i pass an internal table through Submit statement.
    i dnt want to declare a select-options for this purpose.
    Is ther any other way??
    Answers will be rewarded
    Regards,
    Rohan

    Hello Rohan...
    to export a table use the following
    DATA: wa_indx TYPE indx.
      EXPORT tab = itab TO DATABASE indx(xy) FROM wa_indx CLIENT
      SY-MANDT
      ID 'DETAILLIST'.
    to import use this
    imports from database the list sent by the calling program
      IMPORT tab = itab FROM DATABASE indx(xy) TO wa_indx CLIENT sy-mandt
      ID 'DETAILLIST'.
    deletes the data to save wastage of memory
      DELETE FROM DATABASE indx(xy)
        CLIENT sy-mandt
        ID 'DETAILLIST'.

  • Getting the internal table of standard program to my custom program

    Hi All,
    I have a requirement in which i have to get the data from internal table ALV_ITAB from program HKBRO20. As this is the standard program, i have copied this program into Z custom program and using export parameter i am getting the data from internal table ALV_ITAB to my custom program (Using submit of the Z of the standard program). Can any one pls tell me whether the process i am following is correct if not pls tell me how to get the internal table from standard program to our custom program.
    the process i am following
    submit ZHBRO20 and return. IMPORT ALV_ITAB  FROM MEMORY ID 'ABC'.
    copied HBRO20 to ZHBRO20.
    Thanks,
    Raju

    Hi,
    you could also try
    FIELD-SYMBOLS: <fc> .
    CONSTANTS: c_table(21)  VALUE '(PROGRAM_NAME)INTERNAL_TABLENAME[]'.
    ASSIIGN (c_table) TO <fc>.
    Depends on the process, of course.
    Cheers,
    Stefan.

  • JOB_OPEN, SUBMIT REPORT VIA JOB, JOB_CLOSE, How to get result?

    Hi Friends,
    I am calling reports using jobs as calling job_open, submit report via job.., and job_close. But I want to the output/result of the report. How can I do this?
    Thanks.

    Hello nkara,
    Welcome to SDN!!!
    Check this thread:
    background grid
    REgards,
    Vasanth

  • Exporting An message Internal table to Standard program Internal Table

    Hi,
      In T-code VOFM, We have Goods issue routine 113, Now in Custmizing 913 is Configured. we are Checking the status of each handling unit of the Delivery. So I am getting the status Incomeplete Message for Multipe HU's. hence AM storing into One internal Table and Now I want To Export That Internal Table to Standard Program Internal Table 'WAT'.
    If I raise

    Elaborate your questions Please.

  • Importing internal table in Adobe Interactive Forms

    Hi all,
    at the moment I do my first steps in AIF.
    I have created a report and select dd02l, dd03l and dd04l.
    dd02l is a structure. dd03l and dd04l are internal tables.
    How can I import internal tables into my function module with getting a runtime error? Fields and structures are no problem?
    I have defined both internal tables as importing parameter in my form interface because I cannot define internal tables ;o(
    Thx 4 help & regards
    Michael

    hi,
    find attached document it will helpful for u go to link
    1.https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/c2567f2b-0b01-0010-b7b5-977cbf80665d
    2.https://www.sdn.sap.com/irj/sdn/abap-elearning
    thanks reward if helpful

  • Accessing internal table of main program inside function module...

    I have function module say ZFUNC and main program say ZMAIN and internal table defined as IT_TAB inside ZMAIN but not passed as parameter to Function module ZFUNC.
    If I want to access the field value of IT_TAB of  main program ZMAIN inside ZFUNC during debugging then, I simply put <b>(ZMAIN)IT_TAB-amount</b> in ABAP debugger and then change it when the debugger is inside ZFUNC.
    How can I write code to change the value of internal table of main program in function module ZFUNC instead of doing in debugger ? I guess I have to use some field symbols, but not sure. Please suggest.
    Regards,
    Rajesh.

    Yes, you do need to use a field symbol.  Say for example, you had a internal table called IMARC in your program and you want to access it later in a funciton module, you would do something like this.
      data: xmarc type marc.
      field-symbols: <imarc> type marc_upl_tt.
    * Assign an internal table
      field = '(ZPROGRAM_NAME)IMARC[]'.
      assign (field) to <imarc>.
      loop at <imarc> into xmarc.
        write: / xmarc-matnr, xmarc-werks.
      endloop.
    Regards,
    Rich Heilman

  • Regarding Passing two internal Tables from Driver Program to Smartform

    hi all,
              I am Passing Two Internal Tables from Driver Program to Smartform it is going to dump and message is showing like this " one of the parameters eded according to the interface description was not specified ".
              When i am passing one Internal Table Output is coming Perfectly. Is there any restriction for passing of internal tables.
    Regards
    Rami

    HI,
    Check the names specified in the smartfrom and FM whcih you are calling in the driver program. Both might be different....

Maybe you are looking for