Global Class that returns an internal table

Hello,
 Is it possible to create a global class (under class builder) that returns an internal table like we used to do in a function module?
 e.g. call function '<Function module name>'
 tables = i_tab.
Thanks,
Jeffrey

Hi Jeffrey,
Yeah u can do that by specifying importing parameters
to method.You can give table type for the parameters.
Thanks&Regards,
Siri.

Similar Messages

How to return an internal table with methods ?

Hi,
I am an Java programmer and very new to ABAP.
How do I return a internal table with a method? I have the table GP1_PRODUCTS and want to return a copy of this table as an internal table called PRODUCTS.
Here is my code that does not work:
class PRODUCTS definition
public
final
create public .
public section.
*"* public components of class PRODUCTS
*"* do not include other source files here!!!
methods GET_PRODUCT_LIST
 returning
 value(PRODUCTS) type GP1_PRODUCTS .
protected section.
*"* protected components of class PRODUCTS
*"* do not include other source files here!!!
private section.
*"* private components of class PRODUCTS
*"* do not include other source files here!!!
ENDCLASS.
CLASS PRODUCTS IMPLEMENTATION.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method PRODUCTS->GET_PRODUCT_LIST
* +-------------------------------------------------------------------------------------------------+
* | [<-()] PRODUCTS TYPE GP1_PRODUCTS
* +--------------------------------------------------------------------------------------</SIGNATURE>
method GET_PRODUCT_LIST.
DATA: it_products TYPE STANDARD TABLE OF GP1_PRODUCTS.
select * from GP1_PRODUCTS into table it_products.
PRODUCTS = it_products.
endmethod.
ENDCLASS.

You have to create a table type for your table GP1_PRODUCTS.
If you use global class (created in SE24), than:
Create a Table Type in SE11
Go to SE11, Enter a name like ZPRODUCTS in the Data Type
There will be popup when you press the Create button to decide a type. Select the Table Type
Enter GP1_PRODUCTS in the Line Type.
* method declaration
methods GET_PRODUCT_LIST
 returning
 value(PRODUCTS) type ZPRODUCTS.
If you use local class:
TYPES: ty_products type standard table of GP1_PRODUCTS..
* method declaration
methods GET_PRODUCT_LIST
 returning
 value(PRODUCTS) type ty_products
Regards,
Naimesh Patel

BAPI OR RFC THAT RETURNS THE VALUE TABLE CONTENTS THAT IS SPECIFIED IN DOM

HI ALL,
i have requirement of BAPI or RFC that returns the value table contants(text table) in CRM..
for ex:
if i pass the dataelement or domain or checktable as input parameter,could i get the contents of its text table associated with it....
please if there is way help me on this..
thanks and regards,
goutham,

Check these FM
RFC_READ_TABLE
RFC_GET_TABLE_ENTRIES

SUBMIT and return the value of that report into internal table

Dear all,
I have a requirement. I want to submit a report and return the value of that report into my internal table.
How to do this.
Pl. guide.

Hi Vidhya,
Below links from SAP help will resolve your issue.
http://help.sap.com/saphelp_nw04/Helpdata/EN/fc/eb3bde358411d1829f0000e829fbfe/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3bd1358411d1829f0000e829fbfe/content.htm
Edited by: Harsh Bhalla on Jan 2, 2010 11:54 AM

Changing an object by calling a method in another class that returns nothin

How can a method like for example Arrays.sort(Object[] a) work? The method has a return statement void, so how come the array passed into the method "magically" end up as being sorted when we look at it in another class after having called this method?

jverd wrote:
sunfun99 wrote:
Since references really are more like addresses, jverd's adress-on-pieces-of-paper analogy is the best, but certainly not because the addresses on the pieces of paper are copies of the address (they aren't). We may just be splitting ever finer semantic hairs here, but how is it not a copy of the address?It is a finely split hair - and ultimately just a difference of language use, I think.
We scribble on pieces of paper and thereby have at least two things to deal with: the scribble, and the location. It is unfortunate, but in English both things are referred to as "the address". The scribble has qualities like "red", "legible" etc, the location has qualities like "distant", "next door to the president": so they do seem to be different things.
We use "address" for both: "I can't read this address" vs "Go to this address". Children make jokes based on the ambiguity: "How do you spell it."
But then there's a third thing: the denotation of the location by the scribble. (denotation here == reference/pointing-at/leash/stick etc). It really does seem to be a third thing. (With apologies to Jean Buridan) consider a person who has lat/long coordinates explained to them for the first time and is handed a piece of paper with coordinates on it. They are asked "Do you know who lives here?" and they answer "Yes, I know the person at this address!". Most would say the statement is false - even if it turns out they were handed their own address. Their assertion of knowledge is an assertion about the denotation of the location by the coordinates, not about the location itself.
So what is copied by a scribe or a photocopy machine when it copies an address? Clearly it's the scribble, not the location. The scribble is duplicated, the location is not. But what about the denotation of the location by the scribble? Not withstanding the above example (and especially in contexts where knowledge and similar concepts are not involved), you could say that the denotation of the location by the scribble is a value. In other words you could hold that two denotations of some location are not just equal but identical iff they denote the same location. (You could, but you needn't.) It is in this sense that the pieces of paper bear, not copies of the address, but the same address.
(Exactly the same applies to "pointers" ie signposts. If you have two "north pole" signs (1) The are different signs (2) They point to the same place (3) They are two signs bearing one and the same reference.)
Edited by: pbrockway2 on Mar 15, 2009 12:49 PM

