EXAMPLE ALV

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241

*&---------------------------------------------------------------------* *& Report ZTEST_ALV *& *&---------------------------------------------------------------------* *& *& *&---------------------------------------------------------------------* REPORT ztest_alv. DATA : t_ekko TYPE TABLE OF ekko, x_ekko TYPE ekko. *ALV Data declaration *--------------------------------------------------------------------* DATA: t_fieldcatalog TYPE slis_t_fieldcat_alv WITH HEADER LINE, d_tab_group TYPE slis_t_sp_group_alv, x_layout TYPE slis_layout_alv, d_repid LIKE sy-repid, t_events TYPE slis_t_event, x_prntparams TYPE slis_print_alv, t_sort TYPE slis_t_sortinfo_alv, t_alv_isort TYPE slis_t_sortinfo_alv WITH HEADER LINE, t_alv_extab TYPE slis_t_extab WITH HEADER LINE. *--------------------------------------------------------------------* START-OF-SELECTION. SELECT * FROM ekko INTO TABLE t_ekko UP TO 50 ROWS. PERFORM f_alv. *&---------------------------------------------------------------------* *& Form F_ALV *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* * --> p1 text * <-- p2 text *----------------------------------------------------------------------* FORM f_alv . REFRESH t_fieldcatalog. PERFORM f_build_fieldcatalog. PERFORM f_build_layout. PERFORM f_build_events. PERFORM f_display_alv_report. REFRESH : t_ekko. ENDFORM. " F_ALV *&---------------------------------------------------------------------* *& Form F_BUILD_FIELDCATALOG *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* * --> p1 text * <-- p2 text *----------------------------------------------------------------------* FORM f_build_fieldcatalog . PERFORM f_sub_fill_alv_field_catalog USING: '01' '01' 'BUKRS' 'T_EKKO' 'R' 'Company Code' '' '' '' '' 'X', '01' '02' 'BSART' 'T_EKKO' 'L' 'PO Type' '' '' '' '' 'X', '01' '03' 'LOEKZ' 'T_EKKO' 'R' 'Delete' '' '' '' '' '', '01' '04' 'LIFNR' 'T_EKKO' 'R' 'Vendor' '' '' '' '' '', '01' '05' 'BSTYP' 'T_EKKO' 'R' 'Account' '' '' '' '' ''. ENDFORM. " F_BUILD_FIELDCATALOG *&---------------------------------------------------------------------* *& Form F_BUILD_LAYOUT *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* * --> p1 text * <-- p2 text *----------------------------------------------------------------------* FORM f_build_layout . x_layout-colwidth_optimize = 'X'. x_layout-zebra = 'X'. * x_layout-info_fieldname = 'LINE_COLOR'. x_layout-box_tabname = 'T_EKKO'. ENDFORM. " F_BUILD_LAYOUT *&---------------------------------------------------------------------* *& Form F_BUILD_EVENTS *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* * --> p1 text * <-- p2 text *----------------------------------------------------------------------* FORM f_build_events . DATA: lx_events TYPE slis_alv_event. REFRESH t_events. CONSTANTS: c_formname_subtotal_text TYPE slis_formname VALUE 'F_SUBTOTAL_TEXT'. CALL FUNCTION 'REUSE_ALV_EVENTS_GET' EXPORTING i_list_type = 0 IMPORTING et_events = t_events[] EXCEPTIONS list_type_wrong = 1 OTHERS = 2. LOOP AT t_events INTO lx_events. CASE lx_events-name. WHEN slis_ev_top_of_page. MOVE 'F_TOP_OF_PAGE' TO lx_events-form. WHEN slis_ev_pf_status_set. MOVE 'F_PF_STATUS_SET' TO lx_events-form. ENDCASE. MODIFY t_events FROM lx_events. ENDLOOP. *Subtotal CLEAR lx_events. READ TABLE t_events INTO lx_events WITH KEY name = slis_ev_subtotal_text. IF sy-subrc EQ 0. MOVE c_formname_subtotal_text TO lx_events-form. MODIFY t_events FROM lx_events INDEX sy-tabix. ENDIF. ENDFORM. " F_BUILD_EVENTS *&---------------------------------------------------------------------* *& Form F_DISPLAY_ALV_REPORT *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* * --> p1 text * <-- p2 text *----------------------------------------------------------------------* FORM f_display_alv_report . d_repid = sy-repid. CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY' EXPORTING i_callback_program = d_repid is_layout = x_layout it_fieldcat = t_fieldcatalog[] it_sort = t_sort i_default = 'X' i_save = 'A' it_events = t_events is_print = x_prntparams TABLES t_outtab = t_ekko EXCEPTIONS program_error = 1 OTHERS = 2. IF sy-subrc <> 0. ENDIF. ENDFORM. " F_DISPLAY_ALV_REPORT *&---------------------------------------------------------------------* *& Form F_SUB_FILL_ALV_FIELD_CATALOG *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* * -->P_0092 text * -->P_0093 text * -->P_0094 text * -->P_0095 text * -->P_0096 text * -->P_0097 text * -->P_0098 text * -->P_0099 text * -->P_0100 text * -->P_0101 text * -->P_0102 text *----------------------------------------------------------------------* FORM f_sub_fill_alv_field_catalog USING p_rowpos TYPE sycurow p_colpos TYPE sycucol p_fldnam TYPE fieldname p_tabnam TYPE tabname p_justif TYPE char1 p_seltext TYPE dd03p-scrtext_l p_out TYPE char1 p_tech TYPE char1 p_qfield TYPE slis_fieldname p_qtab TYPE slis_tabname p_key TYPE char1. DATA: lx_fcat TYPE slis_fieldcat_alv. lx_fcat-row_pos = p_rowpos. lx_fcat-col_pos = p_colpos. lx_fcat-fieldname = p_fldnam. lx_fcat-tabname = p_tabnam. lx_fcat-just = p_justif. lx_fcat-seltext_l = p_seltext. lx_fcat-no_out = p_out. lx_fcat-tech = p_tech. lx_fcat-qfieldname = p_qfield. lx_fcat-qtabname = p_qtab. lx_fcat-key = p_key. APPEND lx_fcat TO t_fieldcatalog. CLEAR lx_fcat. ENDFORM. " F_SUB_FILL_ALV_FIELD_CATALOG *&---------------------------------------------------------------------* *& Form f_top_of_page *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* FORM f_top_of_page. *ALV Header Declarations DATA: lt_header TYPE slis_t_listheader, lx_header TYPE slis_listheader, lt_line LIKE lx_header-info, ld_lines TYPE i, ld_linesc(10) TYPE c. DATA : ld_year_txt(8). *Title lx_header-typ = 'H'. lx_header-info = 'PETRONAS CARIGALI INDONESIA'. APPEND lx_header TO lt_header. CLEAR lx_header. lx_header-typ = 'S'. lx_header-info = 'PRODUCTION SHARING CONTRACTS'. APPEND lx_header TO lt_header. CLEAR lx_header. lx_header-typ = 'A'. lx_header-info = 'PRODUCTION SHARING CONTRACTS'. APPEND lx_header TO lt_header. CLEAR lx_header. CALL FUNCTION 'REUSE_ALV_COMMENTARY_WRITE' EXPORTING it_list_commentary = lt_header. ENDFORM. "f_top_of_page *&---------------------------------------------------------------------* *& Form f_pf_status_set *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* * -->FU_EXTAB text *----------------------------------------------------------------------* FORM f_pf_status_set USING fu_extab TYPE slis_t_extab. REFRESH fu_extab. SET PF-STATUS 'STANDARD' EXCLUDING fu_extab. SET TITLEBAR 'TITLE' WITH 'Financial Quarterly Report - 4ATT'. ENDFORM. "F_ALV_STATUS

