Empty Internal table?
Hi Guys,
I am having a problem while writing the code The code is below.
SELECT *
INTO TABLE lt_JEST
FROM JEST
FOR ALL ENTRIES IN lt_PROJ
WHERE OBJNR EQ lt_PROJ-OBJNR.
In the code above i want to keep a condition that if there is no data in PROJ internal table Then this Select Statement should not be executed.Can anybody tell me how to do it?
Thanks,
Gopi.
Hi Gopi,
try this out.
IF NOT IT_PROJ[] IS INITIAL.
SELECT * from JEST
INTO TABLE IT_JEST
FOR ALL ENTRIES IN IT_PROJ
WHERE OBJNR = PROJ-OBJNR.
<b>(CHECK IF U WANT TO COMPARE WITH PROJ OR IT_PROJ, IF U R CHECKING IN IT_PROJ, THEN IT_PROJ-OBJNR. (<i>I THINK IT SHOULD BE IT_PROJ-OBJNR</i>)</b>
ELSE.
ENDIF.
REWARD POINTS IF USEFUL
THANKS
Sujay
Similar Messages
-
If empty internal table in select for all entries what is the result?
In select all entries statement , if empty internal table is there then what is the result.
Hello,
If the table is empty then it will select all the records table....
To aviod this u have check the body of the itab.
If not itab[] is intial.
select * ....
endif.
I useful reward.
Vasanth -
Hi,
I want to delete from internal table some regords.
I write code:
delete isrot where bldat < '01.09.2005'.
it doesn't work, what is wrong?
regards,
Joannahi,
you write the statement like....
<b>delete FROM isrot where bldat < '01.09.2005'.</b>
now it will work...
To select the lines that you want to delete using a condition, use the following:
<b>DELETE FROM <target> WHERE <cond> .</b>
All of the lines in the database table that satisfy the conditions in the WHERE clause are deleted. The FROM expression must occur between the keyword and the database table.
You should take particular care when programming the WHERE clause to ensure that you do not delete the wrong lines. For example, if you specify an empty internal table in a dynamic WHERE clause, all of the lines in the table are deleted.
If at least one line is deleted, the system sets SY-SUBRC to 0, otherwise to 4. SY-DBCNT contains the number of lines deleted.
follow this link for more information on internal table operation.
http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3aef358411d1829f0000e829fbfe/content.htm
regards,
Ashok Reddy
Message was edited by:
Ashok Reddy -
Hi,
I am a beginer. I know how to create a structure and how to create an internal table using ABAP/4. My problem is, i don't understand where to use internal table and structure, also i find myself very confused about the explicit work areas.
Plese someone show me a program by explaining all of this clearly.Hi
Internal tables are the core of ABAP. They are like soul of a body. For any program we use
internal tables extensively. We can use Internal tables like normal data base tables only, but the
basic difference is the memory allocated for internal tables is temporary. Once the program is
closed the memory allocated for internal tables will also be out of memory.
But while using the internal tables, there are many performance issues to be considered. i.e which
type of internal table to be used for the program..like standard internal table, hashed internal
table or sorted internal table etc..
Internal tables
Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by
line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data
objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables
whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for
storing and formatting data from a database table within a program. They are also a good way of including very complicated data
structures in an ABAP program.
Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract
description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The
data type is also an attribute of an existing data object.
Internal Tables as Data Types
Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type,
key, and table type.
Line type
The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the
structure is a column in the internal table. However, the line type may also be elementary or another internal table.
Key
The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify
whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness
depends on the table access method.
If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves
internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type
is an internal table, the default key is empty.
The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables
with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember
this, for example, if you intend to sort the table according to the key.
Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In
this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access
records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table.
The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled
very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the
table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system
uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether
the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of
table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique.
When you define the table, you must specify the key as UNIQUE.
Generic Internal Tables
Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a
generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic
internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data
objects.
Internal Tables as Dynamic Data Objects
Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in
respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects,
since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are
the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration)
is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more
than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The
individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the
internal table.
Choosing a Table Type
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most
frequently executed.
Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest
possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by
specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship
with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in
separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key
access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries
are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add
them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always
uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the
table key in the WHERE condition.
Hashed tables
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index.
The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always
have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for
processing large amounts of data.
Creating Internal Tables
Like other elements in the ABAP type concept, you can declare internal tables as abstract data
types in programs or in the ABAP Dictionary, and then use them to define data objects.
Alternatively, you can define them directly as data objects. When you create an internal table as a
data object, you should ensure that only the administration entry which belongs to an internal
table is declared statically. The minimum size of an internal table is 256 bytes. This is important if an
internal table occurs as a component of an aggregated data object, since even empty internal
tables within tables can lead to high memory usage. (In the next functional release, the size of the
table header for an initial table will be reduced to 8 bytes). Unlike all other ABAP data objects, you
do not have to specify the memory required for an internal table. Table rows are added to and
deleted from the table dynamically at runtime by the various statements for adding and deleting
records.
You can create internal tables in different types.
You can create standard internal table and then make it sort in side the program.
The same way you can change to hashed internal tables also.
There will be some performance issues with regard to standard internal tables/ hashed internal
tables/ sorted internal tables.
Internal table types
This section describes how to define internal tables locally in a program. You can also define internal tables globally as data types in the
ABAP Dictionary.
Like all local data types in programs , you define internal tables using the TYPES statement. If you do not refer to an existing table type
using the TYPE or LIKE addition, you can use the TYPES statement to construct a new local internal table in your program.
TYPES <t> TYPE|LIKE <tabkind> OF <linetype> [WITH <key>]
[INITIAL SIZE <n>].
After TYPE or LIKE, there is no reference to an existing data type. Instead, the type constructor occurs:
<tabkind> OF <linetype> [WITH <key>]
The type constructor defines the table type <tabkind>, the line type <linetype>, and the key <key> of the internal table <t>.
You can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
Table type
You can specify the table type <tabkind> as follows:
Generic table types
INDEX TABLE
For creating a generic table type with index access.
ANY TABLE
For creating a fully-generic table type.
Data types defined using generic types can currently only be used for field symbols and for interface parameters in procedures . The generic
type INDEX TABLE includes standard tables and sorted tables. These are the two table types for which index access is allowed. You cannot
pass hashed tables to field symbols or interface parameters defined in this way. The generic type ANY TABLE can represent any table. You
can pass tables of all three types to field symbols and interface parameters defined in this way. However, these field symbols and
parameters will then only allow operations that are possible for all tables, that is, index operations are not allowed.
Fully-Specified Table Types
STANDARD TABLE or TABLE
For creating standard tables.
SORTED TABLE
For creating sorted tables.
HASHED TABLE
For creating hashed tables.
Fully-specified table types determine how the system will access the entries in the table in key operations. It uses a linear search for
standard tables, a binary search for sorted tables, and a search using a hash algorithm for hashed tables.
Line type
For the line type <linetype>, you can specify:
Any data type if you are using the TYPE addition. This can be a predefined ABAP type, a local type in the program, or a data type from the
ABAP Dictionary. If you specify any of the generic elementary types C, N, P, or X, any attributes that you fail to specify (field length, number
of decimal places) are automatically filled with the default values. You cannot specify any other generic types.
Any data object recognized within the program at that point if you are using the LIKE addition. The line type adopts the fully-specified data
type of the data object to which you refer. Except for within classes, you can still use the LIKE addition to refer to database tables and
structures in the ABAP Dictionary (for compatibility reasons).
All of the lines in the internal table have the fully-specified technical attributes of the specified data type.
Key
You can specify the key <key> of an internal table as follows:
[UNIQUE|NON-UNIQUE] KEY <col1> ... <col n>
In tables with a structured line type, all of the components <coli> belong to the key as long as they are not internal tables or references,
and do not contain internal tables or references. Key fields can be nested structures. The substructures are expanded component by
component when you access the table using the key. The system follows the sequence of the key fields.
[UNIQUE|NON-UNIQUE] KEY TABLE LINE
If a table has an elementary line type (C, D, F, I, N, P, T, X), you can define the entire line as the key. If you try this for a table whose line
type is itself a table, a syntax error occurs. If a table has a structured line type, it is possible to specify the entire line as the key. However,
you should remember that this is often not suitable.
[UNIQUE|NON-UNIQUE] DEFAULT KEY
This declares the fields of the default key as the key fields. If the table has a structured line type, the default key contains all non-numeric
columns of the internal table that are not and do not contain references or internal tables. If the table has an elementary line type, the
default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
Specifying a key is optional. If you do not specify a key, the system defines a table type with an arbitrary key. You can only use this to
define the types of field symbols and the interface parameters of procedures . For exceptions, refer to Special Features of Standard Tables.
The optional additions UNIQUE or NON-UNIQUE determine whether the key is to be unique or non-unique, that is, whether the table can
accept duplicate entries. If you do not specify UNIQUE or NON-UNIQUE for the key, the table type is generic in this respect. As such, it can
only be used for specifying types. When you specify the table type simultaneously, you must note the following restrictions:
You cannot use the UNIQUE addition for standard tables. The system always generates the NON-UNIQUE addition automatically.
You must always specify the UNIQUE option when you create a hashed table.
Initial Memory Requirement
You can specify the initial amount of main memory assigned to an internal table object when you define the data type using the following
addition:
INITIAL SIZE <n>
This size does not belong to the data type of the internal table, and does not affect the type check. You can use the above addition to
reserve memory space for <n> table lines when you declare the table object.
When this initial area is full, the system makes twice as much extra space available up to a limit of 8KB. Further memory areas of 12KB each
are then allocated.
You can usually leave it to the system to work out the initial memory requirement. The first time you fill the table, little memory is used. The
space occupied, depending on the line width, is 16 <= <n> <= 100.
It only makes sense to specify a concrete value of <n> if you can specify a precise number of table entries when you create the table and
need to allocate exactly that amount of memory (exception: Appending table lines to ranked lists). This can be particularly important for
deep-structured internal tables where the inner table only has a few entries (less than 5, for example).
To avoid excessive requests for memory, large values of <n> are treated as follows: The largest possible value of <n> is 8KB divided by the
length of the line. If you specify a larger value of <n>, the system calculates a new value so that n times the line width is around 12KB.
Examples
TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.
TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
The program defines a table type ITAB. It is a sorted table, with line type of the structure LINE and a unique key of the component
COLUMN1.
TYPES VECTOR TYPE HASHED TABLE OF I WITH UNIQUE KEY TABLE LINE.
TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.
TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
TYPES: BEGIN OF DEEPLINE,
FIELD TYPE C,
TABLE1 TYPE VECTOR,
TABLE2 TYPE ITAB,
END OF DEEPLINE.
TYPES DEEPTABLE TYPE STANDARD TABLE OF DEEPLINE
WITH DEFAULT KEY.
The program defines a table type VECTOR with type hashed table, the elementary line type I and a unique key of the entire table line. The
second table type is the same as in the previous example. The structure DEEPLINE contains the internal table as a component. The table
type DEEPTABLE has the line type DEEPLINE. Therefore, the elements of this internal table are themselves internal tables. The key is the
default key - in this case the column FIELD. The key is non-unique, since the table is a standard table.
Internal table objects
Internal tables are dynamic variable data objects. Like all variables, you declare them using the DATA statement. You can also declare static
internal tables in procedures using the STATICS statement, and static internal tables in classes using the CLASS-DATA statement. This
description is restricted to the DATA statement. However, it applies equally to the STATICS and CLASS-DATA statements.
Reference to Declared Internal Table Types
Like all other data objects, you can declare internal table objects using the LIKE or TYPE addition of the DATA statement.
DATA <itab> TYPE <type>|LIKE <obj> [WITH HEADER LINE].
Here, the LIKE addition refers to an existing table object in the same program. The TYPE addition can refer to an internal type in the
program declared using the TYPES statement, or a table type in the ABAP Dictionary.
You must ensure that you only refer to tables that are fully typed. Referring to generic table types (ANY TABLE, INDEX TABLE) or not
specifying the key fully is not allowed (for exceptions, refer to Special Features of Standard Tables).
The optional addition WITH HEADER line declares an extra data object with the same name and line type as the internal table. This data
object is known as the header line of the internal table. You use it as a work area when working with the internal table (see Using the
Header Line as a Work Area). When you use internal tables with header lines, you must remember that the header line and the body of the
table have the same name. If you have an internal table with header line and you want to address the body of the table, you must indicate
this by placing brackets after the table name (<itab>[]). Otherwise, ABAP interprets the name as the name of the header line and not of the
body of the table. You can avoid this potential confusion by using internal tables without header lines. In particular, internal tables nested
in structures or other internal tables must not have a header line, since this can lead to ambiguous expressions.
TYPES VECTOR TYPE SORTED TABLE OF I WITH UNIQUE KEY TABLE LINE.
DATA: ITAB TYPE VECTOR,
JTAB LIKE ITAB WITH HEADER LINE.
MOVE ITAB TO JTAB. <- Syntax error!
MOVE ITAB TO JTAB[].
The table object ITAB is created with reference to the table type VECTOR. The table object JTAB has the same data type as ITAB. JTAB also
has a header line. In the first MOVE statement, JTAB addresses the header line. Since this has the data type I, and the table type of ITAB
cannot be converted into an elementary type, the MOVE statement causes a syntax error. The second MOVE statement is correct, since
both operands are table objects.
Declaring New Internal Tables
You can use the DATA statement to construct new internal tables as well as using the LIKE or TYPE addition to refer to existing types or
objects. The table type that you construct does not exist in its own right; instead, it is only an attribute of the table object. You can refer to
it using the LIKE addition, but not using TYPE. The syntax for constructing a table object in the DATA statement is similar to that for defining
a table type in the TYPES statement.
DATA <itab> TYPE|LIKE <tabkind> OF <linetype> WITH <key>
[INITIAL SIZE <n>]
[WITH HEADER LINE].
As when you define a table type , the type constructor
<tabkind> OF <linetype> WITH <key>
defines the table type <tabkind>, the line type <linekind>, and the key <key> of the internal table <itab>. Since the technical attributes of
data objects are always fully specified, the table must be fully specified in the DATA statement. You cannot create generic table types (ANY
TABLE, INDEX TABLE), only fully-typed tables (STANDARD TABLE, SORTED TABLE, HASHED TABLE). You must also specify the key and whether
it is to be unique (for exceptions, refer to Special Features of Standard Tables).
As in the TYPES statement, you can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
You can create an internal table with a header line using the WITH HEADER LINE addition. The header line is created under the same
conditions as apply when you refer to an existing table type.
DATA ITAB TYPE HASHED TABLE OF SPFLI
WITH UNIQUE KEY CARRID CONNID.
The table object ITAB has the type hashed table, a line type corresponding to the flat structure SPFLI from the ABAP Dictionary, and a
unique key with the key fields CARRID and CONNID. The internal table ITAB can be regarded as an internal template for the database table
SPFLI. It is therefore particularly suitable for working with data from this database table as long as you only access it using the key. -
I need to add check whether 21 fields of a internal table are empty or not.
Hello,
I need to add check whether 21 fields of a internal table are empty or not.How can we write a code for the same wand what would be the correct syntax for it.
I tried entering all the fields in the IF loop with AND condition but its giving syntax error.Perhaps this is because the lenght of the IF condition would be more than the allowed one.Hi,
After the select quiery.
If not itab is initial.
Message 'Table is not empty' type 'I'.
Endif.
Regards,
Jagadish. -
Appending empty rows in internal table
Hi,
i am using table control, where there is a condition, some row may left empty. end if i press enter button the empty row is filled by the next available record. My need is to pick the records in the table control to the internal table including the empty rows as it is.Hi Karthikeyan,
By default with user pressinng enter, empty rows will get deleted.
How are you populating your table control? Is it from standard transaction or your internal table?
If it is from your internal table, you can add anothe flag field for empty row.
Whenever row is empty in your internal table, mark flag field as 'X', so in the table control you these entries will not get vanished with pressing of enter.
This is one idea and you can build on this. You can make this flag column as non editable so that no one can change these.
hope this helps,
ags. -
Populating Empty Fields for Existing Internal Table Using For All Entries
I have an internal table called itab_extract that populates without any issues in SELECT A and SELECT B below. Trying to avoid looping, I am using select DB table 'for all entries' in itab_extract. I want the empty fields in itab_extract to populate from the values in the database. However, about 200,000 entries are being appended to the table, and, the values that existed for the already populated fields in itab_extract are gone, and the new fields are populated.
I've played with the syntax and cannot seem to get it to work. My next option is a time consuming loop.
How should the for all entries syntax look to accomplish filling the empty fields in the itab? Thank-You
*read ekko
select ebeln lifnr aedat bsart from ekko *SELECT A*
into CORRESPONDING FIELDS OF TABLE me->itab_extract
where aedat in r_aedat.
select ebeln lifnr aedat BSART from ekko *SELECT B*
appending CORRESPONDING FIELDS OF TABLE me->itab_extract
where aedat in S_DATE2 AND
BSART IN S_BSART.
select ebelp werks matnr *SELECT C*
into CORRESPONDING FIELDS OF TABLE itab_extract
from ekpo
FOR ALL ENTRIES IN itab_extract
where ebeln = itab_extract-ebeln.Hi Tom,
This SQL statement will be time consuming, Do not use a loop.
There are two options.
1. Select EKKO and EKPO details based on standard SAP view. (You can type EKKO in se11 view to find the correct view).
also use one range table populate r_aedat and s_date2 in the same. So you where condition will have r_newrange and
s_bsart. Also do not use into corresponding fields, it is not a good idea. It will increase your performance. Maintain the proper
sequence (Based on database structure of EKKO and EKPO)
2. If you are keen to use for all entries, then first select ekko then after your sy-subrc check get the data from EKPO.
Should be like this.
select ebeln bsart aedat lifnr from ekko into table gt_ekko where aedat in r_newrange and bsart in s_bsart.
if sy-subrc eq 0.
sort gt_ekko by ebeln ascending.
select ebeln ebelp werks matnr into table gt_ekpo for all entries in gt_ekko where ebeln eq gt_ekko-ebeln.
endif.
Hope it helps,
Best Regards,
Tapodipta Khan. -
Hide or Delete Empty columns in dynamic internal table
Hi,
I am having an dynamic internal table which contains more than 100 columns.
I need to delete empty column from that table, can any one help this.Hello,
If you are talking about ALV then you can just the the table for empty columns before populating fieldcataloge and hide the columns.
If your query is still not answered please provide a detail requirement. -
ALV grid is not displaying few fields of final internal table of type DMBTR
hello frnds,
i am displaying 10 fields in ALV grid using field catalog.
among them five fields are currency fields on which i doing some arithematic operations. but all these fields are not getting displayed in alv grid.
here is my code....
declaring final strucutre to generate report
TYPES:BEGIN OF ty_final,
gjahr TYPE gjahr, " Year
wwert TYPE wwert_d, " Traslation date
bukrs TYPE bukrs, " company code
hkont TYPE hkont, " General ledger account
txt20 TYPE txt20_skat, " Account name
belnr TYPE belnr_d, " Purchase order number
shkzg TYPE shkzg, " Dt/Cr indicator
dmbtr1 TYPE dmbtr, " Ammount in local currency
v_alc TYPE dmbtr, " Ammount in local currency
wrbtr TYPE wrbtr, " Ammount in foreign currency
ebeln TYPE ebeln, " Purchase order number
ebelp TYPE ebelp, " Item number
matnr TYPE matnr, " Material number
menge TYPE menge_d, " Qunatity
meins TYPE meins, " Unit of measure
stprs TYPE stprs, " Std material master
v_iv TYPE dmbtr, " Invoice value
pswsl TYPE pswsl, " Currency
v_erc TYPE dmbtr, " Exchange rate calculated
v_op TYPE dmbtr, " Order price
v_uos TYPE dmbtr, " Unit order to stock
v_io TYPE dmbtr, " Invoice to order
v_uv TYPE dmbtr, " Unit value
v_t TYPE dmbtr, " Total
v_d TYPE dmbtr, " Differecne
netpr TYPE bprei, " Net price in purchasing document
v_total TYPE dmbtr, " Total
v_os TYPE dmbtr, " Order to stock
v_ito TYPE dmbtr, " Invoice to order
saknr TYPE saknr, " G/L account number
END OF ty_final.
FORM move_data.
IF NOT i_bseg[] IS INITIAL.
LOOP AT i_bseg INTO wa_bseg.
wa_final-gjahr = wa_bseg-gjahr.
wa_final-bukrs = wa_bseg-bukrs.
wa_final-hkont = wa_bseg-hkont.
wa_final-belnr = wa_bseg-belnr.
wa_final-shkzg = wa_bseg-shkzg.
wa_final-wrbtr = wa_bseg-wrbtr.
wa_final-ebeln = wa_bseg-ebeln.
wa_final-ebelp = wa_bseg-ebelp.
wa_final-matnr = wa_bseg-matnr.
wa_final-menge = wa_bseg-menge.
wa_final-meins = wa_bseg-meins.
wa_final-pswsl = wa_bseg-pswsl.
wa_final-dmbtr1 = wa_bseg-dmbtr.
wa_final-saknr = wa_bseg-saknr.
wa_final-v_total = wa_bseg-dmbtr.
READ TABLE i_bkpf INTO wa_bkpf WITH KEY bukrs = wa_bseg-bukrs.
IF sy-subrc = 0.
wa_final-wwert = wa_bkpf-wwert.
ENDIF.
CLEAR wa_bkpf.
READ TABLE i_mbew INTO wa_mbew WITH KEY matnr = wa_bseg-matnr.
IF sy-subrc = 0.
wa_final-stprs = wa_mbew-stprs.
ENDIF.
CLEAR wa_mbew.
READ TABLE i_ekpo INTO wa_ekpo WITH KEY ebeln = wa_bseg-ebeln.
IF sy-subrc = 0.
wa_final-netpr = wa_ekpo-netpr.
ENDIF.
CLEAR wa_ekpo.
READ TABLE i_skat INTO wa_skat WITH KEY saknr = wa_bseg-saknr.
IF sy-subrc = 0.
wa_final-txt20 = wa_skat-txt20.
ENDIF.
calculating output values
IF wa_bseg-shkzg = 'H'.
wa_final-v_alc = -1 * wa_bseg-dmbtr.
ELSEIF wa_bseg-shkzg = 'S'.
wa_final-v_alc = 1 * wa_bseg-dmbtr.
ENDIF.
DATA : l_c_v_alc TYPE p DECIMALS 2,
l_c_v_iv TYPE p DECIMALS 2.
l_c_v_alc = wa_final-v_alc.
IF wa_bseg-menge NE 0.
wa_final-v_iv = wa_bseg-dmbtr / wa_bseg-menge.
ENDIF.
IF wa_bseg-dmbtr NE 0.
wa_final-v_erc = wa_bseg-wrbtr / wa_final-dmbtr1.
ENDIF.
IF wa_final-v_erc NE 0.
wa_final-v_op = wa_ekpo-netpr / wa_final-v_erc.
ENDIF.
wa_final-v_uos = wa_mbew-stprs - wa_final-v_op.
wa_final-v_io = wa_final-v_iv + wa_final-v_uos.
wa_final-v_uv = wa_final-v_uos + wa_final-v_io.
wa_final-v_t = wa_final-v_uv + wa_bseg-menge.
wa_final-v_d = wa_final-v_t - wa_final-v_alc.
wa_final-v_os = wa_final-v_uos * wa_bseg-menge.
wa_final-v_ito = wa_final-v_io * wa_bseg-menge.
CLEAR wa_bseg.
APPEND wa_final TO i_final.
CLEAR wa_final.
ENDLOOP.
ENDIF.
ENDFORM. "data_retrieval
*& Form build_fieldcat
text
--> p1 text
<-- p2 text
FORM build_fieldcat.
CLEAR wa_fieldcat.
* TYPES : v_alc TYPE dmbtr. "curr. " decimal 2.
DATA: l_c_v_alc TYPE p DECIMALS 2,
l_c_v_iv TYPE p DECIMALS 2 .
l_c_v_alc = v_alc.
l_c_v_iv = v_iv.
Constant Declarations.
CONSTANTS:
l_c_gjahr(5) TYPE c VALUE 'GJAHR', " Year
l_c_wwert(5) TYPE c VALUE 'WWERT', " Traslation date
l_c_bukrs(5) TYPE c VALUE 'BUKRS', " company code
l_c_hkont(5) TYPE c VALUE 'HKONT', " General ledger account
l_c_txt20(10) TYPE c VALUE 'TXT20', " Account name
l_c_belnr(5) TYPE c VALUE 'BELNR', " Doc number
l_c_shkzg(5) TYPE c VALUE 'SHKZG', " Dt/Cr indicator
l_c_dmbtr(5) TYPE c VALUE 'DMBTR1', " Ammount in local currency
" l_c_v_alc TYPE c VALUE 'V_ALC', " Ammount in local currency
l_c_wrbtr(5) TYPE c VALUE 'WRBTR', " Ammount in foreign currency
l_c_ebeln(5) TYPE c VALUE 'EBELN', " Purchase order number
l_c_ebelp(5) TYPE c VALUE 'EBELP', " Item number
l_c_matnr(5) TYPE c VALUE 'MATNR', " Material number
l_c_menge(7) TYPE c VALUE 'MENGE', " Qunatity
l_c_meins(5) TYPE c VALUE 'MEINS', " Unit of measure
l_c_stprs(5) TYPE c VALUE 'STPRS', " Std material master
" l_c_v_iv(4) TYPE c VALUE 'V_IV', " Invoice value
l_c_pswsl(5) TYPE c VALUE 'PSWSL', " Currency
l_c_v_erc(5) TYPE c VALUE 'V_ERC', " Exchange rate calculated
l_c_v_op(4) TYPE c VALUE 'V_OP', " Order price
l_c_v_uos(5) TYPE c VALUE 'V_UOS', " Unit order to stock
l_c_v_io(4) TYPE c VALUE 'V_IO', " Invoice to order
l_c_v_uv(4) TYPE c VALUE 'V_UV', " Unit value
l_c_v_t(3) TYPE c VALUE 'V_T', " Total
l_c_v_d(3) TYPE c VALUE 'V_D', " Differecne
l_c_netpr(5) TYPE c VALUE 'NETPR', " Net price in purchasing document
l_c_v_total(7) TYPE c VALUE 'V_TOTAL', " Total
l_c_v_os(4) TYPE c VALUE 'V_OS', " Order to stock
l_c_v_ito(5) TYPE c VALUE 'V_ITO', " Invoice to order
l_c_saknr(5) TYPE c VALUE 'SAKNR', " G/L account number
l_c_i_final(7) TYPE c VALUE 'I_FINAL'. " Final internal table
Fieldcat for fiscal year
wa_fieldcat-col_pos = 1.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_gjahr.
wa_fieldcat-seltext_m = text-007.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Translation date
wa_fieldcat-col_pos = 2.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_wwert.
wa_fieldcat-seltext_m = text-008.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Company code
wa_fieldcat-col_pos = 3.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_bukrs.
wa_fieldcat-seltext_m = text-009.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for General ledger account
wa_fieldcat-col_pos = 4.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_hkont.
wa_fieldcat-seltext_m = text-010.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Account name
wa_fieldcat-col_pos = 5.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_txt20.
wa_fieldcat-seltext_m = text-011.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Doc number
wa_fieldcat-col_pos = 6.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_belnr.
wa_fieldcat-seltext_m = text-012.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Dt/Cr indicator
wa_fieldcat-col_pos = 7.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_shkzg.
wa_fieldcat-seltext_m = text-013.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Ammount in local currency
wa_fieldcat-col_pos = 8.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = 'DMBTR1'.
wa_fieldcat-seltext_m = text-014.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Ammount in local currency
wa_fieldcat-col_pos = 9.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = 'V_ALC'.
wa_fieldcat-seltext_m = text-015.
wa_fieldcat-ref_fieldname = 'DMBTR'.
wa_fieldcat-no_sign = 'X'.
wa_fieldcat-do_sum = c_x.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Ammount in foreign currency
wa_fieldcat-col_pos = 10.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_wrbtr.
wa_fieldcat-seltext_m = text-016.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Purchse order number
wa_fieldcat-col_pos = 11.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_ebeln.
wa_fieldcat-seltext_m = text-017.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Item No
wa_fieldcat-col_pos = 12.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_ebelp.
wa_fieldcat-seltext_m = text-018.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Material number
wa_fieldcat-col_pos = 13.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_matnr.
wa_fieldcat-seltext_m = text-019.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Qunatity
wa_fieldcat-col_pos = 14.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_menge.
wa_fieldcat-seltext_m = text-020.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Unit of measure
wa_fieldcat-col_pos = 15.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_meins.
wa_fieldcat-seltext_m = text-021.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Std material master
wa_fieldcat-col_pos = 16.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_stprs.
wa_fieldcat-seltext_m = text-022.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Invoice value,
wa_fieldcat-col_pos = 17.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = 'V_IV'.
wa_fieldcat-seltext_m = text-023.
wa_fieldcat-ref_fieldname = 'DMBTR'.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Currency
wa_fieldcat-col_pos = 18.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_pswsl.
wa_fieldcat-seltext_m = text-024.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Exchange rate calculated
wa_fieldcat-col_pos = 19.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = 'V_ERC'.
wa_fieldcat-seltext_m = text-025.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Order price
wa_fieldcat-col_pos = 20.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_v_op.
wa_fieldcat-seltext_m = text-026.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Unit order to stock
wa_fieldcat-col_pos = 21.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_v_uos.
wa_fieldcat-seltext_m = text-027.
wa_fieldcat-do_sum = c_x.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Invoice to order
wa_fieldcat-col_pos = 22.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_v_io.
wa_fieldcat-seltext_m = text-028.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Unit value
wa_fieldcat-col_pos = 23.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_v_uv.
wa_fieldcat-seltext_m = text-029.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Total
wa_fieldcat-col_pos = 24.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_v_t.
wa_fieldcat-seltext_m = text-030.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Difference
wa_fieldcat-col_pos = 25.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_v_d.
wa_fieldcat-seltext_m = text-031.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Net Price in Purchasing Document
wa_fieldcat-col_pos = 26.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_netpr.
wa_fieldcat-seltext_m = text-032.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Total
wa_fieldcat-col_pos = 27.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_v_total.
wa_fieldcat-seltext_m = text-033.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Order to stock
wa_fieldcat-col_pos = 28.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_v_os.
wa_fieldcat-seltext_m = text-034.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
Fieldcat for Invoice to order
wa_fieldcat-col_pos = 29.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_v_ito.
wa_fieldcat-seltext_m = text-035.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
fieldcat for invoice to order
wa_fieldcat-col_pos = 30.
wa_fieldcat-tabname = l_c_i_final.
wa_fieldcat-fieldname = l_c_saknr.
wa_fieldcat-seltext_m = text-035.
APPEND wa_fieldcat TO i_fieldcat.
CLEAR wa_fieldcat.
ENDFORM. "build_fieldcatHi romanch,
defining the field catalog you must reference all currency fields to the respective currency key field (type CUKY).
<alv_fieldcat>-cfieldname = 'HWAER'.
This is sample for alv output of a currency field. The alv structure has a field HWAER which carries the currency key, e.g. USD or so.
Obviously you do not provide a cutrrency key for your values. If they are initial (zero), ALV will not display them as 0,00 but leave the field empty if the reference too currency key is not established.
If you define a DDIC structure for the ALV output this refernce is enforced. You can pass the DDIC structure name to the ALV and don not have to create the field catalog manually.
Regards,
Clemens -
Select on MARA resulting into # values in internal table for one field
Hi Team,
I have written a SELECT statement on MARA table as below.
TRY.
SELECT matnr zzwftag FROM mara CLIENT SPECIFIED
INTO CORRESPONDING FIELDS OF TABLE gt_mara WHERE
mandt = sy-mandt AND
zzwftag NE space
AND zzwftag IS NOT NULL
AND zzwftag NE '#'
AND zzwftag NE '%#%'
AND zzwftag NE ' '
AND zzwftag NOT LIKE '%/%'(012).
CATCH cx_sy_dynamic_osql_error.
MESSAGE 'Error While Fetching Data from MARA'(044) TYPE 'S'(040) DISPLAY LIKE 'W'(041).
ENDTRY.
IF NOT gt_mara[] IS INITIAL.
DELETE gt_mara[] WHERE zzwftag EQ '#'
OR zzwftag IS INITIAL
OR zzwftag EQ space
OR zzwftag EQ ' '.
ENDIF.
Observations: 1. In
the resulting internal table I am seeing '#' values for fields zzwftag which are actually empty when I see the record in SE11 in MARA(ALV display). It shows '#' in it in SE16 display(We can choose User parameters and hence mode of display in SE11)
The requirement is to avoid those records where zzwftag is initial i.e. blank. I tried to delete invalid records but to no avail.
Please suggest any way where I can get the Select correct.
Regards,
AmitPlease do not use so many not conditions in one query....
Using so many negative conditions results in bad data.
Instead use delete statements later this would not confuse the system.
Also if you are using sy-mandt then i think you should not use client specified system will take care of it.
TRY.
SELECT matnr zzwftag FROM mara CLIENT SPECIFIED
INTO CORRESPONDING FIELDS OF TABLE gt_mara WHERE
mandt = sy-mandt AND
zzwftag NE space.
CATCH cx_sy_dynamic_osql_error.
MESSAGE 'Error While Fetching Data from MARA'(044) TYPE 'S'(040) DISPLAY LIKE 'W'(041).
ENDTRY.
IF NOT gt_mara[] IS INITIAL.
DELETE gt_mara[] WHERE zzwftag EQ '#'
OR zzwftag IS INITIAL
OR zzwftag EQ space
OR zzwftag EQ ' '.
delete gt_mara[] where zzwflag eq '%#%'.
ENDIF. -
Importing internal table from one program to another program
Hi everybody,
i have one small doubt.
i am using submit statement and passing the values from this program to another program selection screen. in that program logic is written.In that program one internal table values are being exported to the memory id of that program. now i have to import that internal table values into my program by using import statement. i am using the following syntax
import itab from menory id 'program name'.
but i am getting an error saying program name is unknown.
what is the exat syntax for this .
thanking you,
giri.hi,
check these statements.
IMPORT - Get data
Variants:
1. IMPORT obj1 ... objn FROM DATA BUFFER f.
2. IMPORT obj1 ... objn FROM INTERNAL TABLE itab.
2. IMPORT obj1 ... objn FROM MEMORY.
3. IMPORT obj1 ... objn FROM SHARED MEMORY itab(ar) ID key.
4. IMPORT obj1 ... objn FROM SHARED BUFFER itab(ar) ID key.
5. IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.
6. IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.
7. IMPORT obj1 ... objn FROM LOGFILE ID key.
8. IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.
9. IMPORT (itab) FROM ... .
In some cases, the syntax rules that apply to Unicode programs are different than those for non-Unicode programs. For more details, see Storing Cluster Tables.
Variant 1
IMPORT obj1 ... objn FROM DATA BUFFER f.
Extras:
1. ... = f (for each object to be imported)
2. ... TO f (for each object to be imported)
3. ... ACCEPTING PADDING
4. ... ACCEPTING TRUNCATION
5. ... IGNORING STRUCTURE BOUNDARIES
6. ... IGNORING CONVERSION ERRORS
7. ... REPLACEMENT CHARACTER c
8. ... IN CHAR-TO-HEX MODE
9. ... CODE PAGE INTO f1
10. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See You Cannot Use Implicit Field Names in Clusters.
Effect
Imports the data objects obj1 ... objn from the data buffer declared. The data buffer must be of type XSTRING . The data objects obj1 ... objn can be fields, structures, complex structures, or tables. The system imports all the data that has been stored in the data buffer f using the EXPORT ... TO DATA BUFFER statement and is listed here. It also checks that the structure used in the IMPORT statement matches the one in the EXPORT statement.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged. (In some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported. The contents of all the objects remain unchanged.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is stored in the field f.
Addition 3
... ACCEPTING PADDING
Effect
This addition allows you to append new fields to the end
of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 4
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR
fields, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 5
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is
relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 3 (enlarge structure) or addition 4 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Addition 6
...IGNORING CONVERSION ERRORS
Effect
This addition prevents the system from triggering a
runtime error, if an error occurs when the character set is converted. '#' is used as a replacement character.
Addition 7
... REPLACEMENT CHARACTER c
Effect
The replacement character is used if a particular
character cannot be converted when the character set is converted.
This addition can only be used in conjunction with addition 6.
Addition 8
... IN CHAR-TO-HEX MODE
Effect
Not all character-type fields are converted. To convert
a field, you must create a field (or structure) that is identical to the exported field or structure, except that all its character-type components must be replaced with hexadecimal fields.
You can only use this addition in Unicode programs, to allow you to import camouflaged binary data as single-byte characters.
Moreover, you cannot use this addition in conjunction with the additions 3, 4, 5, 6, or 7.
Addition 9
... CODE PAGE INTO f1
Effect
The code page of the exported data is stored in the
character-type field f1 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition.
Addition 10
... ENDIAN INTO f2
Effect
The byte order (LITTLE or BIG) of the
exported data is stored in the field f2 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition. The field f2 must have the type ABAP_ENDIAN, which is defined in the type group ABAP. For this reason, the type group ABAP must be included in the ABAP program using a TYPE-POOLS statement.
Variant 2
IMPORT obj1 ... objn FROM INTERNAL TABLE itab.
Extras:
1. ... = f (for each object to be imported)
2. ... TO f (for each object to be imported)
3. ... ACCEPTING PADDING
4. ... ACCEPTING TRUNCATION
5. ... IGNORING STRUCTURE BOUNDARIES
6. ... IGNORING CONVERSION ERRORS
7. ... REPLACEMENT CHARACTER c
8. ... IN CHAR-TO-HEX MODE
9. ... CODE PAGE INTO f1
10. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See No implicit field names in cluster.
Effect
Imports the data objects obj1 ... objn (fields, structures, complex structures, or tables) from the specified internal table itab. The first column in the internal table must be of the predefined type INT2 and the second must be type X. To define the first column you must refer to a data element in the ABAP Dictionary that has the predefined type INT2.
All data that was stored in the internal table itab using EXPORT ... TO INTERNAL TABLE and listed, is imported. The system checks that the EXPORT and IMPORT structures match.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the specified data cluster were imported, the rest remain unchanged (it is possible that no data object was imported).
SY-SUBRC = 4:
The data objects could not be imported.
The contents of all listed objects remain unchanged
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
Places the object in the field f.
Addition 3
... ACCEPTING PADDING
Effect
This addition allows you to add new fields to the ends
of structures, even to substructures and internal tables (the additional fields are filled with initial value during the IMPORT). It also allows you to increase the size of existing fields (C, N, X, P, I1, and I2) and to map Char fields to STRING type fields or byte fields to XSTRING type fields.
Addition 4
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR
field or omit the last component on the highest level (till Release 4.6 this was possible without specifying an addition).
Addition 5
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the page order is
relevant, that is any substructures match. With this addition, the system also ignores alignment changes arising from the Unicode conversion (for example, due to subsequent insertion of named includes).
This addition rules out any subsequent structural enhancements (addition 3) or structural shortening (addition 4) because with this addition it is the structural limits and include limits that are to be ignored.
As from Release 6.10, the include information will also be stored in the dataset, so that it is possible to also check whether the includes match, that is substructures and includes (named or unnamed) are treated the same. When importing data that was exported in a Release lower than 6.10, the includes are not checked.
Addition 6
...IGNORING CONVERSION ERRORS
Effect
This addition has the effect that an error in the
character set conversion does not cause a runtime error. The system uses "#" as a replacement character.
Addition 7
... REPLACEMENT CHARACTER c
Effect
The system uses the specified replacement character if a
character cannot be converted during a character set conversion. If this addition is not specified, the system uses "#" as a replacement character.
This addition can only be used in conjunction with addition 6.
Addition 8
... IN CHAR-TO-HEX MODE
Effect
No character type fields are converted. For this you
must create a field or structure that is identical to the exported field or exported structure, except that all character type fields must be replaced with hexadecimal fields.
This addition, which is only allowed in programs with a set Unicode flag, allows you to import binary data disguised as single byte characters. This addition cannot be used in conjunction with additions 3, 4, 5, 6, and 7.
Addition 9
... CODE PAGE INTO f1
Effect
The codepage of the exported data is stored in the
character-type field f1 (for example, to be able to analyze the data imported with the addition IN CHAR-TO-HEX MODE).
Addition 10
... ENDIAN INTO f2
Effect
The byte order (LITTLE or BIG) of the
exported data is stored in the field f2 (for example, to be able analyze the data imported using the addition IN CHAR-TO-HEX MODE). The field f2 must be of type ABAP_ENDIAN, defined in type group ABAP. You must therefore include the type group ABAP in the ABAP program with a TYPE-POOLS statement.
Variant 3
IMPORT obj1 ... objn FROM MEMORY.
Extras:
1. ... = f (for each object to be imported) 2. ... TO f (for each object to be imported)
3. ... ID key
4. ... ACCEPTING PADDING
5. ... ACCEPTING TRUNCATION
6. ... IGNORING STRUCTURE BOUNDARIES
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See You Must Enter Identification and Cannot Use Implicit Field Names inClusters
Effect
Imports data objects obj1 ... objn (fields, structures, complex structures or tables) from a data cluster in the ABAP memory (see EXPORT). Reads in all data without an ID that was exported to memory with "EXPORT ... TO MEMORY.". In contrast to the variant IMPORT FROM DATABASE, it does not check that the structure matches in EXPORT and IMPORT.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because the ABAP memory was empty.
The contents of all objects remain unchanged.
Note
You should always use the addition 3 (... ID key) with the statement. Otherwise, the effect of the variant is not certain (EXPORT statements in different parts of a program overwrite each other in the ABAP memory), since it exists only for reasons of compatibility with R/2.
Additional methods for selecting and deleting data clusters in the ABAP memory are provided by the system class CL_ABAP_EXPIMP_MEM.
Please consult Data Area and Modularization Unit Organization documentation as well.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in field f.
Addition 3
... ID key
Effect
Imports only data stored in ABAP memory under the ID key.
Notes
The key, key, must be a character-type data object (but not a string).
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.
Addition 4
... ACCEPTING PADDING
Effect
This addition allows you to append new fields to the end of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 5
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR field, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 6
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 3 (enlarge structure) or addition 4 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Related
EXPORT TO MEMORY, DELETE FROM MEMORY, FREE MEMORY
Variant 4
IMPORT obj1 ... objn FROM SHARED MEMORY itab(ar) ID key.
Extras:
1. ... = f (for each object to be exported) 2. ... TO f (for each object to be exported)
3. ... CLIENT g (before ID key)
4. ... TO wa (after itab(ar) or ID key )
5. ... ACCEPTING PADDING
6. ... ACCEPTING TRUNCATION
7. ... IGNORING STRUCTURE BOUNDARIES
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See You Cannot Use Implicit Field Names in Clusters and You Cannot Use Table Work Areas.
Effect
Imports the data objects obj1 ... objn (fields, structures, complex structures, or tables) from shared memory. The data objects are read using the ID key from the area ar in the table itab - c.f. EXPORT TO SHARED MEMORY). You must use itab to specify a database table although the system reads from a memory table with the appropriate structure.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged. (In some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported. You may have used the wrong ID. The contents of all the objects remain unchanged.
Notes
The table dbtab named according to SHARED MEMORY must be declared using TABLES (except in addition 2).
The structure of fields (field symbols and internal tables) to be imported must match the structure of the objects exported in the dataset. The objects must be imported under the same names as those under which they were exported. Otherwise, they will not be imported.
The key length consists of: the client (3 digits, but only if tab is client-specific); area (2 characters); ID; and line number (4 bytes). It must not exceed 64 bytes - that is, the ID must not be longer than 55 characters, if the table is client- specific.
The key, key, must be a character-type data object (but not a string).
Additional methods for selecting and deleting data clusters in the shared memory are provided by the system class CL_ABAP_EXPIMP_SHMEM.
Please consult Data Area and Modularization Unit Organization documentation as well.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is stored in the field f.
Addition 3
... CLIENT g (before ID key)
Effect
The data is imported from client g (provided the import/export table is tab client-specific). The client, g must be a character-type data object (but not a string).
Addition 4
... TO wa (after itab(ar) or ID key)
Effect
You need to use this addition if user data fields have been stored in the application buffer and are to be read from there. The work area wa is used instead of the table work area. The target area must correspond to the structure of the called table tab.
Addition 5
... ACCEPTING PADDING
Effect
This addition allows you to: append new fields to the end of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 6
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR fields, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 7
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 4 (enlarge structure) or addition 5 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Related
EXPORT TO SHARED MEMORY, DELETE FROM SHARED MEMORY
Variant 5
IMPORT obj1 ... objn FROM SHARED BUFFER itab(ar) ID key.
Extras:
1. ... = f (for each object to be exported) 2. ... TO f (for each object to be exported)
3. ... CLIENT g (before ID key)
4. ... TO wa (last addition or after itab(ar))
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See Cannot Use Implicit Fieldnames in Clusters und Cannot Use Table Work Areas.
Effect
Imports data objects obj1 ... objn (fields or
tables) from the cross-transaction application buffer. The data objects are read in the application buffer using the ID key of the area ar of the buffer area for the table itab (see EXPORT TO SHARED BUFFER). You must use dbtab to specify a database table although the system reads from a memory table with an appropriate structure.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this means that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.
Example
Import two fields and an internal table from the application buffer with the structure INDX:
TYPES: BEGIN OF ITAB3_LINE,
CONT(4),
END OF ITAB3_LINE.
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',
F1(4),
F2(8) TYPE P DECIMALS 0,
ITAB3 TYPE STANDARD TABLE OF ITAB3_LINE,
INDX_WA TYPE INDX.
Import data.
IMPORT F1 = F1 F2 = F2 ITAB3 = ITAB3
FROM SHARED BUFFER INDX(ST) ID INDXKEY TO INDX_WA.
After import, the data fields INDX-AEDAT and
INDX-USERA in front of CLUSTR are filled with
the values in the fields before the EXPORT
statement.
Notes
You must declare the table dbtab, named after DATABASE using a TABLES statement.
The structure of the fields, structures, and internal tables to be imported must match the structure of the objects exported to the dataset. Moreover, the objects must be imported with the same name used to export them. Otherwise, the import is not performed.
The maximum total key length is 64 bytes. It must include: a client if the table is client-specific (3 characters); an area (2 characters); identification; and line counter (4 bytes). This means that the number of characters available for the identification of a client-specific table is 55 characters.
The key, key, must be a character-type data object (but not a string).
Additional methods for selecting and deleting data clusters in the cross-transaction application buffer are provided by the system class CL_ABAP_EXPIMP_SHBUF.
Please consult Data Area and Modularization Unit Organization documentation as well.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in the field f
Addition 3
... CLIENT g (after dbtab(ar))
Effect
Takes the data from the client g (if the import/export table dbtab is client-specific). The client g must be a character-type data object (but not a string).
Addition 4
... TO wa (as the last addition or after itab(ar))
Effect
You need to use this addition if you want to save user data fields in the application buffer and then read them from there later. The system uses a work area wa instead of a table work area. The target area must have the same structure as the table tab.
Example
DATA: INDX_WA TYPE INDX,
F1.
IMPORT F1 = F1 FROM SHARED BUFFER INDX(AR)
CLIENT '001' ID 'TEST'
TO INDX_WA.
WRITE: / 'AEDAT:', INDX_WA-AEDAT,
/ 'USERA:', INDX_WA-USERA,
/ 'PGMID:', INDX_WA-PGMID.
Variant 6
IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.
Extras:
1. ... = f (for each object to be imported)
2. ... TO f (for each object to be imported)
3. ... CLIENT g (before ID key )
4. ... USING form
5. ... TO wa (last addition or after dbtab(ar))
6. ... MAJOR-ID id1 (instead of ID key)
7. ... MINOR-ID id2 (with MAJOR-ID id1 )
8. ... ACCEPTING PADDING
9. ... ACCEPTING TRUNCATION
10. ... IGNORING STRUCTURE BOUNDARIES
11. ... IGNORING CONVERSION ERRORS
12. ... REPLACEMENT CHARACTER c
13. ... IN CHAR-TO-HEX MODE
14. ... CODE PAGE INTO f1
15. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Implicit Fieldnames in Clusters and Cannot Use Table Work Areas.
Effect
Imports data objects obj1 ... objn (fields, structures, complex structures, or tables) from the data cluster with ID key in area ar of the database table dbtab (see EXPORT TO DATABASE).
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that not data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.
Example
Import two fields and an internal table:
TYPES: BEGIN OF TAB3_TYPE,
CONT(4),
END OF TAB3_TYPE.
DATA: INDXKEY LIKE INDX-SRTFD,
F1(4), F2 TYPE P,
TAB3 TYPE STANDARD TABLE OF TAB3_TYPE WITH
NON-UNIQUE DEFAULT KEY,
WA_INDX TYPE INDX.
INDXKEY = 'INDXKEY'.
IMPORT F1 = F1
F2 = F2
TAB3 = TAB3 FROM DATABASE INDX(ST) ID INDXKEY
TO WA_INDX.
Notes
You must declare the table dbtab, named after DATABASE, using the TABLES statement (except in addition 5).
The structure of fields, field strings and internal tables to be imported must match the structure of the objects exported to the dataset. In addition, the objects must be imported under the same name used to export them. If this is not the case, either a runtime error occurs or no import takes place.
Exception: You can lengthen or shorten the last field if it is of type CHAR, or add/omit CHAR fields at the end of the structure.
The key, key, must be a character-type data object (but not a string).
Additional methods for selecting and deleting data clusters in the database table specified are provided by the system class CL_ABAP_EXPIMP_DB.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in field f.
Addition 3
... CLIENT g (before the ID key)
Effect
Data is taken from the client g (in client-specific import/export databases only). Client g must be a character-type data object (but not a string).
Example
DATA: F1,
WA_INDX TYPE INDX.
IMPORT F1 = F1 FROM DATABASE INDX(AR) CLIENT '002' ID 'TEST'
TO WA_INDX.
Addition 4
... USING form
Note
This statement is for internal use only.
Incompatible changes or further developments may occur at any time without warning or notice.
Effect
Does not read the data from the database. Instead, calls the FORM routine form for each record read from the database without this addition. This routine can take the data key of the data to be retrieved from the database table work area and write the retrieved data to this work area. The name of the routine has the format <name of database table>_<name of form>; it has one parameter which describes the operation (READ, UPDATE or INSERT). The routine must set the field SY-SUBRC in order to show whether the function was successfully performed.
Addition 5
... TO wa (after key or after dbtab(ar))
Effect
You need to use this addition if you want to save user data fields in the cluster database and then read from there. The system uses the work area wa instead of a table work area. The target area entered must have the same structure as the table dbtab.
Example
DATA WA LIKE INDX.
DATA F1.
IMPORT F1 = F1 FROM DATABASE INDX(AR)
CLIENT '002' ID 'TEST'
TO WA.
WRITE: / 'AEDAT:', WA-AEDAT,
/ 'USERA:', WA-USERA,
/ 'PGMID:', WA-PGMID.
Addition 6
... MAJOR-ID id1 (instead of the ID key).
Addition 7
... MINOR-ID id2 (with MAJOR-ID id1)
This addition is not allowed in an ABAP Objects context. See Cannot Use Generic Identification.
Effect
Searches for a record the first part of whose ID (length of id1) matches id1 and whose second part - if MINOR-ID id2 is also declared - is greater than or equal to id2.
Addition 8
... ACCEPTING PADDING
Effect
This addition allows you to append new fields to the end of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 9
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR fields, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 10
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 8 (enlarge structure) or addition 9 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Addition 11
...IGNORING CONVERSION ERRORS
Effect
This addition prevents the system from triggering a runtime error, if an error occurs when the character set is converted. '#' is used as a replacement character.
Addition 12
... REPLACEMENT CHARACTER c
Effect
The replacement character is used if a particular character cannot be converted when the character set is converted. If you do not use this addition, '#' is used as a replacement character.
This addition can only be used in conjunction with addition 11.
Addition 13
... IN CHAR-TO-HEX MODE
Effect
All character-type fields are not converted. To convert a field, you must create a field (or structure) that is identical to the exported field or structure, except that all its character-type components must be replaced with hexadecimal fields.
You can only use this addition in Unicode programs, to allow you to import camouflaged binary data as single-byte characters. Moreover, you cannot use this addition in conjunction with the additions 8, 9, 10, 11, and 12.
Addition 14
... CODE PAGE INTO f1
Effect
The code page of the exported data is stored in the character-type field f1 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition.
Addition 15
... ENDIAN INTO f2
Effect
The byte order(LITTLE or BIG) of the exported data is stored in the field f2 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition. The field f2 must have the type ABAP_ENDIAN, which is defined in the type group ABAP. For this reason, the type group ABAP must be included in the ABAP program using a TYPE-POOLS statement.
Variant 7
IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.
This variant is not allowed in an ABAP Objects context. See Cannot Use Clusters in Files
Note
This variant is no longer supported and cannot be used.
Variant 8
IMPORT obj1 ... objn FROM LOGFILE ID key.
Note
This statement is for internal use only.
Incompatible changes or further developments may occur at any time without warning or notice.
Extras:
1. ... = f (for each field f to be imported) 2. ... TO f (for each field f to be imported)
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Implicit Field Names in Clusters
Effect
Imports data objects (fields, field strings or internal tables) from the update data. You must specify the update key assigned by the system (with current request number) as the key.
The key, key, must be a character-type data object (but not a string).
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported. An incorrect ID may have been used.
The contents of all objects remain unchanged.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in field f.
Variant 9
IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.
Extras:
1. ... CLIENT g (after dbtab(ar)) 2. ... TO wa (last addition or after dbtab(ar))
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Table Work Areas.
Effect
Imports an object directory stored under the specified ID with EXPORT TO DATABASE into the table itab. The internal table itab may not have the type HASHED TABLE or ANY TABLE.
The key, key, must be a character-type data object (but not a string).
The Return Code is set as follows:
SY-SUBRC = 0:
The directory was successfully imported.
SY-SUBRC = 4:
The directory could not be imported, probably because an incorrect ID was used.
The internal table itab must have the same structure as the Dictionary structure CDIR (INCLUDE STRUCTURE).
Addition 1
... CLIENT g (before ID key)
Effect
Takes data from the client g (only with client-specific import/export databases). Client g must be a character-type data object (but not a string).
Addition 2
... TO wa (last addition or after dbtab(ar))
Effect
Uses the work area wa instead of the table work area. When you use this addition, you do not need to declare the table dbtab, named after DATABASE using a TABLES statement. The work area entered must have the same structure as the table dbtab.
Example
Directory of a cluster consisting of two fields and an internal table:
TYPES: BEGIN OF TAB3_LINE,
CONT(4),
END OF TAB3_LINE,
BEGIN OF DIRTAB_LINE.
INCLUDE STRUCTURE CDIR.
TYPES END OF DIRTAB_LINE.
DATA: INDXKEY LIKE INDX-SRTFD,
F1(4),
F2(8) TYPE P decimals 0,
TAB3 TYPE STANDARD TABLE OF TAB3_LINE,
DIRTAB TYPE STANDARD TABLE OF DIRTAB_LINE,
INDX_WA TYPE INDX.
INDXKEY = 'INDXKEY'.
EXPORT F1 = F1
F2 = F2
TAB3 = TAB3
TO DATABASE INDX(ST) ID INDXKEY " TAB3 has 17 entries
FROM INDX_WA.
IMPORT DIRECTORY INTO DIRTAB FROM DATABASE INDX(ST) ID INDXKEY
TO INDX_WA.
Then, the table DIRTAB contains the following:
NAME OTYPE FTYPE TFILL FLENG
F1 F C 0 4
F2 F P 0 8
TAB3 T C 17 4
The meaning of the individual fields is as follows:
NAME:
Name of stored object
OTYPE:
Object type (F: Field, R: Field string / Dictionary struc -
Import Data from Office Control (Web Dynpro for ABAP) into internal-Table
Hello,
I have a question concerning the Office Control UI-Eelement in Web Dynpro for ABAP:
How can I import spreadsheet data from the Office Control into a internal-table?
I have an Excel-sheet (without any data) which is shown initially in the Office Control. First the empty Excel-Sheet will be loaded and in the second step data from an alvxml-transformation will be loaded into the Excel-sheet with the method 'activatexmlsource'. This works so far. When I change the loaded data in the Office Control and save it it will be stored as XLS-File. The problem is that I'm not able to use existing Upload-FM because every function module I tried uses GUI-functions and WebDynpro has no GUI-functionality. I always get the error that data from clipboard cannot be imported.
So now the question is:
How can I import changed data from the Office control into a internal-table staying in Web Dynpro application?
Please give some advice, if you have some useful code or ideas.
Thanks
ram
Edited by: Ramakullay Challa on Sep 24, 2009 9:05 AM
Edited by: Ramakullay Challa on Sep 24, 2009 9:07 AMHi,
Once you save to desktop again you have made some changes to that file, this file you want to upload it right.
Then in that case you need to use the FILEUPLOAD UI element right.
Regards,
Lekha. -
Hi
I have a requirement of writing internal table data to XML. Any idea where i should start.
I have pretty good experience with ABAP and basic knowledge in XML.
There are good blogs which talk about transformations and other stuff but they are not able to give me clear path to my solution.
Could somebody give me a basic example or some reference material where i can move the data in internal table (assume Sales order details of a day) to XML.
ThanksRefer the program -
In this implementation we will only focus on the creation of the XML file and the transfer to the user. You can not create a XML document directly. You have to use a so called ixml factory first.
TYPE-POOLS: ixml.
DATA: l_ixml TYPE REF TO if_ixml.
l_ixml = cl_ixml=>create( ).
This iXML factory can create an empty XML document object named l_document.
DATA: l_document TYPE REF TO if_ixml_document.
l_document = l_ixml->create_document( ).
At this point you can add the nodes (elements, attributes) into the document. First you have to declare the root element node.
DATA: l_element_root TYPE REF TO if_ixml_element.
This node we have to give a name and add it (create_simple_node) to the document object l_document, which will be the parent of this node.
l_element_root = l_document->create_simple_element(
name = 'flights'
parent = l_document ).
Next we can add child nodes to there parent node using the same method of the document object.
DATA: l_element_airline TYPE REF TO if_ixml_element,
l_element_airline = l_document->create_simple_element(
name = 'airline'
parent = l_element_root ).
An attribute can be add easily using the method set_attribute of the element node.
l_rc = l_element_airline->set_attribute( name = 'code' value = 'LH401' ).
Now we have finished the document object. Regretfully it can not be displayed in any form due to the fact that it is a binary object.
The next step is to convert the created document to a flat file. To achieve this we have to create a stream factory, which will help us to create an output stream.
DATA: l_streamfactory TYPE REF TO if_ixml_stream_factory.
l_streamfactory = l_ixml->create_stream_factory( ).
In this case, we will convert the document into an output stream which is based on an internal table of type x.
TYPES: BEGIN OF xml_line,
data(256) TYPE x,
END OF xml_line.
DATA: l_xml_table TYPE TABLE OF xml_line,
l_xml_size TYPE i,
l_rc TYPE i,
l_ostream TYPE REF TO if_ixml_ostream.
l_ostream = l_streamfactory->create_ostream_itable( table = l_xml_table ).
When we have created the output stream we can do the rendering from the document into the stream. The XML data will be stored in the internal table automatically.
DATA: l_renderer TYPE REF TO if_ixml_renderer.
l_renderer = l_ixml->create_renderer( ostream = l_ostream
& nbsp; document = l_document ).
l_rc = l_renderer->render( ).
In the last step we upload the file to the sapgui
l_xml_size = l_ostream->get_num_written_raw( ).
CALL METHOD cl_gui_frontend_services=>gui_download
EXPORTING
bin_filesize = l_xml_size
filename = 'c:\temp\flights.xml'
filetype = 'BIN'
CHANGING
data_tab = l_xml_table
EXCEPTIONS
OTHERS = 24.
This finished the first step-of-three. As mentioned before the next log will focus on the conversion from xml files (back) to abap tables.
REPORT z_xit_xml_dom_create.
TYPE-POOLS: ixml.
TYPES: BEGIN OF xml_line,
data(256) TYPE x,
END OF xml_line.
DATA: l_ixml TYPE REF TO if_ixml,
l_streamfactory TYPE REF TO if_ixml_stream_factory,
l_ostream TYPE REF TO if_ixml_ostream,
l_renderer TYPE REF TO if_ixml_renderer,
l_document TYPE REF TO if_ixml_document.
DATA: l_element_flights TYPE REF TO if_ixml_element,
l_element_airline TYPE REF TO if_ixml_element,
l_element_flight TYPE REF TO if_ixml_element,
l_element_from TYPE REF TO if_ixml_element,
l_element_to TYPE REF TO if_ixml_element,
l_element_dummy TYPE REF TO if_ixml_element,
l_value TYPE string.
DATA: l_xml_table TYPE TABLE OF xml_line,
l_xml_size TYPE i,
l_rc TYPE i.
DATA: lt_spfli TYPE TABLE OF spfli.
DATA: l_spfli TYPE spfli.
START-OF-SELECTION.
Fill the internal table
SELECT * FROM spfli INTO TABLE lt_spfli.
Sort internal table
SORT lt_spfli BY carrid.
Start filling xml dom object from internal table
LOOP AT lt_spfli INTO l_spfli.
AT FIRST.
Creating a ixml factory
l_ixml = cl_ixml=>create( ).
Creating the dom object model
l_document = l_ixml->create_document( ).
Fill root node with value flights
l_element_flights = l_document->create_simple_element(
name = 'flights'
parent = l_document ).
ENDAT.
AT NEW carrid.
Create element 'airline' as child of 'flights'
l_element_airline = l_document->create_simple_element(
name = 'airline'
parent = l_element_flights ).
Create attribute 'code' of node 'airline'
l_value = l_spfli-carrid.
l_rc = l_element_airline->set_attribute( name = 'code' value = l_value ).
Create attribute 'name' of node 'airline'
SELECT SINGLE carrname FROM scarr INTO l_value WHERE carrid EQ l_spfli-carrid.
l_rc = l_element_airline->set_attribute( name = 'name' value = l_value ).
ENDAT.
AT NEW connid.
Create element 'flight' as child of 'airline'
l_element_flight = l_document->create_simple_element(
name = 'flight'
parent = l_element_airline ).
Create attribute 'number' of node 'flight'
l_value = l_spfli-connid.
l_rc = l_element_flight->set_attribute( name = 'number' value = l_value ).
ENDAT.
Create element 'from' as child of 'flight'
CONCATENATE l_spfli-cityfrom ',' l_spfli-countryfr INTO l_value.
l_element_from = l_document->create_simple_element(
name = 'from'
value = l_value
parent = l_element_flight ).
Create attribute 'airport' of node 'from'
l_value = l_spfli-airpfrom.
l_rc = l_element_from->set_attribute( name = 'airport' value = l_value ).
Create element 'to' as child of 'flight'
CONCATENATE l_spfli-cityto ',' l_spfli-countryto INTO l_value.
l_element_to = l_document->create_simple_element(
name = 'to'
value = l_value
parent = l_element_flight ).
Create attribute 'airport' of node 'from'
l_value = l_spfli-airpto.
l_rc = l_element_to->set_attribute( name = 'airport' value = l_value ).
Create element 'departure' as child of 'flight'
l_value = l_spfli-deptime.
l_element_dummy = l_document->create_simple_element(
name = 'departure'
value = l_value
parent = l_element_flight ).
Create element 'arrival' as child of 'flight'
l_value = l_spfli-arrtime.
l_element_dummy = l_document->create_simple_element(
name = 'arrival'
value = l_value
parent = l_element_flight ).
Create element 'type' as child of 'flight'
CASE l_spfli-fltype.
WHEN 'X'.
l_value = 'Charter'.
WHEN OTHERS.
l_value = 'Scheduled'.
ENDCASE.
l_element_dummy = l_document->create_simple_element(
name = 'type'
value = l_value
parent = l_element_flight ).
ENDLOOP.
IF sy-subrc NE 0.
MESSAGE 'No data into db table ''spfli'', please run program ''SAPBC_DATA_GENERATOR'' with transaction ''SA38''' TYPE 'E'.
ENDIF.
Creating a stream factory
l_streamfactory = l_ixml->create_stream_factory( ).
Connect internal XML table to stream factory
l_ostream = l_streamfactory->create_ostream_itable( table = l_xml_table ).
Rendering the document
l_renderer = l_ixml->create_renderer( ostream = l_ostream
document = l_document ).
l_rc = l_renderer->render( ).
Saving the XML document
l_xml_size = l_ostream->get_num_written_raw( ).
CALL METHOD cl_gui_frontend_services=>gui_download
EXPORTING
bin_filesize = l_xml_size
filename = 'c:\temp\flights.xml'
filetype = 'BIN'
CHANGING
data_tab = l_xml_table
EXCEPTIONS
OTHERS = 24.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
<?xml version="1.0"?>
<flights>
<airline code="AA" name="American Airlines">
<flight number="0017">
<from airport="JFK">NEW YORK,US</from>
<to airport="SFO">SAN FRANCISCO,US</to>
<departure>110000</departure>
<arrival>140100</arrival>
<type>Scheduled</type>
</flight>
<flight number="0064">
<from airport="SFO">SAN FRANCISCO,US</from>
<to airport="JFK">NEW YORK,US</to>
<departure>090000</departure>
<arrival>172100</arrival>
<type>Scheduled</type>
</flight>
</airline>
<airline code="AZ" name="Alitalia">
<flight number="0555">
<from airport="FCO">ROME,IT</from>
<to airport="FRA">FRANKFURT,DE</to>
<departure>190000</departure>
<arrival>210500</arrival>
<type>Scheduled</type>
</flight>
<flight number="0788">
<from airport="FCO">ROME,IT</from>
<to airport="TYO">TOKYO,JP</to>
<departure>120000</departure>
<arrival>085500</arrival>
<type>Scheduled</type>
</flight>
<flight number="0789">
<from airport="TYO">TOKYO,JP</from>
<to airport="FCO">ROME,IT</to>
<departure>114500</departure>
<arrival>192500</arrival>
<type>Scheduled</type>
</flight>
<flight number="0790">
<from airport="FCO">ROME,IT</from>
<to airport="KIX">OSAKA,JP</to>
<departure>103500</departure>
<arrival>081000</arrival>
<type>Charter</type>
</flight>
</airline>
<airline code="DL" name="Delta Airlines">
<flight number="1984">
<from airport="SFO">SAN FRANCISCO,US</from>
<to airport="JFK">NEW YORK,US</to>
<departure>100000</departure>
<arrival>182500</arrival>
<type>Scheduled</type>
</flight>
<flight number="1699">
<from airport="JFK">NEW YORK,US</from>
<to airport="SFO">SAN FRANCISCO,US</to>
<departure>171500</departure>
<arrival>203700</arrival>
<type>Scheduled</type>
</flight>
<flight number="0106">
<from airport="JFK">NEW YORK,US</from>
<to airport="FRA">FRANKFURT,DE</to>
<departure>193500</departure>
<arrival>093000</arrival>
<type>Scheduled</type>
</flight>
</airline>
<airline code="JL" name="Japan Airlines">
<flight number="0407">
<from airport="NRT">TOKYO,JP</from>
<to airport="FRA">FRANKFURT,DE</to>
<departure>133000</departure>
<arrival>173500</arrival>
<type>Scheduled</type>
</flight>
<flight number="0408">
<from airport="FRA">FRANKFURT,DE</from>
<to airport="NRT">TOKYO,JP</to>
<departure>202500</departure>
<arrival>154000</arrival>
<type>Charter</type>
</flight>
</airline>
<airline code="LH" name="Lufthansa">
<flight number="2407">
<from airport="TXL">BERLIN,DE</from>
<to airport="FRA">FRANKFURT,DE</to>
<departure>071000</departure>
<arrival>081500</arrival>
<type>Scheduled</type>
</flight>
<flight number="2402">
<from airport="FRA">FRANKFURT,DE</from>
<to airport="SXF">BERLIN,DE</to>
<departure>103000</departure>
<arrival>113500</arrival>
<type>Scheduled</type>
</flight>
<flight number="0402">
<from airport="FRA">FRANKFURT,DE</from>
<to airport="JFK">NEW YORK,US</to>
<departure>133000</departure>
<arrival>150500</arrival>
<type>Charter</type>
</flight>
<flight number="0401">
<from airport="JFK">NEW YORK,US</from>
<to airport="FRA">FRANKFURT,DE</to>
<departure>183000</departure>
<arrival>074500</arrival>
<type>Scheduled</type>
</flight>
<flight number="0400">
<from airport="FRA">FRANKFURT,DE</from>
<to airport="JFK">NEW YORK,US</to>
<departure>101000</departure>
<arrival>113400</arrival>
<type>Scheduled</type>
</flight>
</airline>
<airline code="QF" name="Qantas Airways">
<flight number="0005">
<from airport="SIN">SINGAPORE,SG</from>
<to airport="FRA">FRANKFURT,DE</to>
<departure>225000</departure>
<arrival>053500</arrival>
<type>Scheduled</type>
</flight>
<flight number="0006">
<from airport="FRA">FRANKFURT,DE</from>
<to airport="SIN">SINGAPORE,SG</to>
<departure>205500</departure>
<arrival>150500</arrival>
<type>Scheduled</type>
</flight>
</airline>
<airline code="SQ" name="Singapore Airlines">
<flight number="0988">
<from airport="SIN">SINGAPORE,SG</from>
<to airport="TYO">TOKYO,JP</to>
<departure>163500</departure>
<arrival>001500</arrival>
<type>Scheduled</type>
</flight>
<flight number="0158">
<from airport="SIN">SINGAPORE,SG</from>
<to airport="JKT">JAKARTA,ID</to>
<departure>152500</departure>
<arrival>160000</arrival>
<type>Scheduled</type>
</flight>
<flight number="0015">
<from airport="SFO">SAN FRANCISCO,US</from>
<to airport="SIN">SINGAPORE,SG</to>
<departure>160000</departure>
<arrival>024500</arrival>
<type>Scheduled</type>
</flight>
<flight number="0002">
<from airport="SIN">SINGAPORE,SG</from>
<to airport="SFO">SAN FRANCISCO,US</to>
<departure>170000</departure>
<arrival>192500</arrival>
<type>Scheduled</type>
</flight>
</airline>
<airline code="UA" name="United Airlines">
<flight number="0941">
<from airport="FRA">FRANKFURT,DE</from>
<to airport="SFO">SAN FRANCISCO,US</to>
<departure>143000</departure>
<arrival>170600</arrival>
<type>Scheduled</type>
</flight>
<flight number="3504">
<from airport="SFO">SAN FRANCISCO,US</from>
<to airport="FRA">FRANKFURT,DE</to>
<departure>150000</departure>
<arrival>103000</arrival>
<type>Scheduled</type>
</flight>
<flight number="3516">
<from airport="JFK">NEW YORK,US</from>
<to airport="FRA">FRANKFURT,DE</to>
<departure>162000</departure>
<arrival>054500</arrival>
<type>Scheduled</type>
</flight>
<flight number="3517">
<from airport="FRA">FRANKFURT,DE</from>
<to airport="JFK">NEW YORK,US</to>
<departure>104000</departure>
<arrival>125500</arrival>
<type>Scheduled</type>
</flight>
</airline>
</flights>
Regards,
Amit
Reward all helpful replies. -
Internal Table attached as Excel file to an eMail - BCS_EXAMPLE_7 for UC
Hi forums,
SAP provided an example report to send out internal tables attached as an Excel file to a recipients eMail address. I attached the coding of the BCS_EXAMPLE_7 programm to this thread.
report bcs_example_7.
This report provides an example for sending an Excel
attachment in Unicode Systems
constants:
gc_tab type c value cl_bcs_convert=>gc_tab,
gc_crlf type c value cl_bcs_convert=>gc_crlf.
parameters:
mailto type ad_smtpadr
default 'john.doe(a)crazy-company.com'. "#EC *
data send_request type ref to cl_bcs.
data document type ref to cl_document_bcs.
data recipient type ref to if_recipient_bcs.
data bcs_exception type ref to cx_bcs.
data main_text type bcsy_text.
data binary_content type solix_tab.
data size type so_obj_len.
data sent_to_all type os_boolean.
start-of-selection.
perform create_content.
perform send.
*& Form send
form send.
try.
-------- create persistent send request ------------------------
send_request = cl_bcs=>create_persistent( ).
-------- create and set document with attachment ---------------
create document object from internal table with text
append 'Hello world!' to main_text. "#EC NOTEXT
document = cl_document_bcs=>create_document(
i_type = 'RAW'
i_text = main_text
i_subject = 'Test Created By BCS_EXAMPLE_7' ). "#EC NOTEXT
add the spread sheet as attachment to document object
document->add_attachment(
i_attachment_type = 'xls' "#EC NOTEXT
i_attachment_subject = 'ExampleSpreadSheet' "#EC NOTEXT
i_attachment_size = size
i_att_content_hex = binary_content ).
add document object to send request
send_request->set_document( document ).
--------- add recipient (e-mail address) -----------------------
create recipient object
recipient = cl_cam_address_bcs=>create_internet_address( mailto ).
add recipient object to send request
send_request->add_recipient( recipient ).
---------- send document ---------------------------------------
sent_to_all = send_request->send( i_with_error_screen = 'X' ).
commit work.
if sent_to_all is initial.
message i500(sbcoms) with mailto.
else.
message s022(so).
endif.
------------ exception handling ----------------------------------
replace this rudimentary exception handling with your own one !!!
catch cx_bcs into bcs_exception.
message i865(so) with bcs_exception->error_type.
endtry.
endform. "send
*& Form create_content
Create Example Content
1) Write example text into a string
2) convert this string to solix_tab
form create_content.
data lv_string type string.
data ls_t100 type t100.
as example content we use some system messages out of t100
get them for all installed languages from db
and write one line for each language into the spread sheet
columns are separated by TAB and each line ends with CRLF
concatenate 'This Is Just Example Text!' "#EC NOTEXT
gc_crlf gc_crlf
into lv_string.
header line
concatenate lv_string
'MSGID' gc_tab
'MSGNO' gc_tab
'Language' gc_tab "#EC NOTEXT
'Text' gc_crlf "#EC NOTEXT
into lv_string.
data lines
select * from t100 into ls_t100
where arbgb = 'SO' and msgnr = '182'.
concatenate lv_string
ls_t100-arbgb gc_tab
ls_t100-msgnr gc_tab
ls_t100-sprsl gc_tab
ls_t100-text gc_crlf
into lv_string.
endselect.
select * from t100 into ls_t100
where arbgb = 'SO' and msgnr = '316'.
concatenate lv_string
ls_t100-arbgb gc_tab
ls_t100-msgnr gc_tab
ls_t100-sprsl gc_tab
ls_t100-text gc_crlf
into lv_string.
endselect.
convert the text string into UTF-16LE binary data including
byte-order-mark. Mircosoft Excel prefers these settings
all this is done by new class cl_bcs_convert (see note 1151257)
try.
cl_bcs_convert=>string_to_solix(
exporting
iv_string = lv_string
iv_codepage = '4103' "suitable for MS Excel, leave empty
iv_add_bom = 'X' "for other doc types
importing
et_solix = binary_content
ev_size = size ).
catch cx_bcs.
message e445(so).
endtry.
endform. "create_content
NOTES:
UTF-16LE including the BOM (Byte order mark)
is preferred by Microsoft Excel. If you want to create
other binary content you may choose another codepage (e.g.
'4110' (UTF-8) which is standard for e-mails).
Find SAP codepage names in the drop down list
for the codepage setting of node SMTP in transaction SCOT.
Or: leave iv_codepage and iv_add_bom empty. Then the target
codepage is set according to SAPconnect settings
Important:
SAP neither guarantees that the attachment created
by this report can be opened by all Excel Versions nor
that it can be opened by any 3rd party software at all
Best regards to you
Thorsten Hüser
SAP CRM Senior consultant
arvato / BertelsmannHi forums,
SAP provided an example report to send out internal tables attached as an Excel file to a recipients eMail address. I attached the coding of the BCS_EXAMPLE_7 programm to this thread.
report bcs_example_7.
This report provides an example for sending an Excel
attachment in Unicode Systems
constants:
gc_tab type c value cl_bcs_convert=>gc_tab,
gc_crlf type c value cl_bcs_convert=>gc_crlf.
parameters:
mailto type ad_smtpadr
default 'john.doe(a)crazy-company.com'. "#EC *
data send_request type ref to cl_bcs.
data document type ref to cl_document_bcs.
data recipient type ref to if_recipient_bcs.
data bcs_exception type ref to cx_bcs.
data main_text type bcsy_text.
data binary_content type solix_tab.
data size type so_obj_len.
data sent_to_all type os_boolean.
start-of-selection.
perform create_content.
perform send.
*& Form send
form send.
try.
-------- create persistent send request ------------------------
send_request = cl_bcs=>create_persistent( ).
-------- create and set document with attachment ---------------
create document object from internal table with text
append 'Hello world!' to main_text. "#EC NOTEXT
document = cl_document_bcs=>create_document(
i_type = 'RAW'
i_text = main_text
i_subject = 'Test Created By BCS_EXAMPLE_7' ). "#EC NOTEXT
add the spread sheet as attachment to document object
document->add_attachment(
i_attachment_type = 'xls' "#EC NOTEXT
i_attachment_subject = 'ExampleSpreadSheet' "#EC NOTEXT
i_attachment_size = size
i_att_content_hex = binary_content ).
add document object to send request
send_request->set_document( document ).
--------- add recipient (e-mail address) -----------------------
create recipient object
recipient = cl_cam_address_bcs=>create_internet_address( mailto ).
add recipient object to send request
send_request->add_recipient( recipient ).
---------- send document ---------------------------------------
sent_to_all = send_request->send( i_with_error_screen = 'X' ).
commit work.
if sent_to_all is initial.
message i500(sbcoms) with mailto.
else.
message s022(so).
endif.
------------ exception handling ----------------------------------
replace this rudimentary exception handling with your own one !!!
catch cx_bcs into bcs_exception.
message i865(so) with bcs_exception->error_type.
endtry.
endform. "send
*& Form create_content
Create Example Content
1) Write example text into a string
2) convert this string to solix_tab
form create_content.
data lv_string type string.
data ls_t100 type t100.
as example content we use some system messages out of t100
get them for all installed languages from db
and write one line for each language into the spread sheet
columns are separated by TAB and each line ends with CRLF
concatenate 'This Is Just Example Text!' "#EC NOTEXT
gc_crlf gc_crlf
into lv_string.
header line
concatenate lv_string
'MSGID' gc_tab
'MSGNO' gc_tab
'Language' gc_tab "#EC NOTEXT
'Text' gc_crlf "#EC NOTEXT
into lv_string.
data lines
select * from t100 into ls_t100
where arbgb = 'SO' and msgnr = '182'.
concatenate lv_string
ls_t100-arbgb gc_tab
ls_t100-msgnr gc_tab
ls_t100-sprsl gc_tab
ls_t100-text gc_crlf
into lv_string.
endselect.
select * from t100 into ls_t100
where arbgb = 'SO' and msgnr = '316'.
concatenate lv_string
ls_t100-arbgb gc_tab
ls_t100-msgnr gc_tab
ls_t100-sprsl gc_tab
ls_t100-text gc_crlf
into lv_string.
endselect.
convert the text string into UTF-16LE binary data including
byte-order-mark. Mircosoft Excel prefers these settings
all this is done by new class cl_bcs_convert (see note 1151257)
try.
cl_bcs_convert=>string_to_solix(
exporting
iv_string = lv_string
iv_codepage = '4103' "suitable for MS Excel, leave empty
iv_add_bom = 'X' "for other doc types
importing
et_solix = binary_content
ev_size = size ).
catch cx_bcs.
message e445(so).
endtry.
endform. "create_content
NOTES:
UTF-16LE including the BOM (Byte order mark)
is preferred by Microsoft Excel. If you want to create
other binary content you may choose another codepage (e.g.
'4110' (UTF-8) which is standard for e-mails).
Find SAP codepage names in the drop down list
for the codepage setting of node SMTP in transaction SCOT.
Or: leave iv_codepage and iv_add_bom empty. Then the target
codepage is set according to SAPconnect settings
Important:
SAP neither guarantees that the attachment created
by this report can be opened by all Excel Versions nor
that it can be opened by any 3rd party software at all
Best regards to you
Thorsten Hüser
SAP CRM Senior consultant
arvato / Bertelsmann -
How to use internal table in Exporting Parameter of method.
Hi Friends,
I am new to abap oops and using the following code to read a select-option and pass the data in an internal table but on defining
internal table of a standard type it is giving me following error :
ITAB is not an internal table - the OCCURS n specification is missing.
code
====
class lcl_get_details DEFINITION.
PUBLIC SECTION.
types : r_carrid type RANGE OF sflight-carrid.
data : itab type STANDARD TABLE OF sflight.
METHODS : get_data IMPORTING s_carrid type R_carrid
EXPORTING itab type sflight.
ENDCLASS.
class lcl_get_details IMPLEMENTATION.
METHOD get_data.
select *
from sflight
into table itab
where carrid in s_carrid.
if sy-subrc eq 0.
sort itab by carrid.
endif.
endmethod.
ERROR : ITAB is not an internal table - the OCCURS n specification is missing.
Kindly help.Hi,
I think your problem is, because you use 2 variables named ITAB in method get_data.
Instance-variable ITAB is defined as STANDARD TABLE OF sflight.
Exporting-parameter ITAB is defined as sflight.
It seems like in implementation of get_data exporting-parameter ITAB is used.
Try this implementation:
METHOD get_data.
select * from sflight into table me->itab
where carrid in s_carrid.
if sy-subrc eq 0.
sort me->itab by carrid.
endif.
ENDMETHOD.
This should solve your compiler error.
Nether the less, get_data will yield an empty structure as result.
Regards, Hubert
Edited by: Hubert Heitzer on Feb 24, 2010 10:22 AM
Maybe you are looking for
-
This problem is a recent one (only has happened in the past 2-3 weeks). When I shut the lid it used to immediately sleep (the power light began to do its fade in and out, and the backlight turned off), but now when I close the lid, the power light st
-
Path problem while refering the file in tomcat
In the jsp file i am going to update one property file which resides in the same folder using file output stream. it gives path problem.how can refer the path of that file
-
How can I join pages in pdf file?
There is a pdf document which contains 6 pages. I want to place the content of the document on one page pdf (of course, with decreasing the size of pictures) in needed order - like assembling a 2x3 puzzle. Does Acrobat have such feature? If yes, how
-
I've been trying to reset the battery gauge on my Thinkpad X301 (Windows 7). The reset function does run the battery down and then recharge it, but the test is never officially ended, even when left running for days. The Battery Maintenance windows r
-
Adpreclone.pl Non-interactive Mode
Hi All, want to automate backup of APPL tier To do that it is required to run adpreclone.pl with non-interactive mode i.e. It will not ask for any password when it will run through shell script. Or something like perl adpreclone.pl appsTier pwd=<> Is