IMPORT - conversion_options

Syntax

... { { { {[ACCEPTING PADDING] [ACCEPTING TRUNCATION]}
        | [IGNORING STRUCTURE BOUNDARIES] }
        [IGNORING CONVERSION ERRORS [REPLACEMENT CHARACTER rc]] }
    | [IN CHAR-TO-HEX MODE] }
    [CODEPAGE INTO cp]
    [ENDIAN INTO endian].

Extras:

1. ... ACCEPTING PADDING

2. ... ACCEPTING TRUNCATION

3. ... IGNORING STRUCTURE BOUNDARIES

4. ... IGNORING CONVERSION ERRORS [REPLACEMENT CHARACTER rc]

5. ... IN CHAR-TO-HEX MODE

6. ... CODEPAGE INTO cp

7. ... ENDIAN INTO endian

Effect

These additions allow the importing of data stored in data clusters into non-type-related data objects. They also define appropriate conversion rules. The following table shows which of the additions may be used during import from the various storage buffers. The column headings are abbreviations for the following buffers:
DATA BUFFER (B), MEMORY (M), SHARED MEMORY (SM), SHARED BUFFER (SB), DATA BASE (DB) und INTERNAL TABLE (IT).

Note

With the buffer SHARED BUFFER, the displayed additions are specified only after Release 6.40.

Addition 1

... ACCEPTING PADDING

Effect

This addition enhances the rules from the parameter_list for different data types of source field and target field dobj in the data clusters:

• In addition to data objects of the type c, the target field can be longer than the source field for data objects of the type n, p, or x.
  
  
• Source fields of the type b can be exported into target fields of the types s and i; source fields of the type s can be exported into target fields of the type i.
  
  
• Source fields of the type c can be exported into target fields of the type string; source fields of the type x can be exported into target fields of the type xstring.
  
  
• The following rules also apply if the component concerned is the last component of a source or target structure that is otherwise set up in the same manner
  
  
• In a target structure, substructures can also have more components than the substructures of the source structure if the structure is otherwise set up in the same way. The superfluous components are supplied with type-related initial values.
  
  
  

Note

The rule that substructures in a target structure can have more components than the source structure can cause problems in relation to structures defined in the ABAP Dictionary. This is the case if the structure there is marked as enhanceable. Therefore, as of Release 6.40, this situation triggers a warning message in the enhanced program check.

Example

Without the addition ACCEPTING PADDING, the structure f1 in the data cluster could not be imported into the structure f2 since a substructure of f2 contains a superfluous component.

DATA: BEGIN OF f1,
        col1 TYPE string,
       BEGIN OF sub,
         col2 TYPE f,
       END OF sub,
         col3 TYPE i,
      END OF f1.

DATA: BEGIN OF f2,
        col1 TYPE string,
        BEGIN OF sub,
          col2 TYPE f,
          col3 TYPE xstring,
        END OF sub,
          col4 TYPE i,
      END OF f2.

EXPORT para = f1 TO MEMORY ID 'HK'.

...

IMPORT para = f2 FROM MEMORY ID 'HK' ACCEPTING PADDING.

Addition 2

... ACCEPTING TRUNCATION

Effect

This addition expands the rules in the parameter_list for different data types of source field in the data cluster and source field dobj in the data cluster. The rule expansion is such that if, in the case of structures that otherwise have the same type, the source structure at the hightest level has more components than the target structure in the data cluster, the superflous components will be cut off. A substructure of the source structure must not have more components than the respective sustructure in the target structure.

Example

Without the addition ACCEPTING TRUNCATION, the structure f1 in the data cluster could not be imported into the structure f2 since f2 contains less components.

DATA: BEGIN OF f1,
        col1 TYPE string,
       BEGIN OF sub,
         col2 TYPE f,
       END OF sub,
         col3 TYPE i,
         col4 TYPE xstring,
      END OF f1.

DATA: BEGIN OF f2,
        col1 TYPE string,
        BEGIN OF sub,
          col2 TYPE f,
        END OF sub,
          col3 TYPE i,
      END OF f2.

EXPORT para = f1 TO MEMORY ID 'HK'.

...

IMPORT para = f2 FROM MEMORY ID 'HK' ACCEPTING TRUNCATION.

Addition 3

... IGNORING STRUCTURE BOUNDARIES

Effect

This addition expands the rules from the parameter list for different data types of source field in the data cluster and target field dobj in the data cluster. With structures, a different set-up that results from substructures or from different adopted components of other structures with the statement INCLUDE is of no importance whatsoever.

The components of source and target structure are viewed at the same level - independently of their set-up from substructures or from components adopted using INCLUDE. Source and target structures must both have the same number of components and these must be of the same type. Possible alignment gaps that have resulted from substructures are of no importance whatsoever.