ADJUST TEMPLATE, GIU STATUS, MANAGE TR, MANAGE LOCK ENTRIES.

Hey folks,

today i'm gonna show you how to do some job in sap abap module.

first,
adjust template.
in screen painter, there are times when you need most of the button in gui status. well here's the simple way.

just click extras->adjust template

select list viewer and ok,
all of the buttons should have filled by now.

2. make GUI STATUS and GUI TITLE
to make GUI STATUS, you need to make GUI STATUS and GUI TITLE, here's the simple way.

3.Manage TR

in sap abap module, there are times when you have to edit the TR, to make it easier to understand. you can use the SE01 TCODE to do this.

in this step you can edit or change the TR as you wish.

4. manage LOCK ENTRIES.

there are times when you logged out instantiniously or because of the network problem while editing your code, if this happends when you tried to loggin again and edit your code, you will be unable to edit it since your last loggin had lock the entries. all  you have to do is delete the lock entries. use SM12 TCODE.

5. there are times when you wanted to export your report into excel, well sap has already the sistem for that, but you need to activate the GUI STATUS first.

well, that's it for now,

i will post again if i managed to solve something.

adios....

TAW10 - OBJECT DEPENDENCIES

ACTIVE AND INACTIVE VERSION

The active version of an ABAP Dictionary object is the one that is accessed by the components of the runtime environment, such as the ABAP processor and database interface.