How to Create a Jdialog class that returns a boolean parameter

I'm trying to subclass a jdialog to return a boolean to another callling class, the parameter is return when the jdialog closes, how do i declare such a class and what method do i call on the windowclosed event
I'm new to java so need some code sample, the program is to implement a login and password verification.
thanks in advance for any assistance.

Here's another way (a third way is to make the dialog form an inner class)
in this eg, the password is hard-coded as java
import java.awt.*;
import javax.swing.*;
import java.awt.event.*;
class MainWindow extends JFrame
JLabel lbl = new JLabel("JLabel");
JButton btn = new JButton("JButton");
boolean loggedInOK = false;
public MainWindow()
    new FTILogin_Jdia2(this, true).show();
    if(!loggedInOK) System.exit(0);
    buildGUI();
public void buildGUI()
    setLocation(400,300);
    setSize(150,85);
    setDefaultCloseOperation(EXIT_ON_CLOSE);
    JPanel jp = new JPanel(new BorderLayout());
    jp.add(lbl,BorderLayout.NORTH);
    jp.add(btn,BorderLayout.SOUTH);
    getContentPane().add(jp);
    setVisible(true);
public static void main(String[] args){new MainWindow();}
class FTILogin_Jdia2 extends javax.swing.JDialog implements ActionListener
JTextField tf = new JTextField(10);
String password = "java";
MainWindow mainWindow;
public FTILogin_Jdia2(MainWindow parent, boolean modal)
    setModal(modal);
    mainWindow = parent;
    initComponents();
public void initComponents()
    setLocation(400,300);
    getContentPane().setLayout(new BorderLayout());
    JPanel top = new JPanel();
    top.add(new JLabel("Password: "));
    top.add(tf);
    getContentPane().add(top,BorderLayout.NORTH);
    JButton btn = new JButton("OK");
    btn.addActionListener(this);
    getContentPane().add(btn,BorderLayout.SOUTH);
    pack();
public void actionPerformed(ActionEvent e)
    if(tf.getText().equals(password))
      mainWindow.loggedInOK = true;
    dispose();