This addition cannot be used together with the additions ACCEPTING PADDING and ACCEPTING TRUNCATION.

Example

Without the addition IGNORING STRUCTURE BOUNDARIES, the structure f1 in the data cluster could not be imported into the structure f2 since f1 and f2 are set up differently from substructures.

DATA: BEGIN OF incl_struc,
        cola TYPE string,
        colb TYPE i,
      END OF incl_struc.

DATA: BEGIN OF f1.
        INCLUDE STRUCTURE incl_struc.

DATA:  col1 TYPE string ,
       BEGIN OF sub,
         col2 TYPE f,
         col3 TYPE f,
       END OF sub,
         col4 TYPE i,
      END OF f1.

DATA: BEGIN OF f2,
        cola TYPE string,
        colb TYPE i,
        col1 TYPE string,
        BEGIN OF sub,
          col2 TYPE f,
        END OF sub,
          col3 TYPE f,
          col4 TYPE i,
      END OF f2.

EXPORT para = f1 TO MEMORY ID 'HK'.

...

IMPORT para = f2 FROM MEMORY ID 'HK'
                 IGNORING STRUCTURE BOUNDARIES.

Addition 4

... IGNORING CONVERSION ERRORS [REPLACEMENT CHARACTER rc]

Effect

Through this addition, an exception of the class CX_SY_CONVERSION_CODEPAGE is suppressed, which is raised when a conversion to another Codepage is carried out at import, and a character to be converted does not exist in the target codepage.

If the addition REPLACEMENT CHARACTER is specified, each inconvertible character will be replaced during conversion with the character that is contained in rc. For rc, a character-type data object is expectedthat contains a single character if the addition is specified,where the character "#" is used as a substitute character.

As of release 6.40, the addition IGNORING CONVERSION ERRORS also suppresses the exception if the number of bytes of an imported character-type component increases during a conversion to another codepage, and therefore does no longer fit into the target object. If you specify the addition, superfluous characters are truncated on the right. Without specifying the addition, only superfluous blanks are truncated on the right without raising an exception.

Addition 5

... IN CHAR-TO-HEX MODE

Effect

This addition has the effect that data that is stored in the data cluster under the data type x is assigned to target fields of the type x. The contents of the source fields are not converted to the code page of the target system. Instead, they are placed byte by byte and unconverted into the target fields. A single source field or a structure component of the type c can be assigned to a single target field or to a structure component of the type x, which has the same length in bytes. For target fields of the type c, the addition has no effect.

This addition cannot be used together with the previous conversion additions.

Note

With this addition, you should note that a program that uses this addition cannot be transported between systems in which character representation requires different numbers of bytes. This addition is only meant for temporary programs in order to be able to import byte strings that were stored incorrectly in fields of the type c and to be able to store them again for the correct type.

Addition 6

... CODEPAGE INTO cp

Effect

This addition assigns the identification of the code page for the exported data to the data object cp. This object must have a character-type data type. The identification of the code page is the content of the column CPCODEPAGE of the database table TCP00.

Note

The code page can be used in order to process data objects imported using CHAR-TO-HEX MODE. Conversions between code pages can be made using system classes in the section Classes for Conversion of External Data Formats.

Addition 7

... ENDIAN INTO endian

Effect

This addition assigns the identification of the byte sequence of the exported data to the data object ENDIAN, which must have the data type ABAP_ENDIAN from the type group ABAP. The identification for Big Endian is "B"; the identification for Little Endian is "L".

Note

The byte sequence can be used in order to process data objects imported using CHAR-TO-HEX MODE since code pages in which a character takes up more than one byte can be dependent on the byte sequence.

Example

The target field f2-col2 contains, after the import, the unconverted, binary content of f1-col2. The code page and the byte sequence in which the data is stored is available in cp and en. Normally, the data in such a case is exported and imported in another program. You should note that this example only works in a system in which a character is displayed through two bytes since f2-col2 is double the length of f1-col2.

TYPE-POOLS abap.

DATA: BEGIN OF f1,
        col1 TYPE c LENGTH 10 VALUE '1234567890',
        col2 TYPE c LENGTH 10 VALUE '1234567890',
      END OF f1.

DATA: BEGIN OF f2,
        col1(10) TYPE c,
        col2(20) TYPE x,
      END OF f2.

DATA: cp TYPE string,
      en TYPE abap_endian.

EXPORT para = f1 TO DATABASE indx(hk) ID 'HK'.

...

IMPORT para = f2 FROM DATABASE indx(hk) ID 'HK'
                 IN CHAR-TO-HEX MODE
                 CODE PAGE INTO cp
                 ENDIAN INTO en.