On the other hand, the inactive version is created when an active object is changed. It does not affect the runtime system. The inactive version can be changed into an active version through a process called activation.

The slide here illustrates change in the status of an object. Initially, an active structure contains three fields. When an additional field is added to this structure in the ABAP Dictionary, it results in two versions of the same structure. One is an active version containing the original fields and the other is an inactive version containing the additional field. During the activation process, the inactive version replaces the active version. Thus, the inactive version becomes the active version resulting in only a single active version with the four fields.


RUNTIME OBJECTS

In the ABAP Dictionary, information about a structure or table is stored in data elements and structure definitions. The runtime object combines this information into a structure which is so designed that it can be easily accessed from ABAP programs.

You can create runtime objects for all ABAP Dictionary objects that can be used as types in ABAP programs, such as data elements, table types, and views. These objects hold varied information about the overall structure, the individual structure fields, as well as additional information regarding client dependence, buffering, and key fields required for accessing the table data.

WHERE-USED LIST

When some change occurs in a domain, then all the data elements, structures, and tables referring to this domain must be reactivated. This is done so that all affected runtime objects adjust to the changed type information.

Each object in the ABAP Dictionary maintains a ‘where-used list’ that provides information about all the other objects that refer to it.

Using this list, you can determine the direct and indirect usages of the ABAP Dictionary object. For this, you need to define the usage object types that have to be included in the search; for example, all structures and tables using a data element.

You can also search the usages of objects that are not part of the ABAP Dictionary, such as all programs, using a table.

Object usage search can also be limited by the development class or user namespace.

THE REPOSITORY INFORMATION SYSTEM ABAP DICTIONARY

This slide illustrates how to conduct search for ABAP Dictionary objects and their users with the help of the general Repository Information System which includes Repository Information System ABAP Dictionary. You can call the Where-used lists for Repository objects from the information system to search for objects by their attributes. Additionally, you can search for all objects by development class, author, and date of last change.

TAW10 - INPUT CHECKS

FIXED VALUES

If you can input only a limited set of values while creating a domain, then these values are defined as fixed values. These can either be listed individually or defined as an interval. Moreover, fixed values generate F4 Help. As soon as screen entries are made, the fixed values are immediately used as check values.

When fixed values are specified, the value range of the domain gets limited by these values. The value range of a field is determined by its data type and field length.

VALUE TABLE

The value range of a field can be defined using a value table. You can define the value range of a field by specifying a value table in the domain. Validation occurs only after a foreign key is defined for a field or component. In such cases, the system proposes the value table as a check table.

INSERTING A DATA RECORD

This slide illustrates the flight booking details of a customer with American Airlines (AA). The user places an inquiry whether the booking can be made at counter 8. While Table SBOOK mentions all the flight bookings of the airlines, Table SCOUNTER contains all the valid counters of the airlines. If an entry is made in field COUNTER of table SBOOK, you must ensure that only valid counters are entered. Therefore, these counters must be stored in table SCOUNTER.

VIOLATION OF THE FOREIGN KEY CHECK

The booking entries made in table SBOOK are rejected as no corresponding data record for COUNTER is selected from table SCOUNTER. The customer’s request for booking this particular flight at counter 8 is rejected as the counter for American Airlines (AA) is 1 rather than 8. Such relationships between two tables are defined in the ABAP Dictionary using foreign keys which must be defined explicitly for the fields. By using foreign keys, consistency of data is ensured as data that is entered is matched against the existing data.

FOREIGN KEY FIELDS/CHECK FIELDS

Let us understand how to use foreign key fields using two tables, SBOOK and SCOUNTER. Here, Table SBOOK is the foreign key table. Its purpose is to ensure that only valid carrier counters can be assigned to a booking.

On the other hand, Table SCOUNTER is the check table and contains exactly the same information. Each counter in this table has three key fields; namely MANDT, CARRID, and COUNTNUM.

You can define the foreign key by assigning these three fields to the fields of the foreign key table which is used to enter the input on the screen. The entry is accepted only if the entry represents a valid counter. The COUNTER field is called the check field for this foreign key defined for field SBOOK-COUNTER. This means that the entry in this field is checked.

