Internal table types
hi all,
whn we are going to use standard , sorted and harshed table...
wht are the examples for the same..
regards
suprith
Standard Internal Tables
Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.
This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to
the number of table entries.
Sorted Internal Tables
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique, or non-unique, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of
table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.
Hashed Internal Tables
Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.
This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.
Index Tables
Index table is only used to specify the type of generic parameters in a FORM or FUNCTION. That means that you can't create a table of type INDEX.
Internal tables are not DB tables. Standard and Sorted tables in combined are basically called as Index tables and there nothing else. Here is the hierarchy
ANY TABLE
|
| |
Index Tables Hashed Table
|
| |
Standard Table Sorted Table
Similar Messages
-
Internal Table Types (Standard, Sorted, Hashed)
Hi all,
I wonder about using internal table types. I always work with standard table type. I don't know when i have to use the standard, sorted or hashed itab type. Is there limits for line counts of types, like over 200.000 lines use hashed table type etc. ? I need performance improvements for itabs.
Thx,the terminology of internal tables is unfortunately quite confusing:
internal tables use 'index' for the row number of the line in the table, if you know then you can access it directly. It is actually the sy-tabix variable which you have to know.
Things which are called index on the database are called keys, i.e. the sorted primary key of a SORTED table or the hashed primary key of a HASHED table (the technical realization is actually called index).
With the newest basis release (7.02 or 7.20) there are also secondary keys possible on internal tables, for all 3 types.
Siegfried -
Senarious for using different internal table types
please give scenarios for using different internal table types?
Refer to the following.
Internal table types
This section describes how to define internal tables locally in a program. You can also define internal tables globally as data types in the ABAP Dictionary.
Like all local data types in programs , you define internal tables using the TYPES statement. If you do not refer to an existing table type using the TYPE or LIKE addition, you can use the TYPES statement to construct a new local internal table in your program.
TYPES <t> TYPE|LIKE <tabkind> OF <linetype> [WITH <key>]
[INITIAL SIZE <n>].
After TYPE or LIKE, there is no reference to an existing data type. Instead, the type constructor occurs:
<tabkind> OF <linetype> [WITH <key>]
The type constructor defines the table type <tabkind>, the line type <linetype>, and the key <key> of the internal table <t>.
You can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
Table type
You can specify the table type <tabkind> as follows:
Generic table types
INDEX TABLE
For creating a generic table type with index access.
ANY TABLE
For creating a fully-generic table type.
Data types defined using generic types can currently only be used for field symbols and for interface parameters in procedures . The generic type INDEX TABLE includes standard tables and sorted tables. These are the two table types for which index access is allowed. You cannot pass hashed tables to field symbols or interface parameters defined in this way. The generic type ANY TABLE can represent any table. You can pass tables of all three types to field symbols and interface parameters defined in this way. However, these field symbols and parameters will then only allow operations that are possible for all tables, that is, index operations are not allowed.
Fully-Specified Table Types
STANDARD TABLE or TABLE
For creating standard tables.
SORTED TABLE
For creating sorted tables.
HASHED TABLE
For creating hashed tables.
Fully-specified table types determine how the system will access the entries in the table in key operations. It uses a linear search for standard tables, a binary search for sorted tables, and a search using a hash algorithm for hashed tables.
Line type
For the line type <linetype>, you can specify:
Any data type if you are using the TYPE addition. This can be a predefined ABAP type, a local type in the program, or a data type from the ABAP Dictionary. If you specify any of the generic elementary types C, N, P, or X, any attributes that you fail to specify (field length, number of decimal places) are automatically filled with the default values. You cannot specify any other generic types.
Any data object recognized within the program at that point if you are using the LIKE addition. The line type adopts the fully-specified data type of the data object to which you refer. Except for within classes, you can still use the LIKE addition to refer to database tables and structures in the ABAP Dictionary (for compatibility reasons).
All of the lines in the internal table have the fully-specified technical attributes of the specified data type.
Key
You can specify the key <key> of an internal table as follows:
[UNIQUE|NON-UNIQUE] KEY <col1> ... <col n>
In tables with a structured line type, all of the components <coli> belong to the key as long as they are not internal tables or references, and do not contain internal tables or references. Key fields can be nested structures. The substructures are expanded component by component when you access the table using the key. The system follows the sequence of the key fields.
[UNIQUE|NON-UNIQUE] KEY TABLE LINE
If a table has an elementary line type (C, D, F, I, N, P, T, X), you can define the entire line as the key. If you try this for a table whose line type is itself a table, a syntax error occurs. If a table has a structured line type, it is possible to specify the entire line as the key. However, you should remember that this is often not suitable.
[UNIQUE|NON-UNIQUE] DEFAULT KEY
This declares the fields of the default key as the key fields. If the table has a structured line type, the default key contains all non-numeric columns of the internal table that are not and do not contain references or internal tables. If the table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
Specifying a key is optional. If you do not specify a key, the system defines a table type with an arbitrary key. You can only use this to define the types of field symbols and the interface parameters of procedures . For exceptions, refer to Special Features of Standard Tables.
The optional additions UNIQUE or NON-UNIQUE determine whether the key is to be unique or non-unique, that is, whether the table can accept duplicate entries. If you do not specify UNIQUE or NON-UNIQUE for the key, the table type is generic in this respect. As such, it can only be used for specifying types. When you specify the table type simultaneously, you must note the following restrictions:
You cannot use the UNIQUE addition for standard tables. The system always generates the NON-UNIQUE addition automatically.
You must always specify the UNIQUE option when you create a hashed table.
Initial Memory Requirement
You can specify the initial amount of main memory assigned to an internal table object when you define the data type using the following addition:
INITIAL SIZE <n>
This size does not belong to the data type of the internal table, and does not affect the type check. You can use the above addition to reserve memory space for <n> table lines when you declare the table object.
When this initial area is full, the system makes twice as much extra space available up to a limit of 8KB. Further memory areas of 12KB each are then allocated.
You can usually leave it to the system to work out the initial memory requirement. The first time you fill the table, little memory is used. The space occupied, depending on the line width, is 16 <= <n> <= 100.
It only makes sense to specify a concrete value of <n> if you can specify a precise number of table entries when you create the table and need to allocate exactly that amount of memory (exception: Appending table lines to ranked lists). This can be particularly important for deep-structured internal tables where the inner table only has a few entries (less than 5, for example).
To avoid excessive requests for memory, large values of <n> are treated as follows: The largest possible value of <n> is 8KB divided by the length of the line. If you specify a larger value of <n>, the system calculates a new value so that n times the line width is around 12KB.
Examples
TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.
TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
The program defines a table type ITAB. It is a sorted table, with line type of the structure LINE and a unique key of the component COLUMN1.
TYPES VECTOR TYPE HASHED TABLE OF I WITH UNIQUE KEY TABLE LINE.
TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.
TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
TYPES: BEGIN OF DEEPLINE,
FIELD TYPE C,
TABLE1 TYPE VECTOR,
TABLE2 TYPE ITAB,
END OF DEEPLINE.
TYPES DEEPTABLE TYPE STANDARD TABLE OF DEEPLINE
WITH DEFAULT KEY.
The program defines a table type VECTOR with type hashed table, the elementary line type I and a unique key of the entire table line. The second table type is the same as in the previous example. The structure DEEPLINE contains the internal table as a component. The table type DEEPTABLE has the line type DEEPLINE. Therefore, the elements of this internal table are themselves internal tables. The key is the default key - in this case the column FIELD. The key is non-unique, since the table is a standard table.
http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb35de358411d1829f0000e829fbfe/content.htm -
Getting dynamically the internal table type
Hello all,
is there a standard function to get the internal table type name.like if a internal table is based on sflight,by using the function i pass the internal table and get the type sflight.
regards
kaushikfor this we have the CL_ABAP_TYPEDESCR class, subclasses and all of their methods.
Coding should look something like this:
DATA: dref TYPE REF TO data.
FIELD-SYMBOLS: <table> TYPE STANDARD TABLE,
<line> TYPE ANY.
DATA: lr_reference TYPE REF TO cl_abap_typedescr.
DATA: lr_tab TYPE REF TO cl_abap_tabledescr.
DATA: lr_data TYPE REF TO cl_abap_datadescr.
PARAMETERS: pa_tab TYPE tabname DEFAULT 'BUT000'.
CREATE DATA dref TYPE STANDARD TABLE OF (pa_tab).
ASSIGN dref->* TO <table>.
SELECT * FROM but000 INTO TABLE <table>
UP TO 10 ROWS.
CALL METHOD cl_abap_typedescr=>describe_by_data
EXPORTING
p_data = <table>
RECEIVING
p_descr_ref = lr_reference.
lr_tab ?= lr_reference.
lr_data = lr_tab->get_table_line_type( ).
WRITE lr_data->absolute_name.
Edited by: Micky Oestreich on Jan 19, 2009 8:09 AM
Edited by: Micky Oestreich on Jan 19, 2009 8:44 AM -
[internal tables] TYPES or DATA
Hi,
starting with ABAP and try to understand internal tables. The structure
of an internal table isn't quiet clear. They have a work area and a table body,
but why do I need a additionally type of line?
Is this content, my tutorial uses DATA to define the itab and TYPES to define
the workarea (type of line). I don't really understand the different between those
commands.
Does anyone got a good web blog to understand internal tables completly?
thx
chrisHi,
The Statements TYPES and DATA
Each ABAP program define its own data types using the statement.
TYPES dtype TYPE type ...
and declare its own variables or instance attributes of classes using the statement
DATA var {TYPE type} ...
Within the program or a class, you can also define local data types and variables within procedures. Local variables in procedures obscure identically-named variables in the main program or class.
When creating data types and data objects, there are a number of naming convention that also apply for other local program definitions, such as procedures. These are described in detail in the keyword documentation.
The Additions TYPE and LIKE
The additions TYPE type and LIKE dobj are used in various ABAP statements. The additions can have various meanings, depending on the syntax and context.
· Definition of local types in a program
· Declaration of data objects
· Dynamic creation of data objects
· Specification of the type of formal parameters in subroutines
· Specification of the type of formal parameters in methods
· Specification of the type of field symbols
Constructing New Data Types
The TYPE addition allows you to construct new data types in the TYPES, DATA; CONSTANTS; and STATICSstatements. In the TYPES statement, these are local data types in the program. In the other statements, they are attributes of new data objects, meaning that the newly defined data types are not free-standing. Rather, they are linked to database objects.This means that you can refer to them using the LIKEaddition, but not using TYPE.
To construct new data types, the addition TYPE can be used with the following type constructors:
· Construction of reference types
REF TO type|dobj
· Construction of structured data types
BEGIN OF struc_type.
END OF struc_type.
· Construction of table types
tabkind OF linetype
These data types only exist during the runtime of the ABAP program.
Referring to Known Data Types or Data Objects
Using the additions TYPE or LIKE in the TYPESstatement, local data types in a program can be referred to known data types or data objects. This is mainly the case with user-defined elementary data types. If you declare variables using the additions TYPE type or LIKE dobj with statement DATA, the data type of var is already fully defined before the declaration is made.
The known types or data that are referred to must be visible at the point where the data type or variable is declared.
A known data type can be any of the following:
· A predefined ABAP type to which you refer using the TYPE addition
· An existing local data type in the program to which you refer using the TYPE addition
· The data type of a local data object in the program to which you refer using the LIKE addition
· A data type in the ABAP Dictionary to which you refer using the TYPE addition. To ensure compatibility with earlier releases, it is still possible to use the LIKE addition to refer to database tables and flat structures in the ABAP Dictionary. However, you should use the TYPE addition in new programs.
The LIKE addition takes its technical attributes from a visible data object. As a rule, you can use LIKE to refer to any object that has been declared using DATA or a similar statement, and is visible in the current context. The data object only has to have been declared. It is irrelevant whether the data object already exists in memory when you make the LIKE reference.
· In principle, the local data objects in the same program are visible. As with local data types, there is a difference between local data objects in procedures and global data objects. Data objects defined in a procedure obscure other objects with the same name that are declared in the global declarations of the program.
· You can also refer to the data objects of other visible ABAP programs. These might be, for example, the visible attributes of global classes in class pools. If a global class cl_lobal has a public instance attribute or static attribute attr, you can refer to it as follows in any ABAP program:
DATA dref TYPE REF TO cl_global.
DATA: f1 LIKE cl_global=>attr,
f2 LIKE dref->attr.
You can access the technical properties of an instance attribute using the class name and a reference variable without first having to create an object. The properties of the attributes of a class are not instance-specific and belong to the static properties of the class.
TYPES: BEGIN OF struct,
number_1 TYPE i,
number_2 TYPE p DECIMALS 2,
END OF struct.
DATA: wa_struct TYPE struct,
number LIKE wa_struct-number_2,
date LIKE sy-datum,
time TYPE t,
text TYPE string,
company TYPE s_carr_id.
This example declares variables with reference to the internal type STRUCT in the program, a component of an existing data object wa_struct, the predefined data object SY-DATUM, the predefined ABAP type t and STRING, and the data element S_CARR_ID from the ABAP Dictionary.
Referring to Generic Data Types
If you refer to one of the generic predefined ABAP types of fixed length (c, n, p, x) in the TYPES or DATA statement, you must specify the undefined technical attributes.
TYPES|DATA var[(length)] TYPE type ...
TYPES|DATA var TYPE type ...
DATA: text1,
text2 LENGTH 2,
text3 TYPE c LENGTH 3,
pack TYPE p DECIMALS 2 VALUE '1.225'.
This example creates three character variables with field lengths of one, two, and three bytes respectively, and a packed number variable with field length 8 bytes and two decimal places. If the attribute Fixed point arithmetic is set, the value of pack is 1.23.
This example shows how to declare elementary data objects with reference to predefined ABAP types.
PROGRAM demo_elementary_data_objects.
DATA text1 TYPE c LENGTH 20.
DATA text2 TYPE string.
DATA number TYPE i.
text1 = 'The number'.
number = 100.
text2 = 'is an integer.'.
WRITE: text1, number, text2.
This program produces the following output on the screen:
The number 100 is an integer.
In this example, the data objects text1, text2 and number are declared with the DATA statement. The technical attributes are determined by referring to the predefined ABAP types c, string, and I. Values from unnamed literals are assigned to the data objects. The contents of the named data objects are displayed on the list.
Specifying a Start Value
When you declare an elementary fixed-length variable, the DATAstatement automatically fills it with the type-specific initial value as listed in the table in the Predefined ABAP Types section.
However, you can also specify a starting value of a fixed-length elementary variable (also within a structure declaration) using the VALUE addition in the DATAstatement:
DATA var ... VALUE val|{IS INITIAL}.
Specifying start values:
DATA: counter TYPE p VALUE 1,
date TYPE d VALUE '19980601',
flag TYPE n VALUE IS INITIAL.
After this data declaration, the character string flag contains its type specific
Initial value 0.
Regarsd -
How to get the Data type of the Internal Table.
How can i get the data types used to create an internal table
TYPES : BEGIN OF t_makt,
matnr TYPE matnr,
maktx TYPE maktx,
END OF t_makt.
Like this some function will give me which data types i have used for the internal table at run time.Use the FM ..
data : int_fcat type SLIS_T_FIELDCAT_ALV.
REUSE_ALV_FIELDCATALOG_MERGE ..
CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
EXPORTING
I_PROGRAM_NAME = sy-repid
I_INTERNAL_TABNAME = 'IMAT' <-- this is your internal table
I_INCLNAME = sy-repid
CHANGING
CT_FIELDCAT = int_fcat <--- this contains all the fields along with their characteristics ...
EXCEPTIONS
INCONSISTENT_INTERFACE = 1
PROGRAM_ERROR = 2
OTHERS = 3. -
Transfer an internal table with non char data type to an application server
Here is a part of my code. lv_string variable was type string initially but i got an error Not mutually convertible in a Unicode Program. I changed it to type ty_afko. Now the program works but the data it puts out has just a bunch of #####. I cannot make all value in the internal table type char because then my select statement is giving errors.. Please help...
Type: BEGIN OF ty_afko,
rsnum LIKE afko-rsnum, " Number of reservation
aprio LIKE afko-aprio, " Order Priority
maufnr LIKE afko-maufnr, " Number of superior order
lead_aufnr LIKE afko-lead_aufnr, " Leading order in current processing
END OF ty_afko.
data: gt_afko TYPE STANDARD TABLE OF ty_afko INITIAL SIZE 0,
wa_afko TYPE ty_afko,
select rsnum aprio maufnr lead_aufnr
from afko into table gt_afko.
IF gv_error = 'X'.
EXIT.
ELSE.
<b>DATA: Lv_string type ty_afko.</b>
loop at gt_afko into wa_afko.
clear lv_string.
<b> move wa_afko to lv_string.</b>
perform f_transfer_dataset using gc_f_afko lv_string changing gv_error.
endloop.
endif.
FORM f_transfer_dataset USING p_file
p_data
CHANGING p_error TYPE c.
Data: lv_file(25) type c.
CONCATENATE gc_path p_file INTO lv_file.
TRANSFER p_data TO lv_file.
ENDFORM. "F_TRANSFER_DATASETThe key is to create another empty structure with fields of type c.
TYPES: BEGIN OF ty_resb,
bdter TYPE RESB-BDTER, " This field is type d
bdmng type resb-bdmng, " This field is type p with 3 decimals - total 14
END OF ty_resb,
BEGIN OF ty_resbstr, " This structure is the same as above but the field types will be char.
bdter(10),
bdmng(14),
END OF ty_resbstr.
DATA: gt_resb TYPE STANDARD TABLE OF ty_resb,
wa_resb TYPE ty_resb,
structure type ty_resbstr. " Empty fields with the same structure as the work area.
SELECT bdter bdmng FROM resb INTO corresponding fields of TABLE gt_resb.
open dataset pfile for output in text mode encoding default.
loop at gt_resb into wa_resb.
clear gv_string.
move-corresponding wa_resb to gv_string.
perform f_transfer_dataset using gc_f_resb gv_string.
endloop.
FORM f_transfer_dataset USING p_file p_data.
TRANSFER p_data TO lv_file.
ENDFORM. -
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 -
Short dump while reading a currency field from Flat file into internal tabl
Hi,
I am getting a short dump........saying number conversion dump (while reading a currency value into field in internal table from a fixed lenght flat file).........
Do I need to use a string variable to get the value from flat file or how ??
Please suggest.Santosh,
Thanks for your inputs,
But my internal table type is of DEC (5,2) , I am getting that... it needs to be of type 'C'. Can you suggest.
Ex :
MOVE wa_temp-infile_string+106(8) TO wa_item-QT_PERCENT
This didnt work
so i tried moving into a seperate variable
MOVE wa_temp-infile_string+106(8) TO v_percent.
and then write to
WRITE v_percent to wa_item-QT_PERCENT. -
Hi Friends,
See the followong code which converts xml data into itab.
*& Report ZTEST_XML1 *
REPORT ZTEST_XML1 .
*PURPOSE: This program transfers XML data into SAP internal table format
*The nodes in DOM can be stored as fields in SAP Internal table
type pool definitions
TYPE-POOLS: ixml. "iXML Library Types
type definitions
TYPES: BEGIN OF t_xml_line, "Structure for holding XML data
data(256) TYPE x,
END OF t_xml_line.
DATA: l_ixml TYPE REF TO if_ixml,
l_streamfactory TYPE REF TO if_ixml_stream_factory,
l_parser TYPE REF TO if_ixml_parser,
l_istream TYPE REF TO if_ixml_istream,
l_document TYPE REF TO if_ixml_document,
l_node TYPE REF TO if_ixml_node,
l_xmldata TYPE string.
DATA: l_elem TYPE REF TO if_ixml_element,
l_root_node TYPE REF TO if_ixml_node,
l_next_node TYPE REF TO if_ixml_node,
l_name TYPE string,
l_iterator TYPE REF TO if_ixml_node_iterator.
DATA: l_xml_table TYPE TABLE OF t_xml_line, " XML Table of the structure
*t_xml_line
l_xml_line TYPE t_xml_line, " Record of structure t_xml_line
l_xml_table_size TYPE i. " XML table size
DATA: l_filename TYPE string. " String to hold filename
data: begin of i_final occurs 0,
pnumber(20),
pname(50),
pdes(70),
end of i_final.
PARAMETERS: pa_file TYPE char1024 DEFAULT 'C:\product.xml'.
Validation of XML file: Only DTD included in XML document is supported
PARAMETERS: pa_val TYPE char1 AS CHECKBOX.
start of selection
START-OF-SELECTION.
Creating the main iXML factory
l_ixml = cl_ixml=>create( ).
Creating a stream factory
l_streamfactory = l_ixml->create_stream_factory( ).
PERFORM get_xml_table CHANGING l_xml_table_size l_xml_table.
Wrap the table containing the file into a stream.
l_istream = l_streamfactory->create_istream_itable( table = l_xml_table
size = l_xml_table_size ).
Creating a document
l_document = l_ixml->create_document( ).
Creating a Parser
l_parser = l_ixml->create_parser( stream_factory = l_streamfactory
istream = l_istream
document = l_document ).
Validate a document
IF pa_val = 'X'.
l_parser->set_validating( mode = if_ixml_parser=>co_validate ).
ENDIF.
Parse the stream
IF l_parser->parse( ) <> 0.
IF l_parser->num_errors( ) <> 0.
DATA: parseerror TYPE REF TO if_ixml_parse_error,
str TYPE string,
i TYPE i,
count TYPE i,
index TYPE i.
count = l_parser->num_errors( ).
WRITE: count, ' parse errors have occured:'.
index = 0.
WHILE index < count.
parseerror = l_parser->get_error( index = index ).
i = parseerror->get_line( ).
WRITE: 'line: ', i.
i = parseerror->get_column( ).
WRITE: 'column: ', i.
str = parseerror->get_reason( ).
WRITE: str.
index = index + 1.
ENDWHILE.
ENDIF.
ENDIF.
Process the document
IF l_parser->is_dom_generating( ) EQ 'X'.
PERFORM process_dom USING l_document.
ENDIF.
*& Form get_xml_table
text
<--P_L_XML_TABLE_SIZE text
<--P_L_XML_TABLE text
FORM get_xml_table CHANGING p_l_xml_table_size
p_l_xml_table.
Local variable declarations
DATA: l_len TYPE i,
l_len2 TYPE i,
l_tab TYPE tsfixml,
l_content TYPE string,
l_str1 TYPE string,
c_conv TYPE REF TO cl_abap_conv_in_ce,
l_itab TYPE TABLE OF string.
l_filename = pa_file.
Upload file from the client's workstation
CALL METHOD cl_gui_frontend_services=>gui_upload
EXPORTING
filename = l_filename
filetype = 'BIN'
IMPORTING
filelength = l_xml_table_size
CHANGING
data_tab = l_xml_table
EXCEPTIONS
OTHERS = 19.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
Writing the XML document to the screen
CLEAR l_str1.
LOOP AT l_xml_table INTO l_xml_line.
c_conv = cl_abap_conv_in_ce=>create( input = l_xml_line-data replacement
= space ).
c_conv->read( IMPORTING data = l_content len = l_len ).
CONCATENATE l_str1 l_content INTO l_str1.
ENDLOOP.
l_str1 = l_str1+0(l_xml_table_size).
SPLIT l_str1 AT cl_abap_char_utilities=>cr_lf INTO TABLE l_itab.
WRITE: /.
WRITE: /' XML File'.
WRITE: /.
LOOP AT l_itab INTO l_str1.
REPLACE ALL OCCURRENCES OF cl_abap_char_utilities=>horizontal_tab IN
l_str1 WITH space.
WRITE: / l_str1.
ENDLOOP.
WRITE: /.
ENDFORM. " get_xml_table
*& Form process_dom
text
-->P_L_DOCUMENT text
FORM process_dom USING document TYPE REF TO if_ixml_document.
DATA: node TYPE REF TO if_ixml_node,
iterator TYPE REF TO if_ixml_node_iterator,
nodemap TYPE REF TO if_ixml_named_node_map,
attr TYPE REF TO if_ixml_node,
name TYPE string,
prefix TYPE string,
value TYPE string,
indent TYPE i,
count TYPE i,
index TYPE i.
node ?= document.
CHECK NOT node IS INITIAL.
ULINE.
WRITE:/.
WRITE: /' DOM-TREE'.
WRITE: /.
IF node IS INITIAL.
EXIT.
ENDIF.
Create a node iterator
iterator = node->create_iterator( ).
Get current node
node = iterator->get_next( ).
Loop over all nodes
WHILE NOT node IS INITIAL.
indent = node->get_height( ) * 2.
indent = indent + 20.
CASE node->get_type( ).
WHEN if_ixml_node=>co_node_element.
element node
name = node->get_name( ).
nodemap = node->get_attributes( ).
WRITE: / 'ELEMENT :'.
WRITE: AT indent name COLOR COL_POSITIVE INVERSE.
IF NOT nodemap IS INITIAL.
attributes
count = nodemap->get_length( ).
DO count TIMES.
index = sy-index - 1.
attr = nodemap->get_item( index ).
name = attr->get_name( ).
prefix = attr->get_namespace_prefix( ).
value = attr->get_value( ).
WRITE: / 'ATTRIBUTE:'.
WRITE: AT indent name COLOR COL_HEADING INVERSE, '=',
value COLOR COL_TOTAL INVERSE.
ENDDO.
ENDIF.
WHEN if_ixml_node=>co_node_text OR
if_ixml_node=>co_node_cdata_section.
text node
value = node->get_value( ).
WRITE: / 'VALUE :'.
WRITE: AT indent value COLOR COL_GROUP INVERSE.
ENDCASE.
Advance to next node
node = iterator->get_next( ).
ENDWHILE.
*delete adjacent duplicates from i_final.
*loop at i_final.
*write:/ i_final-pnumber,i_final-pname,i_final-pdes.
*endloop.
*if not i_final[] is initial.
*modify ztestproduct from table i_final.
*endif.
ENDFORM. " process_dom
in the above code at line no: 268 there is a method:
value = node->get_value( ).in which actual data from XML file is coming.
So the varibale "Value" contains the data.
see line no: 270:
WRITE: AT indent value COLOR COL_GROUP INVERSE.
what ever values i am getting here i want to append to a Internal table ...
Can any body tell me how to do that?
i am sure of reward points.Hai Ravi
REPORT abc.
DATA
DATA : t001 LIKE TABLE OF t001 WITH HEADER LINE.
DATA : BEGIN OF itab OCCURS 0,
a(100) TYPE c,
END OF itab.
DATA: xml_out TYPE string .
DATA : BEGIN OF upl OCCURS 0,
f(255) TYPE c,
END OF upl.
DATA: xmlupl TYPE string .
FIRST PHASE
FIRST PHASE
FIRST PHASE
Fetch Data
SELECT * FROM t001 INTO TABLE t001.
XML
CALL TRANSFORMATION ('ID')
SOURCE tab = t001[]
RESULT XML xml_out.
Convert to TABLE
CALL FUNCTION 'HR_EFI_CONVERT_STRING_TO_TABLE'
EXPORTING
i_string = xml_out
i_tabline_length = 100
TABLES
et_table = itab.
Download
CALL FUNCTION 'GUI_DOWNLOAD'
EXPORTING
filetype = 'BIN'
filename = 'd:\xx.xml'
TABLES
data_tab = itab.
SECOND PHASE
SECOND PHASE
SECOND PHASE
BREAK-POINT.
REFRESH t001.
CLEAR t001.
CALL FUNCTION 'GUI_UPLOAD'
EXPORTING
filename = 'D:\XX.XML'
filetype = 'BIN'
TABLES
data_tab = upl.
LOOP AT upl.
CONCATENATE xmlupl upl-f INTO xmlupl.
ENDLOOP.
XML
CALL TRANSFORMATION ('ID')
SOURCE XML xmlupl
RESULT tab = t001[].
Regards
Sreeni -
Error while uploading a textfile into internal table.
Hello,
i am uploading a textfile into an internal table and i have used the 'CALL METHOD cl_gui_frontend_services=>gui_upload' for uploading of the file into the internal table. But instead i am getting sumthing lyke
CTTL#1001#BANK-0014393-PP-LHR#|#2000#112312#CCL00#29.08.2006#|Cash In </b>. I have the following internal table,
[code]
begin of ls_cashrec,
bukrs type char30, " company code
cjnr type char30, " cash journal number
cjtranstxt type char30, " business transaction
cjamount type wrbtr, " amount
dzuonr type char30, " assignment
prctr type char6, " profit center
budat type sy-datum, " posting date
cjpostext type char30, " text
end of ls_cashrec.
and
DATA:
gt_cashrec TYPE STANDARD TABLE OF ls_cashrec.
where am i wrong ?
Regard and Thanks,
ShehryarHi again,
1. The best thing is that the
data format in text file is
YYYYMMDD (8 characters only)
(Then in that case, we can directly
declare our field in internal table type sy-datum.
2. Other wise,
we have to declare the field in internal table
as character format and length
(based upon the text file field length,
including DOTS / etc)
Then we have to finally convert in YYYYMMDD
format in to other field,
which we will finally use as sy-datum field.
regards,
amit m. -
XML and XSD file to an internal table
I had read a lot of thread but i don't understand how to deal with xml/xsd in R3.
I need someone that have a definite example for this escenary please.
With OPEN DATASET took from the server XML and XSD file, and put it in two internal tables type string.
What functions or method have to use, and how to use them, to charge the XML file in an internal table?
This is an example of XML and XDS:
XML
AND CONTINUE
Best Regards,I just tried to interpret your question, it was not obvious what you wanted.
I guess what you mean is that you have defined (statically) a deep structure, and you want to decode the XML into it. That is called a transformation (transaction STRANS, statement CALL TRANSFORMATION). You have the choice between 2 transformation languages: XSLT and ST. Of course, it depends what release you are running.
I advise you to play first with the ID transformation, to convert an ABAP deep structured data object into XML, so that you see what XML is generated, this one is called asXML. If you create your own transformation, when you call it, it will first convert automatically the data object to asXML, and the transformation has to do the rest of the job.
You can do the opposite, i.e. converting from XML to a data object, according to the same principle (intermediate asXML).
Well, there are lots of things to say, I recommend you to read articles and documentation on XSLT and ST (search on SDN).
About XSD, it won't help (and I did never see any possibility to use it) to decode the XML, as you must anyway define the target data object statically (and there's no tool to generate the ABAP code of the data object definition from the XSD).
Note that you may also use iXML libraries to parse the XML.
Please tell us more.
BR
Sandra -
How 2 create dynamic internal table and can we pass it to gui_download FM
HI all,
How can we create a dynamic internal table?
I have a requirement where i have to create an internal table with the no. of fields depending on the selection screen values, i think tat can be possible though dynamic creation only.
How to solve this issue..?Pointers will be very much useful..
Thanks
Sunny.hi
Follow the code it will help you out....
REPORT YUSMM_TEXT2 .
*TABLES
TABLES: MARA, " General Material Data
MAKT, " Material Descriptions
T002. " Language Keys
* GLOBAL TYPE-POOL
TYPE-POOLS : SLIS.
* GLOBAL TYPES
TYPES: BEGIN OF TP_LANG ,
SPRAS LIKE T002-SPRAS,
LAISO LIKE T002-LAISO,
SRNO(3) TYPE N,
END OF TP_LANG.
TYPES: BEGIN OF TP_MATNR,
MATNR LIKE MARA-MATNR,
BEGRU LIKE MARA-BEGRU,
END OF TP_MATNR.
* DECLARATION FOR GLOBAL INTERNAL TABLES (WITH INCLUDE STRUCTURE)
DATA:GT_MAKT TYPE STANDARD TABLE OF MAKT, "Materialkurztexte,
GT_THEAD TYPE STANDARD TABLE OF THEAD, "SAPscript: Text-Header,
GT_LINETAB TYPE STANDARD TABLE OF TLINE, "SAPscript: Text-Zeilen,
GT_T002 TYPE STANDARD TABLE OF T002. "Language key
DATA: BEGIN OF GV_TEXT_OUTPUT_LINE,
MATNR LIKE MARA-MATNR,
BEGRU LIKE MARA-BEGRU,
MAKTX LIKE MAKT-MAKTX,
LTXT40(1250) TYPE C,
SRNO(3) TYPE N,
SPRAS LIKE T002-SPRAS,
END OF GV_TEXT_OUTPUT_LINE.
DATA: GT_MATNR TYPE STANDARD TABLE OF TP_MATNR,
WA_GT_MATNR TYPE TP_MATNR.
DATA: GT_LANG TYPE STANDARD TABLE OF TP_LANG,
WA_GT_LANG TYPE TP_LANG.
DATA: GT_TEXT_OUTPUT_LINE LIKE STANDARD TABLE OF GV_TEXT_OUTPUT_LINE,
GT_FIELDCAT TYPE SLIS_T_FIELDCAT_ALV,
GV_FIELDCAT LIKE LINE OF GT_FIELDCAT,
CT_GT_FIELDCAT_IN LIKE GV_FIELDCAT,
GS_LAYOUT TYPE SLIS_LAYOUT_ALV,
GV_REPID TYPE SY-REPID.
DATA: BEGIN OF GV,
FORMER_ERROR LIKE SY-MARKY, " Fehlermeldung bereits
FILE_OPEN(1), " Flag open file
REC_LENGTH TYPE I, " record length
MATNR TYPE MARA-MATNR, " material
REPID TYPE SYST-REPID,
RETCO TYPE SY-SUBRC,
END OF GV.
DATA: GV_MAKT TYPE MAKT,
GV_T002 TYPE T002,
GV_LANGU TYPE THEAD-TDSPRAS.
* DECLARATION FOR FIELD-SYMBOLS
FIELD-SYMBOLS: <FS_DATA> TYPE REF TO DATA,
<FS_DATA1> TYPE REF TO DATA,
<FS_2> TYPE STANDARD TABLE,
<FS_22> TYPE STANDARD TABLE,
<FS_1>,
<FS_11>,
<F>,
<FA>,
<LWA_LINE_WA>,
<LWA_LINE_WA1>.
DATA: IT_FLDCAT TYPE LVC_T_FCAT.
DATA: T_FLDCAT1 TYPE SLIS_T_FIELDCAT_ALV.
DATA: L_LT TYPE SLIS_LAYOUT_ALV.
DATA: WA_IT_FLDCAT TYPE LVC_S_FCAT.
DATA: WA_IT_FLDCAT1 TYPE SLIS_FIELDCAT_ALV.
DATA: GP_TABLE TYPE REF TO DATA.
DATA: WA_NEWLINE TYPE REF TO DATA.
*DECLARATION FOR CONSTANTS
CONSTANTS:
BEGIN OF GC,
TDID_GRUN TYPE THEAD-TDID VALUE 'GRUN',
TDOBJECT_MAT TYPE THEAD-TDOBJECT VALUE 'MATERIAL',
ON(01) TYPE C VALUE 'X',
YES(01) TYPE C VALUE 'X',
TXT(25) TYPE C VALUE 'MATERIAL DETAILS',
MAT(25) TYPE C VALUE 'MATERIAL NUMBER',
AUT(25) TYPE C VALUE 'AUTHORIZATION GROUP',
FOUND TYPE SY-SUBRC VALUE '00', " Return-Code
RC_OK TYPE SY-SUBRC VALUE '00', " Return-Code
OFF TYPE SY-SUBRC VALUE '00', " return code
FALSE TYPE SY-SUBRC VALUE '00', " boolean
TRUE TYPE SY-SUBRC VALUE '01', " boolean
END OF GC.
* DECLARATION FOR VARIABLES
DATA: V(3) TYPE N,
STR TYPE STRING,
STR1 TYPE STRING,
V_VAR(3) TYPE N,
V_VAR1(3) TYPE N,
V_FIELDNAME(15) TYPE C,
V_CHAR(15) TYPE C,
V_LINES(3) TYPE N,
MAKTEXT LIKE MAKT-MAKTX,
LT_DATA TYPE REF TO DATA,
LT_DATA1 TYPE REF TO DATA,
LWA_LINE TYPE REF TO DATA,
LWA_LINE1 TYPE REF TO DATA.
*SELECTION-SCREEN AND PARAMETERS
SELECTION-SCREEN: BEGIN OF BLOCK A1 WITH FRAME TITLE TEXT-002.
SELECT-OPTIONS:
S_MATNR FOR MARA-MATNR, "MATERIAL NUMBER
S_MTART FOR MARA-MTART, "MATERIAL TEXT
S_LANG FOR MAKT-SPRAS. "LANGUAGE
PARAMETER: GP_SIZE TYPE I DEFAULT 200. "DATA LENGTH
SELECTION-SCREEN: END OF BLOCK A1.
* AT SELECTION SCREEN
AT SELECTION-SCREEN.
IF GP_SIZE < 0.
MESSAGE E002(00).
ENDIF.
IF GP_SIZE > 50000.
MESSAGE W130(26) WITH TEXT-004.
SET CURSOR FIELD 'gp_size'.
ENDIF.
* INITIALIZATION
INITIALIZATION.
GV-REPID = SY-REPID.
*START-OF-SELECTION
START-OF-SELECTION.
PERFORM GET_MARA_DATA
TABLES
GT_TEXT_OUTPUT_LINE
USING
S_MATNR[]
S_MTART[]
GP_SIZE
CHANGING
GV-RETCO
PERFORM GET_MAT_TEXT
TABLES
GT_MAKT
GT_TEXT_OUTPUT_LINE
GT_THEAD
GT_LINETAB
USING
GC
GV-RETCO
CHANGING
GV_TEXT_OUTPUT_LINE
GV_MAKT
PERFORM GET_LANG.
PERFORM DYNAMIC_TABLES.
PERFORM POPULATE_FINAL_TABLE.
PERFORM POPULATE_DYNAMIC_TABLE.
* END-OF-SELECTION
END-OF-SELECTION.
PERFORM DATA_OUTPUT.
*& Form get_mara_data
* Materialdaten lesen
* <->ct_gt_text_output_line Ausgabetabelle
* -->it_s_matnr Parameter Materialnummer
* -->it_s_mtart Parameter Materialart
* -->if_gp_size Parameter Anzahl Materialnummern
FORM GET_MARA_DATA TABLES CT_GT_TEXT_OUTPUT_LINE STRUCTURE
GV_TEXT_OUTPUT_LINE
USING IT_S_MATNR LIKE S_MATNR[]
IT_S_MTART LIKE S_MTART[]
IF_GP_SIZE
CHANGING IF_GV-RETCO. "#EC *
* MARA in die Übergabestruktur einlesen
SELECT MATNR BEGRU
FROM MARA UP TO IF_GP_SIZE ROWS
APPENDING CORRESPONDING FIELDS OF TABLE GT_MATNR
WHERE MATNR IN IT_S_MATNR
AND MTART IN IT_S_MTART.
IF_GV-RETCO = SY-SUBRC.
ENDFORM. " get_mara_data
*& Form get_mat_text
* Kurz- und Langtexte zum Material lesen
* <->ct_gt_makt Materialkurztexte
* <->ct_gt_text_output_line Ausgabetabelle
* <->ct_gt_thead Kopftabelle für ALV
* <->ct_gt_linetab Zeilentabelle für ALV
* -->if_gc Globale Konstanten
* <--cf_gv_text_output_line Struktur Ausgabetabelle
* <--cf_gv_makt Struktru Materialkurztexte
FORM GET_MAT_TEXT TABLES CT_GT_MAKT STRUCTURE MAKT
CT_GT_TEXT_OUTPUT_LINE STRUCTURE
GV_TEXT_OUTPUT_LINE
CT_GT_THEAD STRUCTURE THEAD
CT_GT_LINETAB STRUCTURE TLINE
USING
IF_GC LIKE GC
IF_GV-RETCO
CHANGING CF_GV_TEXT_OUTPUT_LINE LIKE
GV_TEXT_OUTPUT_LINE
CF_GV_MAKT LIKE GV_MAKT
DATA: STRG TYPE STRING,
STRG1(1255) TYPE C.
IF IF_GV-RETCO = IF_GC-FOUND.
* Materialkurztexte in alles Sprachen einlesen
SELECT * FROM MAKT APPENDING TABLE CT_GT_MAKT
FOR ALL ENTRIES IN GT_MATNR "ct_gt_text_output_line
WHERE MATNR = GT_MATNR-MATNR " ct_gt_text_output_line-matnr
* Kurztexte in die sprachabhängigen Felder bringen
LOOP AT GT_MATNR INTO WA_GT_MATNR.
LOOP AT CT_GT_MAKT INTO CF_GV_MAKT
WHERE MATNR = WA_GT_MATNR-MATNR.
CF_GV_TEXT_OUTPUT_LINE-MATNR = WA_GT_MATNR-MATNR.
CF_GV_TEXT_OUTPUT_LINE-BEGRU = WA_GT_MATNR-BEGRU.
CF_GV_TEXT_OUTPUT_LINE-MAKTX = CF_GV_MAKT-MAKTX.
CF_GV_TEXT_OUTPUT_LINE-SPRAS = CF_GV_MAKT-SPRAS.
* LANGTEXT
CLEAR CT_GT_THEAD[].
CT_GT_THEAD-TDOBJECT = IF_GC-TDOBJECT_MAT.
CT_GT_THEAD-TDNAME = WA_GT_MATNR-MATNR.
CT_GT_THEAD-TDID = IF_GC-TDID_GRUN.
CT_GT_THEAD-TDSPRAS = CF_GV_MAKT-SPRAS.
CALL FUNCTION 'TEXT_READ'
EXPORTING
I_HEADER = CT_GT_THEAD
I_READONLY = IF_GC-ON
IMPORTING
E_HEADER = CT_GT_THEAD
TABLES
T_LINES = CT_GT_LINETAB[]
EXCEPTIONS
NOTFOUND = 1.
IF SY-SUBRC = IF_GC-FOUND.
LOOP AT CT_GT_LINETAB.
STRG = CT_GT_LINETAB-TDLINE.
IF STRG1 <> ' '.
CONCATENATE STRG1 ';' STRG INTO STRG1.
ELSE.
STRG1 = STRG.
ENDIF.
ENDLOOP.
CF_GV_TEXT_OUTPUT_LINE-LTXT40 = STRG1.
APPEND CF_GV_TEXT_OUTPUT_LINE TO CT_GT_TEXT_OUTPUT_LINE.
CLEAR CF_GV_TEXT_OUTPUT_LINE.
STRG1 = ' '.
ELSE.
APPEND CF_GV_TEXT_OUTPUT_LINE TO CT_GT_TEXT_OUTPUT_LINE.
ENDIF.
ENDLOOP.
ENDLOOP.
ENDIF.
ENDFORM. " get_mat_text
*& Form data_output
* Daten mit ALV ausgeben
* <->ct_GT_FIELDCAT Feldkatalog für ALV
* <->ct_gt_text_output_line Ausgabetabelle
* -->P_GS_LAYOUT Layout für ALV
* -->if_gc Globale Konstanten
* <--cf_GV_REPID Zur Zeit aufgerufener Reportname
* <--cf_gv_fieldcat Struktur Feldkatalog
* <--cf_gv Globale Variablen
FORM DATA_OUTPUT.
PERFORM FIELDCATBUILD.
PERFORM LAYOUT.
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
EXPORTING
I_CALLBACK_PROGRAM = GV-REPID
I_CALLBACK_PF_STATUS_SET = 'EVENT_SET_STATUS_01'
I_CALLBACK_USER_COMMAND = 'EVENT_USER_COMMAND'
IS_LAYOUT = L_LT
IT_FIELDCAT = T_FLDCAT1[]
TABLES
T_OUTTAB = <FS_2>
EXCEPTIONS
PROGRAM_ERROR = 1
OTHERS = 2.
IF SY-SUBRC <> GC-FOUND.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDFORM. " data_output
*& Form fieldcatbuild
* text
* --> p1 text
* <-- p2 text
FORM FIELDCATBUILD. " TABLES ct_gt_fieldcat_in STRUCTURE gv_fieldcat.
LOOP AT IT_FLDCAT INTO WA_IT_FLDCAT.
WA_IT_FLDCAT1-FIELDNAME = WA_IT_FLDCAT-FIELDNAME.
WA_IT_FLDCAT1-TABNAME = WA_IT_FLDCAT-TABNAME.
WA_IT_FLDCAT1-SELTEXT_L = WA_IT_FLDCAT-FIELDNAME.
APPEND WA_IT_FLDCAT1 TO T_FLDCAT1.
CLEAR : WA_IT_FLDCAT,WA_IT_FLDCAT1.
ENDLOOP.
ENDFORM. " fieldcatbuild
* Form event_set_status_01*
FORM EVENT_SET_STATUS_01 USING LT_EXCL TYPE SLIS_T_EXTAB.
SET PF-STATUS 'ABCD' .
ENDFORM. "EVENT_SET_STATUS_01
*& Form Name: event_user_command *
*& Form Desc: For Handling USER_COMMAND *
FORM EVENT_USER_COMMAND USING
IF_UCOMM TYPE SY-UCOMM
IS_SELFIELD TYPE SLIS_SELFIELD.
CASE IF_UCOMM.
WHEN 'DOWNLOAD'.
PERFORM POPULATE_DOWNLOAD_TABLE.
DATA: L_LENGHT TYPE I.
CALL FUNCTION 'GUI_DOWNLOAD'
EXPORTING
FILENAME = 'C:data.xls'
FILETYPE = 'ASC'
WRITE_FIELD_SEPARATOR = 'X'
TRUNC_TRAILING_BLANKS = 'X'
DAT_MODE = 'X'
IMPORTING
FILELENGTH = L_LENGHT
TABLES
DATA_TAB = <FS_22>.
IF SY-SUBRC <> GC-FOUND.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
IF L_LENGHT NE GC-FOUND.
MESSAGE S398(00) WITH 'DATA downloaded to c:data.xls'.
ENDIF.
ENDCASE.
ENDFORM. "event_user_command
*& Form get_lang
* text
* --> p1 text
* <-- p2 text
FORM GET_LANG.
SELECT SPRAS
LAISO FROM T002 INTO CORRESPONDING FIELDS OF TABLE GT_LANG
WHERE SPRAS IN S_LANG.
DESCRIBE TABLE GT_LANG LINES V_LINES.
LOOP AT GT_LANG INTO WA_GT_LANG.
V = V + 1.
WA_GT_LANG-SRNO = V.
MODIFY GT_LANG FROM WA_GT_LANG TRANSPORTING SRNO.
ENDLOOP.
LOOP AT GT_LANG INTO WA_GT_LANG.
CONCATENATE 'MATEDESC-' WA_GT_LANG-LAISO INTO V_FIELDNAME.
CLEAR WA_IT_FLDCAT.
WA_IT_FLDCAT-FIELDNAME = V_FIELDNAME.
WA_IT_FLDCAT-SELTEXT = V_FIELDNAME.
WA_IT_FLDCAT-DATATYPE = 'CHAR'.
WA_IT_FLDCAT-INTLEN = 40.
WA_IT_FLDCAT-TABNAME = '<FS_2>'.
APPEND WA_IT_FLDCAT TO IT_FLDCAT .
CLEAR WA_GT_LANG.
ENDLOOP.
LOOP AT GT_LANG INTO WA_GT_LANG.
CONCATENATE 'BASDAT-' WA_GT_LANG-LAISO INTO V_FIELDNAME.
CLEAR WA_IT_FLDCAT.
WA_IT_FLDCAT-FIELDNAME = V_FIELDNAME.
WA_IT_FLDCAT-DATATYPE = 'CHAR'.
WA_IT_FLDCAT-INTLEN = 255.
WA_IT_FLDCAT-SELTEXT = V_FIELDNAME.
WA_IT_FLDCAT-TABNAME = '<FS_2>'.
APPEND WA_IT_FLDCAT TO IT_FLDCAT .
CLEAR WA_GT_LANG.
ENDLOOP.
V_FIELDNAME = 'MATNR'.
CLEAR WA_IT_FLDCAT.
WA_IT_FLDCAT-FIELDNAME = V_FIELDNAME.
WA_IT_FLDCAT-DATATYPE = 'CHAR'.
WA_IT_FLDCAT-SELTEXT = 'Matnr'.
WA_IT_FLDCAT-INTLEN = 18.
WA_IT_FLDCAT-TABNAME = '<FS_2>'.
INSERT WA_IT_FLDCAT INTO IT_FLDCAT INDEX 1.
V_FIELDNAME = 'BEGRU'.
CLEAR WA_IT_FLDCAT.
WA_IT_FLDCAT-FIELDNAME = V_FIELDNAME.
WA_IT_FLDCAT-DATATYPE = 'CHAR'.
WA_IT_FLDCAT-SELTEXT = 'BEGRU'.
WA_IT_FLDCAT-INTLEN = 4.
WA_IT_FLDCAT-TABNAME = '<FS_2>'.
INSERT WA_IT_FLDCAT INTO IT_FLDCAT INDEX 2.
ENDFORM. " get_lang
*& Form dynamic_tables
* text
* --> p1 text
* <-- p2 text
FORM DYNAMIC_TABLES.
ASSIGN LT_DATA TO <FS_DATA>.
* Creating the Dynamic Internal Table
CALL METHOD CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE
EXPORTING
IT_FIELDCATALOG = IT_FLDCAT " Fieldcatalogue
IMPORTING
EP_TABLE = <FS_DATA> " Dynamic Internal Table
EXCEPTIONS
GENERATE_SUBPOOL_DIR_FULL = 1
OTHERS = 2.
* Assign Dyn Table To Field Sumbol
ASSIGN <FS_DATA>->* TO <FS_1>.
* Assigning the Internal Table TYPE ANY to Standard internal Table
ASSIGN <FS_1> TO <FS_2>.
* Creating a Workarea
CREATE DATA LWA_LINE LIKE LINE OF <FS_2> .
* Assigning the Content to the workares as a Pointer
ASSIGN LWA_LINE->* TO <LWA_LINE_WA>.
ENDFORM. " dynamic_tables
*& Form populate_final_table
* text
* --> p1 text
* <-- p2 text
FORM POPULATE_FINAL_TABLE.
LOOP AT GT_TEXT_OUTPUT_LINE INTO GV_TEXT_OUTPUT_LINE.
READ TABLE GT_LANG INTO WA_GT_LANG
WITH KEY SPRAS = GV_TEXT_OUTPUT_LINE-SPRAS.
IF SY-SUBRC EQ GC-FOUND.
GV_TEXT_OUTPUT_LINE-SRNO = WA_GT_LANG-SRNO.
ENDIF.
MODIFY GT_TEXT_OUTPUT_LINE FROM GV_TEXT_OUTPUT_LINE.
ENDLOOP.
ENDFORM. " populate_final_table
*& Form populate_dynamic_table
* text
* --> p1 text
* <-- p2 text
FORM POPULATE_DYNAMIC_TABLE.
DATA: INDX TYPE SY-TABIX.
LOOP AT GT_TEXT_OUTPUT_LINE INTO GV_TEXT_OUTPUT_LINE.
AT NEW MATNR.
INDX = SY-TABIX.
ASSIGN COMPONENT 1 OF STRUCTURE <LWA_LINE_WA> TO <F>.
<F> = GV_TEXT_OUTPUT_LINE-MATNR.
ASSIGN COMPONENT 2 OF STRUCTURE <LWA_LINE_WA> TO <F>.
<F> = GV_TEXT_OUTPUT_LINE-BEGRU.
ENDAT.
LOOP AT GT_LANG INTO WA_GT_LANG.
IF GV_TEXT_OUTPUT_LINE-SRNO = WA_GT_LANG-SRNO.
V_VAR = GV_TEXT_OUTPUT_LINE-SRNO + 2.
ASSIGN COMPONENT V_VAR OF STRUCTURE <LWA_LINE_WA> TO <F>.
<F> = GV_TEXT_OUTPUT_LINE-MAKTX.
V_VAR = GV_TEXT_OUTPUT_LINE-SRNO + V_LINES + 2.
ASSIGN COMPONENT V_VAR OF STRUCTURE <LWA_LINE_WA> TO <F>.
<F> = GV_TEXT_OUTPUT_LINE-LTXT40.
ENDIF.
ENDLOOP.
AT END OF MATNR.
APPEND <LWA_LINE_WA> TO <FS_2>.
CLEAR <LWA_LINE_WA>.
ENDAT.
ENDLOOP.
ENDFORM. " populate_dynamic_table
*& Form LAYOUT
* text
* --> p1 text
* <-- p2 text
FORM LAYOUT.
CLEAR L_LT.
L_LT-ZEBRA = GC-YES.
L_LT-COLWIDTH_OPTIMIZE = 'X'.
L_LT-WINDOW_TITLEBAR = GC-TXT.
ENDFORM. " LAYOUT
*& Form populate_download_table
* text
* --> p1 text
* <-- p2 text
FORM POPULATE_DOWNLOAD_TABLE.
ASSIGN LT_DATA1 TO <FS_DATA1>.
CALL METHOD CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE
EXPORTING
IT_FIELDCATALOG = IT_FLDCAT " Fieldcatalogue
IMPORTING
EP_TABLE = <FS_DATA1> " Dynamic Internal table
EXCEPTIONS
GENERATE_SUBPOOL_DIR_FULL = 1
OTHERS = 2.
* Assign Dyn Table To Field Sumbol
ASSIGN <FS_DATA1>->* TO <FS_11>.
* Assigning the Internal Table TYPE ANY to Standard internal Table
ASSIGN <FS_11> TO <FS_22>.
* Creating a Workarea
CREATE DATA LWA_LINE1 LIKE LINE OF <FS_22> .
* Assigning the Content to the workares as a Pointer
ASSIGN LWA_LINE1->* TO <LWA_LINE_WA1>.
DATA: STRN1 TYPE STRING,
STRN2 TYPE STRING,
INDX TYPE SY-TABIX.
ASSIGN COMPONENT 1 OF STRUCTURE <LWA_LINE_WA1> TO <FA>.
<FA> = GC-MAT.
ASSIGN COMPONENT 2 OF STRUCTURE <LWA_LINE_WA1> TO <FA>.
<FA> = GC-AUT.
LOOP AT GT_LANG INTO WA_GT_LANG.
V_VAR1 = WA_GT_LANG-SRNO + 2.
CONCATENATE 'MATERIALDESCRIPTION-' WA_GT_LANG-LAISO INTO STRN1.
ASSIGN COMPONENT V_VAR1 OF STRUCTURE <LWA_LINE_WA1> TO <FA>.
<FA> = STRN1.
V_VAR1 = WA_GT_LANG-SRNO + V_LINES + 2.
CONCATENATE 'BASICDATA-' WA_GT_LANG-LAISO INTO STRN2.
ASSIGN COMPONENT V_VAR1 OF STRUCTURE <LWA_LINE_WA1> TO <FA>.
<FA> = STRN2.
ENDLOOP.
APPEND <LWA_LINE_WA1> TO <FS_22>.
CLEAR <LWA_LINE_WA1>.
APPEND <LWA_LINE_WA1> TO <FS_22>.
V_VAR1 = 0.
LOOP AT GT_TEXT_OUTPUT_LINE INTO GV_TEXT_OUTPUT_LINE.
AT NEW MATNR.
INDX = SY-TABIX.
ASSIGN COMPONENT 1 OF STRUCTURE <LWA_LINE_WA1> TO <FA>.
<FA> = GV_TEXT_OUTPUT_LINE-MATNR.
ASSIGN COMPONENT 2 OF STRUCTURE <LWA_LINE_WA1> TO <FA>.
<FA> = GV_TEXT_OUTPUT_LINE-BEGRU.
ENDAT.
LOOP AT GT_LANG INTO WA_GT_LANG.
IF GV_TEXT_OUTPUT_LINE-SRNO EQ WA_GT_LANG-SRNO.
V_VAR1 = GV_TEXT_OUTPUT_LINE-SRNO + 2.
ASSIGN COMPONENT V_VAR1 OF STRUCTURE <LWA_LINE_WA1> TO <FA>.
<FA> = GV_TEXT_OUTPUT_LINE-MAKTX.
V_VAR1 = GV_TEXT_OUTPUT_LINE-SRNO + V_LINES + 2.
ASSIGN COMPONENT V_VAR1 OF STRUCTURE <LWA_LINE_WA1> TO <FA>.
* STR = GV_TEXT_OUTPUT_LINE-LTXT40.
* SEARCH STR FOR ';'.
* DO.
* IF SY-SUBRC = 0.
* SPLIT STR AT ';' INTO STR1 STR.
* <FA> = STR1.
* APPEND <LWA_LINE_WA1> TO <FS_22>.
* SEARCH STR FOR ';'.
* CLEAR <LWA_LINE_WA1>.
* ELSE.
* EXIT.
* ENDIF.
* ENDDO.
* <FA> = STR.
* APPEND <LWA_LINE_WA1> TO <FS_22>.
<FA> = GV_TEXT_OUTPUT_LINE-LTXT40.
ENDIF.
ENDLOOP.
AT END OF MATNR.
APPEND <LWA_LINE_WA1> TO <FS_22>.
CLEAR <LWA_LINE_WA1>.
ENDAT.
ENDLOOP.
ENDFORM. " populate_download_table
thanks
Nitya -
Dynamically changing internal table in 'gui_download'
Hi Experts,
i have to download 4 internal tables, each with different structures, to the presentation server using 'gui_download', based on which radio-button is selected in the selection screen. I am hoping to use a single 'form' and 4 'perform' calls. how can I dynamically change the tables in the 'gui_download' function modules.
plz help.....................Hi ,
Build the field catalog dynamically based on the internal table structure based on the radio button selected.Use the dynamic internal table generated from the filedcatalog and use in GUI_DOWNLOAD.
See the below code:
*& Report ZRAJESH02
REPORT zrajesh02.
Dynamic internal table
TYPE-POOLS: slis.
FIELD-SYMBOLS: <dyn_table> TYPE STANDARD TABLE,
<dyn_wa>.
DATA: alv_fldcat TYPE slis_t_fieldcat_alv,
it_fldcat TYPE lvc_t_fcat.
DATA: lv_monate TYPE f,
lv_months TYPE i,
lv_date TYPE sy-datum,
p_check1 type n value '1'.
lv_date = sy-datum + 360.
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE text-001.
PARAMETERS: p_check TYPE c.
SELECTION-SCREEN END OF BLOCK b1.
START-OF-SELECTION.
CALL FUNCTION 'MONTHS_BETWEEN_TWO_DATES'
EXPORTING
i_datum_bis = lv_date
i_datum_von = sy-datum
i_kz_incl_bis = ' '
IMPORTING
e_monate = lv_monate.
lv_months = lv_monate.
PERFORM f_fcat USING 'AUFNR' 'CHAR' '12'.
PERFORM f_fcat USING 'POSNR' 'CHAR' '06'.
while p_check1 LE p_check.
PERFORM f_fcat USING p_check1 'CHAR' '1'.
p_check1 = p_check1 + 1.
endwhile.
PERFORM build_dyn_itab.
LOOP AT <dyn_table> INTO <dyn_wa>.
WRITE:/ <dyn_wa>.
ENDLOOP.
FORM f_fcat USING fieldname dattyp length.
DATA:wa_it_fldcat TYPE lvc_s_fcat.
CLEAR wa_it_fldcat.
wa_it_fldcat-fieldname = fieldname.
wa_it_fldcat-datatype = dattyp.
wa_it_fldcat-intlen = length.
APPEND wa_it_fldcat TO it_fldcat .
ENDFORM. "f_fcat
*& Form build_dyn_itab
text
FORM build_dyn_itab.
DATA: new_table TYPE REF TO data,
new_line TYPE REF TO data.
wa_it_fldcat TYPE lvc_s_fcat.
CLEAR wa_it_fldcat.
wa_it_fldcat-fieldname = 'AUFNR'.
wa_it_fldcat-datatype = 'CHAR'.
wa_it_fldcat-intlen = 12.
APPEND wa_it_fldcat TO it_fldcat .
CLEAR wa_it_fldcat.
wa_it_fldcat-fieldname = 'POSNR'.
wa_it_fldcat-datatype = 'CHAR'.
wa_it_fldcat-intlen = 6.
APPEND wa_it_fldcat TO it_fldcat .
Create dynamic internal table and assign to FS
CALL METHOD cl_alv_table_create=>create_dynamic_table
EXPORTING
it_fieldcatalog = it_fldcat
IMPORTING
ep_table = new_table.
ASSIGN new_table->* TO <dyn_table>.
Create dynamic work area and assign to FS
CREATE DATA new_line LIKE LINE OF <dyn_table>.
ASSIGN new_line->* TO <dyn_wa>.
ENDFORM. "build_dyn_itab
Thanks,
Rajesh. -
Internal Table ! Accessing Issue!
Hello Guys!
Internal table
Sorted, Hashed, Standard
For accesing itab uses,
Standard---> uses Linear Search
Sorted ---> Binary Search
Hashed-----> Hash Algorithm
Can u pls tell me what is linear search, binary search, hash algorithm?
And also,
Why we mostly go for standard table?
PLs give ur suggestions,
Thanks for your answers
<b><REMOVED BY MODERATOR></b>
Thanks
Rahul.
Message was edited by:
Alvaro Tejada GalindoTABKIND - Internal Table Types
Alternatives:
1. STANDARD TABLE
2. SORTED TABLE
3. HASHED TABLE
4. INDEX TABLE
5. ANY TABLE
Effect
The table type - set in the DATA, TYPES, orCREATE DATA statement, specifies how the system accesses entries in the internal table in generic key operations.
(READ TABLE itab, DELETE TABLE itab, INSERT TABLE itab, MODIFY TABLE itab, COLLECT itab). As a general rule, the runtime required for key operations depends on the total length of the key.
The various table types have the following hierarchy:
ANY TABLE
|
| |
INDEX TABLE HASHED TABLE
|
| |
STANDARD TABLE SORTED TABLE
Alternative 1
STANDARD TABLE
Effect
Defines the table as a standard table. Key access to a standard table uses a linear search. This means that the timne required for a search is in linear relation to the number of table entries.
You should use index operations to access standard tables.
For the sake of compatibility, you can use TABLE as a synonym of STANDARD TABLE.
Alternative 2
SORTED TABLE
Effect
Defines the table as one that is always saved correctly sorted. Key access to a sorted table uses a binary key. If the key is not unique, the system takes the entry with the lowest index. The runtime required for key access is logarithmically related to the number of table entries.
You can also access sorted tables by index operations. When you insert using an index, the system checks to ensure that the sort sequence has been correctly maintained. For this reason, it takes longer than inserting entries in a standard table. As a rule, you should only access sorted tables using their key.
Alternative 3
HASHED TABLE
Effect
Defines the table as one that is managed with an internal hash procedure. You can imagine a hashed table as a set, whose elements you can address using their unique key. Unlike standard and sorted tables, you cannot access hash tables using an index. All entries in the table must have a unique key. Access time using the key is constant, regardless of the number of table entries.
You can only access a hashed table using the generic key operations or other generic operations ( SORT, LOOP, and so on). Explicit or implicit index operations (such as LOOP ... FROM oe INSERT itab within a LOOP) are not allowed.
Alternative 4
INDEX TABLE
Effect
Standard and sorted tables belong to the generic class index tables. An index table is one that you can access using an index. You can currently only use the table type INDEX TABLE to specify the type of generic parameters in a FORM or a FUNCTION. Hashed tables are not index tables, and cannot therefore be passed to parameters defined as INDEX TABLE.
Alternative 5
ANY TABLE
Effect
Like INDEX TABLE, you use ANY TABLE to specify the type of any generic table parameter. The set of permitted operations for a table with type ANY TABLE consists of the intersection of all permitted operations for STANDARD, SORTED and HASHED TABLEs, and so is identical to the set of operations permitted for hashed tables.
Note in particular that you cannot use index access for tables with this type.
Maybe you are looking for
-
Error running SendMail when launch application from JNI
Hello, I am getting the following exception when I try to send email using JavaMail. This error began happening when we upgraded to Java 1.6. It does not happen with earlier versions of Java. javax.mail.SendFailedException: Sending failed; nested exc
-
How to make Popup LOV Not Editable?
Hello, I started using a Select List (named LOV) as an element in a report. However, I go the error: ORA-20001: Error fetching column value: ORA-06502: PL/SQL: numeric or value error: character string buffer too small So I switched to a Popup LOV (na
-
How i can send an email with attachement of any type format file in form10g
I developed an application in forms 10g my application send an email via outlook but i want to attach any type of PDF or WORD document how i can attach the file and send this email via outlook if any one know please share your valuable experience wit
-
If you are going to implement the MVC pattern in a webapp, what is the best framework to use? I've done a tutorial with Struts. Is that a good framework? Is there any disadvantages by using such frameworks?
-
ShoppingCartException:This site is not a valid site for given Bill to
Hi all I got following error when i tried to checkout from billing page. I have only changed the bill to contact and the I have changed any bill to addr then tried to checkout. please help me why this is happening.If I haven't changed the contact I a