[/code

Why is the returned internal table contains same values?

Hi all,
I got a bapi that returned an internal table type MARC.
For testing in R/3, the internal table returns 3 material no. with different values,
but in vb.net, it returns 3 entries with same values,
(I've passed the internal table as ByRef in the vb)
what's wrong are there?
Thanks.

Please post your test code.

Defining attribute for internal table within class builder?

Hello there,
I use an function module that provides me an internal table which has the reference type of the DDIC object zml_output. Furthermore I call this function module within a global class that should keep the result of the function module into the attribute lt_result, that is declared as private and typed with
lt_result TYPE zml_output.
Even the definition of that attribute causes the following error message:
"lt_result" is not an internal table.
I don't have any clue how to type lt_result differently. Actually I would need the following type of typing "TYPE TABLE OF" but that does not exist within the class builder.
Thanks for your help in advanced!
Robert

Hi Konstantinidis ...
Of course I can provide it to you. The code of my methode load_data reads as follows:
method LOAD_DATA.
    CALL FUNCTION 'ZDATAGET'
    EXPORTING
      iv_dat    = iv_dat
      iv_time1 = iv_time1
      iv_delta = iv_delta
    TABLES
      et_result = lt_result.
endmethod.
Especially the lt_result causes the mentioned error message
The compiler seems to expect something "TABLE" like for attribute lt_result. But whatever I tried it doesn't seem to work out.
Many thanks for help...

Reg:Submit statement Return Internal Table

Hi Team,
I have a query to return the internal table from the called program via SUBMIT statement to the calling statement ??
Example : Thing is that consider reports A and B , Report B is getting called from report A where in B we have one internal table full of data that i need to pull to report A and there i need to process it.
How can i achieve this?
Please let me know the possible ways.
Karthik.S

Hi karthik,
SUBMIT .... AND RETURN EXPORTING LIST TO MEMORY.
Then use FM LIST_FROM_MEMORY.
Thanks,
Anil

Problem in returning internal table from FM in ABAP Objects

Hi All,
I have to return an internal table from one of the FM i created in the controller class (_IMPL) of a view.
The problem here is, the internal table i m getting here
is of type to a structure!.
but i have to return it as type ref to DATA, which cant be assigned directly.
Now, my question is.. How can i convert ..
internal table type structure
to
internal table type ref to DATA.
Thanks and Regards,
sudeep v d.

Hi Sudeep.
Can you see if something like this works for you?
DATA: dref type ref to DATA.
FIELD-SYMBOL: <fs> type ANY.
LOOP AT <internaltable> INTO <structure>
ASSIGN "<component_name>" component of <structure> TO <fs>
CREATE DATA dref type <structure>.
dref->* = <fs>.
ENDLOOP.

Returning Internal Table as Returning Parameter of Method (by Value).

When you return an internal table as the returning parameter of a method, it is passed by value. I understand the concept of passing by value vs. passing by reference, but exactly what this means in this case is ambiguous.
1) It could mean that the entire table, including data, is copied from the local table in the method into the parameter provided by the calling code.
2) Alternatively, it could mean that only the pointer to the table is passed by value and the data is not literally copied from one place in memory to another. This would not be the same as passing by reference. For instance, I believe this is how object references are passed by value.
I want to know how it works, so that I know if there is an efficiency problem with returning a huge table. The returning parameter is wonderful for getter methods, and I prefer to use it over exporting parameters, but I have some concern about passing tables as returning parameters since I don't know how this works.
Can anyone either explain this, or at least make it clear to me whether or not there is an efficiency issue?
Thanks, in advance,
-Chris

Thanks to those who tried to help me with this question, but I finally had to just figure it out on my own. I just realized today that there is a way to find the answer using the debugger's Go To->Status Display->Memory Use option. This shows how variables are stored in memory.
The answer:
First of all, if you set one internal table equal to another like:
i_tab1 = i_tab2.
or like:
i_tab1[] = i_tab2[].
both will simply set i_tab1 to point to the same memory that i_tab2 is using. It does not make a copy. Now, if you attempt to change i_tab1, with an append statement for instance, a copy of i_tab2's memory is made then! The requested change to i_tab1 is then applied to the copied data. AHA!!! This means that even if you think you are copying a table, you are not really doing it until it becomes necessary due to a divergence in values.
I specifically tested a returning parameter to see how memory is handled, and it is basically just like an '=' statment. No copy of the data is performed at first. The memory that is allocated for the local variable in the method is simply pointed to by the variable used in the calling code to recieve that value.
What if you then change the value in the calling code after the method has finished executing? The answer depends on the situation. If the value that you returned from the method is still being pointed to by another variable somewhere, then a copy is made when you attempt to change the returned table in the calling code, but if there is no longer another variable pointing to this memory, you can change the table in the calling program all you want without causing a copy in memory.
For instance, if you have a getter method that returns the value of an attribute, at first no copy will be made, but when you try to change the table in your calling code, a copy will be made then. However, if you just fill a local table in your getter method and return that table, there will never be a copy made, because the local variable that originally pointed to that memory expired when the method completed. That means that after the method completes, the only variable pointing to the allocated memory is the one in the calling code that recieved the returning value.
This is fantastic!! This behaives in a way that seems to provide maximum efficiency in most cases. Also, the table copies are never a waste, since they only happen upon changing of one of the table variables that point to the common memory, and in this case you would want to make a copy to avoid corrupting the other variable.
Also, even if you did return your table as an exporting parameter by reference, you would not gain any significant efficiency. There would still be no table copy if you don't change the returned table. Also, if you did change the returned table, you would still produce a table copy if there was another variable, like an attribute, still pointing to the memory that you set your exporting paramter from before.
The only situation that I can see resulting in a needless efficiency problem is if someone used a getter method to return the value of a table attribute, then changed the returned table in the calling program, and then used a setter method to set the whole table attribute equal to the changed table. This would be a waste, so maybe this should be accomplished in another way.
In conclusion, there is essentially no reason to hesitate returning a whole internal table as a returning parameter from a method call, even though it is pass by value.
Kudos to the ABAP development team for their good design!

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

How many times will internal table get filled?

Dear BW / ABAP gurus:
I am observing a routine in a transformation in 7.0 data flow.
The internal table is created as follows in the global declaration in the Start Routine:
TYPES: BEGIN OF ST_PROD,
          /BIC/AZPROD TYPE /BIC/OIAZPROD,
          /BIC/AZCOST TYPE /BIC/OIAZCOST,
        END OF ST_PROD.