In the example shown here, a foreign key is defined for field COUNTER leading to three check tables, SCOUNTER-CLIENT, SCOUNTER-CARRID, and SCOUNTER-COUNTNUM; and three foreign key tables, SBOOK-MANDT, SBOOK-CARRID, and SBOOK-COUNTER.

DATA CONSISTENCY THROUGH FOREIGN KEYS

The check field is the field of the foreign key table that is to be checked. A foreign key is a group of fields of a table that is also the primary key for another table. Therefore, a foreign key links two tables, the check table and the foreign key table. The check table, also known as the referenced table, is the table whose key fields are checked. The foreign key table contains entries which must be consistent with the key fields of the check table.

FOREIGN KEY DEFINITIONS IN THE CHECK FIELD

Domain equality between the check field and the referenced key field of the check table is a mandatory requirement in the ABAP Dictionary. By using the same domain for the check field and the referenced key field of the check table, there will not be any need to compare fields with different data types and field lengths. While you can use different data elements, they must always refer to the same domain. If domains are not equal, the foreign key will not be consistent. If the domain of the check field contains a value table, the value table can act as check table, if the value table does not have any foreign key.

However, for all other foreign key fields, only the data type and the field length are required to be equal.

CHECK TABLE NOT EQUAL TO VALUE TABLE

This slide illustrates an example of a foreign key definition. It shows the system proposal for the field AGENCYNUM in SBOOK, on the basis of the value table in the domain.

Let us assume that SBUSPART is the check table. For check table SBUSPART-CLIENT, the foreign key table is SBOOK-CLIENT, while for check table SBUSPART-BUSPARTNUM, the foreign key table is SBOOK-AGENCYNUM.

However, this proposal is not correct. The SBUSPART table contains all the business partners of airline carriers. However, only agencies are allowed for field SBOOK-AGENCYNUM. Table SBUSPART, therefore, contains invalid data for this field. In fact, table STRAVELAG is the correct check table. It is a subset of table SBUSPART owing to its foreign key definition on field AGENCYNUM.

SEMANTIC ATTRIBUTES

Cardinality is a semantic attribute that describes the foreign key relationship with regard to the number of records of the check table that are assigned to records of the foreign key table. The cardinality must be defined with regards to the check table.

A foreign key field can identify a table entry based on its type. There are four types of foreign key fields:

Not specified means that there is no information about the kind of foreign key field.

No key fields or candidates suggests that the foreign key fields are neither primary key fields of the foreign key table nor do they uniquely identify a record of the foreign key table.

Key fields or candidates indicates that the foreign key fields are either primary key fields of the foreign key table or they uniquely identify a record of the foreign key table.

Key fields of a text table means that the foreign key table acts as a text table in the check table in cases where the key of the foreign key table only differs from the key of the check table in an additional language key field.

TEXT TABLE

Table SMEAL depicts information about in-flight meals provided to the passengers. The meal names are maintained in another table, SMEALT. Table SMEALT is the text table for table SMEAL as the key of SMEALT comprises the key of SMEAL and an additional language key field. An explanatory text for all the key entries of SMEAL can also be given in Table SMEALT.

You must link the text table SMEALT with table SMEAL using a foreign key to link the key entries with the text. Key Fields of a text table must be selected for the type of the foreign key fields.

TAW10 - PERFORMANCE WHEN ACCESSING THE TABLES

STRUCTURE OF AN INDEX

An index is a copy of the database table containing only the key fields. As data in an index is sorted, it can be accessed and retrieved instantly. Indexes also contain a pointer from the index entry to the corresponding table entry.
When index is used for data retrieval, all fields constituting the index will participate in the WHERE clause. In the example shown in the slide, the SELECT * statement is used to fetch data from the SCARR table where the value of CARRID is LH. Therefore, binary search is used to locate the records in data table. LH is in the first position in the WHERE clause as it has the maximum number of selections, 14.

ACCESSES WITH INDEXES

The function of the database optimizer is to determine which index should be used by the database for accessing data records. When you use the SELECT * statement with carname as Lufthansa, the database optimizer selects the SCARR NAM index table to fetch data from the SCARR table.
There are two types of indexes: Primary and Secondary. The index type of a particular index can be determined by its three-place index ID. If the index ID is zero, it denotes a primary index.
Customers can also create their own indexes on SAP tables. The index IDs for such indexes always begin with either Y or Z.

