This tip has been copied from SearchSap.com
Tip submitted by: srini s
This is an example program to create a combobox in your ABAP program. You have to create screen
ID as 1000 and call PBO and PAI (combopbo output and comboclick input)modules to get the proper
result.
Code
REPORT ZCOMBOBOX.
tables usr03.
data : itabitems like listitem occurs 0 with header line,
dname like usr03-bname,
indx type i,
itemname(256) type c,
first(4) type c value 'true'.
TYPES: BEGIN OF CNTL_FONT,
INIT(1) TYPE C,
F_TYPE TYPE I,
BOLD TYPE I,
ITALIC TYPE I,
SIZE TYPE I,
END OF CNTL_FONT.
TYPES: BEGIN OF CNTL_HANDLE,
OBJ LIKE OBJ_RECORD,
SHELLID TYPE I,
PARENTID TYPE I,
C_TYPE(4) TYPE C,"CNTL_TYPE,
CLSID LIKE CNTLSTRLIS-NAME,
ORIGIN LIKE SY-REPID,
HANDLE_TYPE(10) TYPE C,
LIFETIME TYPE I,
PROGRAM LIKE SY-REPID,
DYNNR LIKE SY-DYNNR,
IMODE TYPE I,
DYNPRO_POS TYPE I,
GUID TYPE I,
END OF CNTL_HANDLE.
data : CNTL_FONT_DEFAULTS TYPE CNTL_FONT.
data : CNTL_HANDLE_TEST TYPE CNTL_HANDLE.
cntl_font_defaults-f_type = 0.
cntl_font_defaults-bold = 1.
cntl_font_defaults-italic = 0.
cntl_font_defaults-size = 0.
cntl_font_defaults-init = ''.
select bname from usr03 into itabitems-item.
append itabitems.
endselect.
call screen 1000.
*&---------------------------------------------------------------------*
*& Module COMBOCLICK INPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE COMBOCLIK INPUT.
CALL FUNCTION 'COMBOBOX_GET_SELECTION'
EXPORTING
HANDLE = CNTL_HANDLE_TEST
IMPORTING
INDEX = indx
ITEM = itemname
EXCEPTIONS
CNTL_SYSTEM_ERROR = 1
CNTL_ERROR = 2
OTHERS = 3
.
IF SY-SUBRC <> 0.
.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
message ID SY-MSGID TYPE 'E' NUMBER 1
with itemname.
ENDMODULE. " COMBOCLICK INPUT
*&---------------------------------------------------------------------*
*& Module COMBOPBO OUTPUT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
MODULE COMBOPBO OUTPUT.
IF First = 'true'.
First = 'false'.
CALL FUNCTION 'OCX_COMBOBOX'
EXPORTING
LEFT = 100
TOP = 20
WIDTH = 280
HEIGHT = 16
FONT = CNTL_FONT_DEFAULTS
VISIBLE = 'X'
DISP_SCREEN = '1000'
IMPORTING
COMBOBOX_HANDLE = CNTL_HANDLE_TEST
TABLES
LIST_ITEMS = itabitems
EXCEPTIONS
LINK_ERROR = 1
OTHERS = 2
.
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDIF.
ENDMODULE. " COMBOPBO OUTPUT
Tuesday, July 15, 2008
sitemap SapMaterial.com Creating a combobox
Defining and reading internal tables
1. Types of internal tables
2. Defining an internal table
3. Reading internal tables
1. Types of internal tables
1.1 STANDARD table
Key access to a standard table uses a linear search. This means that the time required for a search
is in linear relation to the number of table entries.
You should use index operations to access standard tables.
1.2 SORTED table
Defines the table as one that is always saved correctly sorted.
Key access to a sorted table uses a binary key. If the key is not unique, the system takes the entry
with the lowest index. The runtime required for key access is logarithmically related to the number
of table entries.
1.3 HASHED table
Defines the table as one that is managed with an internal hash procedure
You can only access a hashed table using the generic key operations or other generic operations (
SORT, LOOP, and so on). Explicit or implicit index operations (such as LOOP ... FROM oe INSERT itab
within a LOOP) are not allowed.
1.4 INDEX table
A table that can be accessed using an index.
Index table is only used to specify the type of generic parameters in a FORM or FUNCTION. That
means that you can't create a table of type INDEX.
Standard tables and sorted tables are index tables.
1.5 ANY table
Any table is only used to specify the type of generic parameters in a FORM or FUNCTION. That
means that you can't create a table of type ANY.
Standard, sorted and hashed tables belongs to ANY tables.
2. Defining an internal table
DATA itab TYPE table type of line type [WITH UNIQUE/NON-UNIQUE KEY
[WITH HEADER LINE]
Note: There are also other ways to define an internal table. Please refere to the documentation.
2.1 The KEY option
KEY key1,,keyn :
key1..keyn are fields in the table. The sequence in which you specify the key is significant.
DEFAULT KEY :
The key fields are the standard keys. Note that you can only specify an empty key for tables with
access type STANDARD TABLE. The standard key basically comprises all tables fields with
character-like types (type ( C, STRING, D, T, N, X, XSTRING). In particular, components with a
numeric type (also refer to ABAP numeric types) and table components usually do not belong to the
standard key.
Example:
types:
begin of t_makt,
matnr like makt-matnr,
maktx like makt-maktx,
end of t_makt.
data:
* Define the table
gi_makt type sorted table of t_makt with unique key matnr.
* Define the work area for the table if necessary
gi_makt type t_makt.
3. Reading internal tables
READ TABLE itab WITH TABLE KEY k1 = v1 k2 = v2 [additions]
Note: In case of more than one match, it is the first match that is selected.
STANDARD TABLE: The system searches from the start of the table. The response time is in linear
relation to the number of table entries.
SORTED TABLE: The response time is in logarithmic relation to the number of table entries.
HASHED TABLE: The response time is constant
READ TABLE itab WITH KEY k1 = v1 k2 = v2 [BINARY SEARCH] [additions]
Note: In case of more than one match, it is the first match that is selected.
STANDARD TABLE: If you use the ... BINARY SEARCH addition, the system uses a binary search.
Otherwise, the search is sequential. This assumes that the internal table is sorted in ascending order
in the sequence of the specified key fields.
SORTED TABLE: If the specified key fields form a left-justified extract of the table key, the search is
binary, otherwise sequential.
HASHED TABLE: Sequential search.
READ TABLE itab INDEX i [additions]
Accessing the table entry with the index i.
Additions:
INTO wa - wa is used as output area
ASSIGNING
contents in comparison to the first addition. However, this addition does involve table administration
costs, and it is therefore only worthwile for lines longer than around 300 bytes.
COMPARING f1...fn - If the system find an entry, the system compares the subfields f1, f2, ... with
the corresponding fields of the work area before they are transported into it.
COMPARING ALL FIELDS
TRANSPORTING f1 f2 - If the system finds an entry, it does not transfer all of the subfields (default)
into the work area, but only the specified fields f1 f2 ...; the other subfields remain unchanged.
TRANSPORTING NO FIELDS
Example:
loop at gi_mseg into g_mseg.
read table gi_makt
with table key matnr = g_mseg-matnr
into g_makt.
endloop.
sitemap SapMaterial.com Transaction variants / Screen variants
What you can do with a transaction variant
Insert default values into fields
Change the ready for input status for fields
Hide various screen elements, menu functions or entire screens
Adjust table control settings
Note: Transaction variants can only be used with dialog transactions.
How to create a transaction variant
Transaction variants are created with transaction: SHD0
In the field Transaction on SHD0 enter the transactioncode for the screen you want tpo modify (E.g.
VA03)
In the field Variant on SHD0 enter the name you want to give the transaction variant (E.g. ZVA03)
Press Create
Now the screen for the transaction is shown and you can enter default values in the fields of the
screen
Press Enter. Now a screen that enbles you to make further customizing (Hide, Output only, Invisible,
Mandatory) if the screen fields is shown.
After you have finished customizing the screen press Enter to go to the next screen or ave and exit
to save the Transaction variant
To run the transaction varian, you must create a new Transaction code in SE93 that referes to the
Transaction variant. Choose Transaction with variant as Start object.
Note: The transaction variant can also be called from a program that imcludes a call to function
module RS_HDSYS_CALL_TC_VARIANT
Screen variants
To create a screen variant, use transaction SHD0. Use menu Goto -> Screen variants
The process to create a screen variant is similar to creating a Transaction variant. The difference
between the two types is that a Transaction variant covers the whole transaction and therefore can
have more than 1 screen, while a screen variant only can have 1 screen.
Modifying dictionary tables
There are 2 ways to add additional fields to a dictionary table without having to make a modification:
1. Append structures
2. Customizing includes
1. Append structures
Append structures can only be assigned to a single table.
Append structures are created in the custome rnamespace ( ZZ or YY)
In case of new versions of the standard table during upgrade, the append structures are
automatically appended to the new version of the standard table
Append structures can not be used with cluster and pool tables
Append structures are created in transaction SE11. Display the standard table fields and press the
Append structure button.
When you press the button, SAP sugests a name for the new append structure. After you has
accepted the name,
a screen will be shown where you can enter the new fields.
Remember to activate.
2. Customizing includes
Some of the SAP standard tables contains special include statements called Customizing includes. In
contrast to Append structures,
Note that customizing includes are created by SAP, but the customer supply the fields for the include.
Customizing includes begin with CI_ and is part of the customer namespace
One Customizing include can be inserted into more than one table.
You can find Customizing includes in SE11 under structures.
Try to take a look at table RKPF which uses the Customizing include CI_COBL (In an IDES system).
Next try to add a field to CI_COBL, and activate it. If you go back to table RKPF you will se that your
new field has been added.
User exits
1. Introduction
2. How to find user exits
3. Using Project management of SAP Enhancements
1. Introduction
User exits (Function module exits) are exits developed by SAP. The exit is implementerd as a call to
a functionmodule. The code for the function module is writeen by the developer. You are not writing
the code directly in the function module, but in the include that is implemented in the function module.
The naming standard of function modules for functionmodule exits is: EXIT_
The call to a functionmodule exit is implemented as: CALL CUSTOMER.-FUNCTION <3>
Example:
The program for transaction VA01 Create salesorder is SAPMV45A
If you search for CALL CUSTOMER-FUNCTION i program SAPMV45A you will find ( Among other user
exits):
CALL CUSTOMER-FUNCTION '003'
exporting
xvbak = vbak
xvbuk = vbuk
xkomk = tkomk
importing
lvf_subrc = lvf_subrc
tables
xvbfa = xvbfa
xvbap = xvbap
xvbup = xvbup.
The exit calls function module EXIT_SAPMV45A_003
2. How to find user exits
Display the program where you are searching for and exit and search for CALL CUSTOMER-EXIT
If you know the Exit name, go to transaction CMOD. Choose menu Utillities->SAP Enhancements.
Enter the exit name and press enter.
You will now come to a screen that shows the function module exits for the exit.
3. Using Project management of SAP Enhancements
We want to create a project to enahance trasnaction VA01
Go to transaction CMOD
Create a project called ZVA01
Choose the Enhancement assign radio button and press the Change button
In the first column enter V45A0002 Predefine sold-to party in sales document . Note that an
enhancement can only be used i 1 project. If the enhancement is allready in use, and error message
will be displayed
Press Save
Press Components. You can now see that enhancement uses user exit EXIT_SAPMV45A_002.
Double click on the exit.
Now the function module is displayed. Double click on include ZXVVAU04 in the function module
Insert the following code into the include: E_KUNNR = '2155'.
Activate the include program. Go back to CMOD and activate the project.
Goto transaction VA01 and craete a salesorder. Note that Sold-to-party now automatically is "2155"
Menu exits
Menu exits allow you to add your own functionallity to menus. Menu exits are implemented by SAP,
and are reserved menu entries in the GUI interface. The developer can add his/her own text and
logic for the menu.
Function codes for menu exits all start with "+"
Example
We want to create a new menu item in the Office menu. The text for the menu should be "Run
ZTEST", and the menu will
run report ZTEST.
Goto transaction SE43 Area Menu Maintenance
In Area Menu Paramenter type 'S000' (S triple Zero)
Select Change and ignore all the warning screens
Expand the office menu. In the buttom of the office tree you will find a menu named "Customer
function"
Double click on the text. In the pop-up screen change the text to "Run ZTEST". Note that the
trsnaction code is +C01
Goto transaction SE93 and create transaction +C01 that calls report ZTEST.
Now you will se the menu displayed in the office tree. If you delete transaction +C01 again, the new
menu will dissapear.
Screen exits
Screen exits are exits that allow you to use a reserved part of the screen (A subscreen) to display or
input data.
It is determined be SAP where the sub screen will be displayed.
The syntax is: CALL CUSTOMER-SUBSCREEN
The screen exit is not processed untill the corresponding subscreen has been created in an
enhancement project, and the project has been activated.
Note:
Function codes are only processed in the main screens flow logic
You are not allowed to enter a name for the subscreens command field
You are not allowed to define GUI stauses
You are not allowed to enter a value for Next screen
The global data of the program is not available for the subscreen. Data for the subscreen is provided
by function modules. These function modules belongs to the same function group as the subscreen
Subscreens are edited with transaction CMOD. When you activate a project containg subscreens,
the calling screen is regenerated and the subscreen is displayed next time you display the calling
screen
The developer must create the subscreen and the corresponding PBO and PAI modules
How to identify screen exits
Look after CALL CUSTOMER-SUBSCREEN in the screenprogram of the screen you want to modify.
Use transaction CMOD menu Utillities -> SAP enhancements to search for screen exits
Runthe report in the chapter Report for finding User Exit. Search for the words "screen exit" in the
report
An example of a screen exit can be found in an IDES system, transaction BC425_01 screen 200. You
can also take a look on function group WLF2 screen 0206.
Thursday, July 10, 2008
Internal table objects
| SapMaterial.com |
 | |  | |  | |  | |  | |  | |  | |  | |  |
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
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 (
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.
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
[INITIAL SIZE
[WITH HEADER LINE].
As when you define a table type , the type constructor
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.
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.
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
[INITIAL SIZE
After TYPE or LIKE, there is no reference to an existing data type. Instead, the type constructor occurs:
The type constructor defines the table type
You can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
You can specify the table type
Generic table types
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
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.
You can specify the key
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.
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
reserve memory space for
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 <=
It only makes sense to specify a concrete value of
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
length of the line. If you specify a larger value of
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.
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 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.
abap faqs
Difference between 'perform userexit' and 'Call customer-'
VF11 - Billing Date should be defaulted with system date
How to execute a function in BADI ME_GUI_PO_CUST
How to determine the total net-value of an outb. delivery ?
Problem with LANGTEXT_ONLY functional module
Viewing archives
COM AUTOMATION WITH MERLIN
Exporting to file, last character is a space
printing invoice sets
Smartforms --- Translation
Incompletion log for custom fields on VA01 - Resolved
General Ledger ( GL ) updation
Consuming Web Service from ABAP
hai...a help
Re-write 'provide' statement with 'loop at'
ALV GRID Question
execution goes to /RWD/SAPLNOTIFY
Create TO for TR for incomplete TR quantity true FM
purchase info record
ALV Catalogue Generator wizard
vl02n output crashing...trying to debug smartform...stuck
Print Table Control and ALV on same screen
Is it possible to download short dumps (ST22) to a file?
Table Maintenance Generator
Help in user exit while doing a PGI
creation of a job
Call Transaction for MM02
Execute ALV in background
Row headers instead of columns headers
Program storage
Enhancing an Infotype Included in the standard SAP ECC 6.0
Net price list (V_LN) - how to change the input output
user exit for reversal document..
Parameters problem
FI-CO document linking problem
Reagrding List Box in Module Pool Program
How get the information in Expert tab
User getting Locked when making a Call to RFC FM
Is it possible to display mean value in ALV block list?
Page Format...Three cheque in one page
it is possible?
Sort the fields in Query
User Exit Help
cust statement - BKORM
Screen of TRx ME21N
Maintain Subscreen for Coding Block
Game for R/3
Customer Include SAPF100
REUSE_ALV_GRID_DISPLAY : No merge using editable fields