DATA: IT_PROD TYPE TABLE OF ST_PROD,
      WA_PROD TYPE ST_PROD.
The programmer is fetching data for product cost which is not available in the source. This code is written in the Start Routine:
SELECT /BIC/AZPROD /BIC/AZCOST
FROM /BIC/PAZPROD
INTO CORRESPONDING FIELDS OF TABLE IT_PROD
WHERE OBJVERS = 'A'.
My questions:
(1) Is it a standard practice to create the internal table in the global declaration?
(2) Is it a standard practice to fill the internal table with data in the Start Routine? Is it possible to fill the internal table with data in the global declaration? Or is the global declaration only reserved for declaring variables and creating internal tables?
(3) What is the use of 2nd part global?
(4) Let's say there are 100, 000 records at the source and the DTP package size is 50,000. Then the Start Routine will get executed 2 times. So the code in the Start Routine will hit the database 2 times to fill the internal table. Is this correct?
Note to mods: Please do not delete the thread. Move to the beginner section if you think this is basic. But please do not delete. It take a long time to type out the questions.

hi Saurav,
(1) Is it a standard practice to create the internal table in the global declaration?
1. No ,internal table should be created in global part only if they are getting used in field level or end routine .Else they must be in local part and should get refreshed at the end so that performance not get affected.
(2) Is it a standard practice to fill the internal table with data in the Start Routine? Is it possible to fill the internal table with data in the global declaration? Or is the global declaration only reserved for declaring variables and creating internal tables?
1.No if only you want to use the data in field level routine and start routine ,you will fill table in start routine otherwise no .
2.first global part is for data declaration so no in first global part select cannot come .
3.Second global part can have select but you cannot write any statement using source package or result package here as they are private object of transformation class and not recognized at this area.However simple select on any table other than these will be fine .
(3) What is the use of 2nd part global?
1.In second global part you can declare internal table ,structures that are not of type source package or result package but independent and can use them .
2.If you will declare these table in first global part they will be private object and you cannot write select using them in second global part .
3.Second global part is also declaration but outside the class so these objects are global across transformation with more flexibility .
4.If you will declare any data here using the structure of source /result package you will get error .This is a data declaration part comes between transformation definition and implementation part .
(4) Let's say there are 100, 000 records at the source and the DTP package size is 50,000. Then the Start Routine will get executed 2 times. So the code in the Start Routine will hit the database 2 times to fill the internal table. Is this correct?
yes the source and result package are actually the DTP packages only so code will get executed same no of time as you have number of packages in DTP extraction .
Hope this will be helpful .
Regards,
Jaya Tiwari

Attribute as internal table

I'm developing a BSP application that uses a application class. I created a table type in the data dictionary and used that as the type for an attribute of the class. In one of the methods of the class I use SELECT statement to fill the attribute but I get an error saying the attribute is not an internal table. Am I missing a step?
Thanks for any help,
Ross

Hello All,
Well I am able to use this method very easily...indeed.....
But I have a slightly different requirement....I have created a table-type in the data-dictionary....but what if I want to use the same method for many different tables....
Actually i was trying to develop a method to read values from active table of a DSO...by just passing the DSO name and Returning the internal table....
But if the table structure is different, then how can we (or can we ?) change the table type dynamically ???
Hope I'm clear...

RFC - delay in internal table update/refresh

Hello,
We have an RFC call. The end of the function call returns an internal table with new rows appended to it.However, when we check at the invoking code, i could see that it takes a while for the newly appended rows to be refreshed in the internal table. In order to avoid this, i have introduced a 'Wait upto' statement. However, this is proving to be a performance overhead. Can you please suggest if there is any other alternative to achieve this?
Thanks and regards,
Deepthi.

Hi,
If you are using nested loops, the better way to use the internal table, is always use READ statement. When you use read statement, you will be mentioning all the key fields like READ table itab with key f1 = k1.....
a) So first see in all your internal tables while comparing entries are you mentioning all the key fields in the read statements.
b) While you compare data between 2 internal tables inside a loop. Always check whether entries exist in both the tables, like if the values are initial for a particular internal table.
c) check sy-subrc = 0 for all the entries and internal tables.
d) try using continue inside your loop .... endloop.
Because, if there is no entry in the top level internal table, you can immediately give a continue statement there, so that system shall not check all the internal tables. It will exit from the current loop entry and the checking shall immediately start for the next table index.
This shall drastically reduce your processing time logic.
Lakshminarayanan
P.S. Mark all helpful answers for points

Global Class that returns an internal table

Similar Messages

Maybe you are looking for