DATA ACCESS USING THE BUFFER

You can use table buffers to increase performance when reading records from a table. The buffers reside locally on the application servers. During the initial access, data is read from the database. Thereafter, data remains loaded into the buffer and is accessed directly from it. This speeds up the whole process.


FULL BUFFERING

Full buffering means that a table is either completely buffered or not buffered at all. In full buffering, when a single record is accessed, all the records of that table are also loaded into the buffer. There are three points to be kept in mind while using full buffering. These are
  the size of the table to be buffered;

  the number of read accesses; and

  the number of write accesses.

It is commonly observed that the smaller the table is; the more frequently it is read and the less frequently it is written. This makes it ideal for full buffering. It is also recommended for tables that have frequent accesses to records that do not exist.

GENERIC BUFFERING

With generic buffering, when you access a particular record, all other records whose generic key fields match this record are loaded into the buffer. The generic key for a table is the left-justified part of a primary key that is specified when the buffering type is selected.


SINGLE-RECORD BUFFERING

Single-record buffering is preferred for
  records that are accessed with SELECT SINGLE command; and

  tables in which the individual entries are repeatedly accessed.

In single-record buffering, only those records that are actually accessed are loaded into the buffer. This can save a lot of storage space in the buffer compared to generic and full buffering. However, in this case, the overhead for buffer administration is higher than that for generic or full buffering.


TABLE BUFFERING

The buffers reside locally on the application servers. During initial access, data is read from the database. Thereafter, data remains loaded into the buffer and are accessed directly from it, making the data access easier and faster. However, another program can change this data in the database. Therefore, data must be synchronized.


BUFFER SYNCHRONIZATION 1

As the buffers reside locally on the application servers, they must be synchronized after any data has been modified in a buffered table. This synchronization occurs at periodic intervals laid down in the system profile.
Let us understand this process with an example.
As shown here, two application servers need to access Table SCARR in the database. Server 1 first reads the records from Table SCARR on the database. This table is then loaded into a local buffer on server 1. This local buffer is subsequently used by server 1 to access the data.



BUFFER SYNCHORIZATION 2

Here, Server 2 accesses the records from Table SCARR in the database and loads it into its local buffer.

BUFFER SYNCHRONIZATION 3

If a user on Server 1 deletes certain records from the SCARR table and updates the database, then Server 1 writes an entry in the synchronization table and updates its local buffer.


BUFFER SYNCHRONIZATION 4

A user on Server 2 can still access the deleted records because the records reside in his local buffer, even though they no longer exist in the database table. If the same access had been made through an application program to Server 1, it would have replied stating that the records no longer exist.


BUFFER SYNCHRONIZATION 5

The synchronization of the servers takes place at fixed time intervals. During synchronization, both servers check the synchronization table to look for any modifications.
Server 2 now realizes that the SCARR table has been modified by server 1 and immediately invalidates the table in its local buffer. Server 1, on the other hand, does not need to invalidate the table in its buffer, since it had made the modification initially. Therefore, it continues to use the table in its buffer to access the SCARR table.

BUFFER SYNCHRONIZATION 6

After the table in its buffer is invalidated during the synchronization process, Server 2 accesses the SCARR table again. It does this through the database. The SCARR table from the database is now reloaded into the local buffer of Server 2.


DECISION TREE FOR BUFFERING

This slide illustrates a decision-making tree for buffering tables. It illustrates the decision-making process involved in buffering tables. It is seen that buffering significantly increases performance. This is because table buffers reside locally on an application server and are refreshed at regular intervals. However, it is important to select the right type of buffering. Another crucial point is that the more frequently a table is read; and the less frequently its contents are changed, the better it is to buffer the table.

TAW10 - DATA OBJECTS IN ABAP DICTIONARY

DATA DICTIONARY INITIAL SCREEN (SE11)

The globally known data types are defined using the Data Type field.
You can define the type group for creating global constants using the Type Group field.
The Domain field is where the technical properties of data objects can be defined.

DATA TYPES IN THE ABAP DICTIONARY

You can generate data objects in the ABAP programs using the data types declared in the ABAP dictionary.
However, an ABAP program cannot access domains for defining data objects. The data elements get their data types from domains.
The components of a structure can be elementary fields, tables, as well as structures.
A structured type or an elementary type can be the line type of a table type (ITAB).


DOMAIN

Domains cannot be used directly in programs or tables.
Therefore, data element is used as a bridge from the technical properties to the different data types or data objects.
You can define technical attributes and value ranges.
The most frequently used data types are CHAR, DATS, DEC, and NUMC. CHAR, the character string, can have a maximum length of 255 in tables. DATS defines the date and the length is set at eight characters.
DEC is used for the calculation of an amount in a field, and contains operators, such as the point, the plus or minus (+/-) sign, and thousand-separator commas. It can have a maximum of 31 characters.
NUMC is used for character strings that comprise only numbers. It is restricted to a maximum of 255 characters.

DATA ELEMENT

Data elements not only constitute the link between domains and the data objects, but also contain semantic or technical information about the data objects created from these.
You can translate the field labels into other languages by choosing the transaction SE63 or the menu path: Goto → Translation.
You can append F4 or input help to a data element.
You can assign the SET or GET parameter to the data element, if an input field based on the same data element exists on a subsequent screen. This helps you read the value from the parameter and enter it in the screen field.

STRUCTURES

Structure components can be data elements, integrated types, structure definitions of internal tables, DB table views, or other existing structure definitions. The data object, generated by including the fields of an actual two-dimensional object like a view or DB tables, remains flat or one-dimensional.


USING SIMPLE STRUCTURES IN ABAP

A flat structure is formed by the sequence of fields through the use of data elements. A one-dimensional data object is formed with this structure type. The individual elements or components of the structure can be addressed by using the name of the structure, a hyphen, and the name of the components.


NESTED STRUCTURE

A nested structure is formed by including another structured object in the structure and assigning it to a component.
You can nest structures like these into one another in any way.



INTERNAL TABLES

Internal tables can be defined using an existing line structure. You can use database tables, structure definitions, views, data elements, direct type definitions, or existing table types as line types.
A two-dimensional array is created in the main memory by declaring an internal table in an ABAP program.


DEEP STRUCTURE

A deep structure is formed by inserting an internal table as a structure component. It contains at least one table. The component of such a table has its own name and can be addressed like a normal internal table (LOOP AT..., INSERT... INTO TABLE, ...).
An internal table can have a deep structure as a line type. Thus multidimensional data types can be created as you can inter-nest internal tables and structures several times.




TYPE GROUP

You declare the type group using the TYPE POOL statement. This enables you to use the types of a type group in a program.
All names of these data types and constants must begin with the name of the type group and an underscore.
You define global constants using a type group, which should have a name not more than five characters long.
In the type group, you use the CONSTANTS statement to define constants, as well as to declare cross-program constants.



TABLES AND FIELDS

A table consists of
  columns (fields) and rows (entries);

  a unique table name and certain general attributes, such as delivery class and maintenance authorization; and

  certain key fields called the primary keys, whose values uniquely identify each entry of the table.



BASIC OBJECT OF THE ABAP DICTIONARY

The basic objects for defining data in the ABAP Dictionary are
  tables

  data elements, and

  domains.

Domains are used for technical definition of table fields, such as field type and length. One domain may be used by more than one data element.
Data elements, on the other hand, are used for semantic definitions, such as short descriptions. One data element may be used by more than one field of one or more tables.
A field in a table is not an independent object. It is table-dependent and can only be maintained within a table.


TWO-LEVEL DOMAIN CONCEPT: EXAMPLE

A single domain can be used for different data elements.
Let us assume that flight schedules are stored in a table SPFLI. The table contains the fields AIRPFROM (departure airport) and AIRPTO (arrival airport). These fields have the same domain S_AIRPID because both fields contain airport IDs and therefore have the same technical attributes.
They have a different semantic meaning, however, and use different data elements to document this. The field AIRPFROM uses data element S_FROMAIRP while field AIRPTO uses data element S_TOAIRP.


TRANSPARENT TABLES AND STRUCTURES

A transparent table is automatically created on the database when it is activated in the ABAP Dictionary. When this happens, the database-independent description of the table from the ABAP Dictionary is translated into the language of the corresponding database system.
The database table thus created, along with its fields, has the same name as the table in the ABAP Dictionary. The data types in the ABAP Dictionary are converted to the corresponding data types of the database system.
The order of the fields in the ABAP Dictionary can differ from the order of the fields on the database.
Transparent tables can be accessed by ABAP programs in two ways:
  Access the data in the table with the OPEN SQL or the EXEC SQL command.

  Access a structured type defined in the table, only when variables or more complex types are defined.A structured type, for which there is no corresponding object in the database, can also be created in the ABAP Dictionary. Such types are called structures. Structures can also be used to define the types of variables.

INCLUDE STRUCTURES

To avoid redundant structure definitions, you can include structures in tables or within other structures. A table can only be included in its entirety.
A chain of includes may only contain one database table.
An include can contain other includes.


TECHINCAL SETTINGS

Technical settings help determine how to manage the tables once they are created on the database; whether they should be buffered; and whether modifications to the entries should be logged.
Once a table is activated in the ABAP Dictionary, it is automatically created in the database. You can deduce the information on storage area and expected table size from the settings for the data class and size category. The buffer settings specify how the table should be buffered, if necessary. You can also define whether modifications to the table entries should be logged.




FRAGMENTING THE TABLES IN THE DATABASE

One way to defragment the indexes is to simply delete and reenter them. The database once again calculates the content and structure of the index, and creates a single memory space, where possible, in the storage medium. During this process, you can still use the database tables.
You can reduce fragmentation in fragmented tables by converting them. All the data is first transferred to a new table created by the SAP system. The old table is deleted and replaced by the new one. If the new table grows unexpectedly and quickly, it is also checked again, before being converted.

DATA CLASS

A data class logically defines the physical area of the database in which your table should be stored. If defined correctly, tables will automatically be created in the right areas on the database, when they are activated in the ABAP Dictionary.
The four main data classes are
  master data,

  transaction data,

  organizational data, and

  system data.

Master data is rarely modified. One example of master data is an address file, with a name, an address, and a telephone number.
Transaction data, on the other hand, is frequently modified. An example of transaction data is the material stock of a warehouse, which can change after every purchase order.
The third main data class, organizational data, is defined during Customizing when the system is installed. It is rarely modified after that. Country keys are examples of organizational data.
The last data class, system data, is the data required by the SAP System itself. Program sources are examples of system data.


SIZE CATEGORY

The size category describes the expected storage requirements for a table in a database.
When a table is initially created in the database, a fixed extent is reserved for it, irrespective of its size category. If more space is required later, additional extents can be added. The sizes of these additional extents are fixed and are determined by the size category specified in the ABAP Dictionary.
Size categories range from 0 to 4.


LOGGING

Logging is used to record and store modifications to the entries of a table.
However, this option is available only if the SAP System contains the parameter rec/client, which can be set to different values to define which clients have log access.
Data modifications are logged independently of the update.

OVERVIEW OF THE DB TABLES TYPE

Pooled and cluster tables are other database table types.
The definition of transparent tables is identical in both the ABAP Dictionary and the database. In contrast, pooled and cluster tables comprise several tables, which are logically defined in the ABAP Dictionary, but are combined into a single physical database table.



CLUSTER TABLES

Cluster tables store functionally dependent data, divided among different tables, in a single database table. The intersection of the key fields of the cluster tables, or the key of the table cluster, is called the cluster key.
Data dependent on a single cluster key is stored in the VARDATA field of the table cluster.
The database interface also compresses the contents of the VARDATA field. The latter, therefore, includes a description for decompressing its data.
The PAGNO field of the cluster table ensures that all entries are unique; while the TIMESTAMP and PAGELG fields contain administrative information.


POOLED TABLES

Table pools, unlike the table clusters, store data records from independent tables defined in the ABAP Dictionary.
This example depicts the intersection of the key fields of TABA and TABB, which is empty. Despite this difference, the data records from TABA and TABB are stored in a single database table, the TABAB table pool.
The key for a data record of the TABAB table pool consists of a combination of the fields TABNAME and VARKEY.
The TABNAME field assumes the name of the pooled table.
The VARKEY field comprises the key fields of the pooled table.
The VARDATA field contains the non-key fields of the pooled tables, stored in an unstructured way. These are also compressed by the database interface. The length of the VARDATA field is stored in the DATALN field.



DESCRIBE THE ADVANTAGES AND DISADVANTAGES OF POOLED AND CLUSTER TABLES

Pooled and cluster tables contain far fewer tables, as a direct result of the combination of tables and of data compression.
This translates into fewer different SQL statements.
The main disadvantage of pool and cluster tables is the limited database functionality. There is no support for primary or secondary indices, database views, ABAP JOINs, or Table Appends. Moreover, the data in these tables can only be accessed through OPEN SQL .