EVENTS In ABAP

Event Block

•Reporting events

INITIALIZATION
START-OF-SELECTION
GET
END-OF-SELECTION

•Selection screen events

AT SELECTION-SCREEN OUTPUT
AT SELECTION-SCREEN ON VALUE REQUEST
AT SELECTION-SCREEN ON HELP REQUEST
AT SELECTION-SCREEN ON
AT SELECTION-SCREEN ON BLOCK
AT SELECTION-SCREEN ON RADIOBUTTON GROUP
AT SELECTION SCREEN
AT SELECTION SCREEN ON END OF

•List events

TOP-OF-PAGE
END-OF-PAGE
AT LINE-SELECTION
AT PF
AT USER-COMMAND

Some Important ALV Function modules

REUSE_ALV_LIST_DISPLAY
REUSE_ALV_GRID_DISPLAY
REUSE_ALV_BLOCK_LIST_APPEND
REUSE_ALV_BLOCK_LIST_DATA_GET
REUSE_ALV_BLOCK_LIST_DATA_SET
REUSE_ALV_BLOCK_LIST_DISPLAY
REUSE_ALV_BLOCK_LIST_HS_APPEND
REUSE_ALV_BLOCK_LIST_INIT
REUSE_ALV_BLOCK_LIST_REFRESH
REUSE_ALV_BLOCK_STATUS_GET
REUSE_ALV_CHECKBOX_SET
REUSE_ALV_COMMENTARY_WRITE
REUSE_ALV_EVENTS_GET
REUSE_ALV_EVENTS_TRANSFER
REUSE_ALV_EVENT_NAMES_GET
REUSE_ALV_FIELDCATALOG_MERGE
REUSE_ALV_HIERSEQ_LIST_DISPLAY
REUSE_ALV_HS_LIST_WIDTH_GET
REUSE_ALV_HS_TABLES_GET
REUSE_ALV_LIST_DISPLAY
REUSE_ALV_LIST_LAYOUT_INFO_GET
REUSE_ALV_LIST_LAYOUT_INFO_SET
REUSE_ALV_LIST_WIDTH_GET
REUSE_ALV_POPUP_TO_SELECT
REUSE_ALV_TABLES_GET
REUSE_ALV_TABLE_CREATE

Internal table

Purpose of Internal Tables

• In ABAP/4, you work mainly with tables. Tables are the essential data structures in the R/3 System. Long-life data is stored in relational database tables.


• Besides database tables, you can create internal tables which exist only during the runtime of your program. ABAP/4 provides various operations for working with internal tables. You can, for example, search for, append, insert, or delete lines.


• The number of lines in an internal table is not fixed. Depending on requirements, the system increases the size of internal tables at runtime.


• You can use internal tables to perform table calculations on subsets of database tables. For example, you can read a certain part of a database table into an internal table (see Reading Data into an Internal Table).

From the internal table, you can then calculate totals or generate a ranked list.


• Another use for internal tables is reorganizing the contents of database tables according to the needs of your program. For example, you can read data relevant for creating a telephone list from one or several large customer tables into an internal table. During the runtime of your program, you can then access this list directly without having to perform a time-consuming database query for each call.

Structure of Internal Tables

In ABAP/4, you can distinguish between internal table data types, which define the structure of internal tables, and internal table data objects, which are the actual internal tables and can be filled with data. An internal table data type is an abstract definition of a data structure which can be used to declare data objects as internal tables.

Data type

An internal table is one of the two structured data types in ABAP/4. The other structured data type is the field string. An internal table consists of any number of lines which all have the same data type. The data type of the lines can be elementary or structured.

This definition opens a variety of internal table structures which range from lines consisting of one field to lines consisting of field strings which have internal tables as components.


You can define a data type as an internal table by using the TYPES statement with the OCCURS parameter. No memory is occupied when defining a data type.

Data object

A data object which has a data type defined as an internal table is the actual internal table you work with. It occupies memory and you can fill or read its lines.
You create a data object as an internal table by using the DATA statement either with the OCCURS parameter or by referring to another internal table by using the TYPE or LIKE parameters.

Identifying Table Lines

In order to access a certain line of a table, you must specify a field or combination of fields that can be used to identify the line. In the relational data model which is used to store long-life data in the R/3 System, the minimum combination required for this purpose is known as the key. The fields that define the key are called key fields.

Internal Table Index

The index is the sequential number of a table line. It is not a table field, but is created and managed automatically by the system.


You can use the index with the DELETE, INSERT, MODIFY, LOOP, and READ statements. In these statements, you can specify the index either as literal or as variable.
After processing a particular line of an internal table, the system field SY-TABIX generally contains the index of that line.

Internal Table Key

There are two kinds of internal table keys.

Self-defined Key

When reading lines from an internal table using the READ statement, you can specify a self-defined.

Standard Key

By definition, the key fields of an internal table are those fields which are not numeric (type F, I, and P) and are not internal tables. These key fields form the standard key of an internal table.


To obtain the standard key of an internal tables with nested structures (table lines which contain field strings as components), the system breaks down the sub-structures to the level of elementary fields.

LUW - Logical Unit of Work

An SAP logical unit of work (LUW) is a functionally complete set of steps within a business process in the R/3 System.

The process steps must be logically related.

SAP LUWs work on an all-or-nothing principle: Either all or none of its steps are carried out.

The business process to be mapped must be basic. For example, you would not have a single SAP LUW consisting of all of the steps between a customer processing an order and an invoice being produced. Instead, you would split this up into separate parts, each of which would then be represented in the R/3 System by its own LUW. What constitutes an "elementary" process depends on the overall process and how you have modeled it.

For further information, see the ABAP Editor Keyword documentation for the term transaction processing.

A database logical unit of work (LUW) is a non-separable sequence of database operations. At the beginning and end of the LUW, the database is in a consistent state.

The database LUW is either fully carried out by the database system, or is not carried out at all.

A database LUW is opened with every dialog step and by a database commit of the previous DB LUW.

The database LUW is closed with a database commit. It is only in the commit that the data is written to the database (after which it can no longer be reversed). Before the database commit, you can undo the changes using a database rollback. Here, the database is reset to the status that it had before the first change was made to the current DB LUW.

Data that has been written to the database permanently with a database commit cannot be rolled back.

Database LUWs allow you to encapsulate logically related actions from a business process. For example, when transferring sums of money in financial accounting, you must deduct an amount from one account and then add it to another account. Before and after the process, the data is consistent, but in between the two steps, it can be inconsistent.

For further information, see the ABAP Editor Keyword documentation for the term transaction processing.

The SAP R/3 System is based on the three-tier architecture of a client/server system. The three tiers are the database, application, and presentation server layers.

This architecture, along with the distribution of users' requests (user dispatching), leads to a highly efficient, cost-effective multi-user system.

The three-tier architecture means that a large number of users with low-cost desktop computers (with low performance) can be mapped to a small number of high-performance (and considerably more expensive) work processes on application servers. Each work process on an application server is assigned a work process on a high-performance database server.

Distributing user requests to work processes assigns individual clients at presentation server level to a work process for a particular period. In turn, the work process uses another work process in the database. After the work process has processed the user input in a dialog step, the user, along with the program context, is removed from the work process, which can then be used by another user.


The three-tier architecture is far more scalable than a "fat" client architecture, in which the Presentation and application levels run on one server. With three-tier architecture, the number of database users is considerably lower than the number of users active in the system. This has a positive effect on the behavior of the database.


The three-tier architecture of the R/3 System has certain consequences for process handling. When a work process is released for use by another user (client), an implicit database commit is triggered for the database process assigned to it (via a basis program).

Work processes on the application server and database are released before each user dialog. This Ensures that long user dialogs in which the system is "only displaying a screen" are not included in Database LUWs. The duration of the user interaction will be longer than the DB LUW duration.


Shorter database LUWs lead to less load on the database.

Implicit commits on the database are triggered whenever the work process has to wait. This includes:

When the system sends a new screen
When the system sends a dialog message
When you make a synchronous remote function call (RFC)
When you use the CALL TRANSACTION or SUBMIT statement.

Using an SAP LUW to represent a business process chain usually involves user dialogs as well as the changes to the database. The aim of an R/3 transaction is to represent the information exchanged in the SAP LUW as an indivisible unit in the database. This means that an SAP LUW can only use a single database LUW.

Since SAP LUWs usually involve several database LUWs, you need to bundle the database changes in a single database LUW within your transaction.

ABAP List Viewer

ABAP List Viewer
The common features of report are column alignment, sorting, filtering, subtotals, totals etc. To implement these, a lot of coding and logic is to be put. To avoid that we can use a concept called ABAP List Viewer (ALV).
Using ALV, we can have three types of reports:
1. Simple Report
2. Block Report
3. Hierarchical Sequential Report
There are some function modules which will enable to produce the above reports without much effort.
All the definitions of internal tables, structures
and constants are declared in a type-pool called SLIS.
Simple Report
The important function modules are:
•Reuse_alv_list_display
•Reuse_alv_fieldcatalog_merge
•Reuse_alv_events_get
•Reuse_alv_commentary_write
•Reuse_alv_grid_display
A. REUSE_ALV_LIST_DISPLAY: This is the function module which prints the data.
The important parameters are:
1. Export:
a. I_callback_program : report id
b. I_callback_pf_status_set : routine where a user can set his own pf status or change the
functionality of the existing pf -status.
c. I_callback_user_command : routine where the function codes are handled.
d. I_structure name : name of the dictionary table
e. Is_Layout : structure to set the layout of the report
f. It_fieldcat : internal table with the list of all fields and their attributes which are to
be printed (this table can be populated automatically by the function
module REUSE_ALV_FIELDCATALOG_MERGE)
g. It_events : internal table with a list of all possible events of ALVand their
corresponding routine names.
2. Tables:
a. t_outtab : internal table with the data to be output
B. REUSE_ALV_FIELDCATALOG_MERGE:
This function module is used to populate a fieldcatalog which is essential to display the data in ALV. If the output data is from a single dictionary table and all the columns are selected, then we need not exclusively create the field catalog. Its enough to mention the table name as a parameter(I_structure_name) in the REUSE_ALV_LIST_DISPLAY. But in other cases we need to create it.
The important parameters are:
1. Export:
a. I_program_name : report id
b. I_internal_tabname : the internal output table
c. I_inclname : include or the report name where all the dynamic forms are handled.
2. Changing
ct_fieldcat : an internal table with the type SLIS_T_FIELDCAT_ALV which is declared in
the type pool SLIS.
C . REUSE_ALV_EVENTS_GET: Returns table of possible events for a a list type
1. Import:
Et_Events : The event table is returned with all possible CALLBACK events for the
specified list type (column ‘NAME’). For events to be processed by the
callback, their ‘FORM’ field must be filled. If the field is initialized, the event
is ignored. The entry can be read from the event table, the field ‘FORM’ filled
and the entry modified using constants from the type pool SLIS.
2. Export:
I_list_type:
0 = simple list
1 = hierarchical-sequential list
2 = simple block list
3 = hierarchical-sequential block list
D. REUSE_ALV_COMMENTARY_WRITE : This is used in the Top-of-page event to print the headings and other comments for the list.
1. It_list_commentary : Internal table with the headings of the type slis_t_listheader.
This internal table has three fields:
Typ : ‘H’ - header, ‘S’ - selection, ‘A’ - action
Key : only when typ is ‘S’.
Info : the text to be printed
E. REUSE_ALV_GRID_DISPLAY: A new function in 4.6 version, to display the results in grid rather than as a list.
Parameters : same as reuse_alv_list_display
HIERARCHICAL REPORTS
A. REUSE_ALV_HIERSEQ_LIST_DISPLAY
1. Export:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
d. IS_LAYOUT
e. IT_FIELDCAT
f. IT_EVENTS
g. I_TABNAME_HEADER : Name of the internal table in the program containing the output data of the
highest hierarchy level.
h. I_TABNAME_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
i. IS_KEYINFO : This structure contains the header and item table field names which link the two tables
(shared key).
2. Tables
a. T_OUTTAB_HEADER : Header table with data to be output
b. T_OUTTAB_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
BLOCK REPORT
This is used to display multiple lists continuously.
The important functions used in this report are:
A. REUSE_ALV_BLOCK_LIST_INIT
B. REUSE_ALV_BLOCK_LIST_APPEND
C. REUSE_ALV_BLOCK_LIST_DISPLAY
D. REUSE_ALV_BLOCK_HS_LIST_APPEND
A. REUSE_ALV_BLOCK_LIST_INIT
Parameters:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
This function module is used to set the default GUI status etc.
B. REUSE_ALV_BLOCK_LIST_APPEND
Export :
a. IS_LAYOUT : layout settings for block
b. IT_FIELDCAT : field catalog
c. I_TABNAME : Internal table name of the output data
d. IT_EVENTS : internal table name with all possible events
Tables :
a. T_OUTTAB : internal table with output data.
This function module adds the data to the block.
INTERNAL TABLES IN SLIS
Slis_t_fieldcat_alv :
This internal table contains the field attributes. This internal table can be populated automatically by using ‘REUSE_ALV_FIELDCATALOG_MERGE’.
Important Attributes:
a. col_pos : position of the column
b. fieldname : internal fieldname
c. tabname : internal table name
d. ref_fieldname : fieldname (dictionary)
e. ref_tabname : table (dictionary)
f. key(1) : column with key-color
g. icon(1) : icon
h. hotspot(1) : hotspot
i. Symbol(1) : symbol
j. Checkbox(1) : checkbox
k. just(1) : (R)ight (L)eft (C)ent
l. do_sum(1) : sum up
m. no_out(1) : (O)blig. (X)no out
n. outputlen : output length
o. seltext-l : long key word
p. seltext_m : middle key word
q. seltext_s : short key word
r. reptext_ddic : heading(ddic)
s. ddictxt(1) : (S)hort (M)iddle (L)ong
t. datatype : datatype
SLIS_T_EVENT :
Internal table for storing all the possible events of the ALV. This can be populated by the function module Reuse_alv_events_get
The columns are :
name : name of the event
form : name of the routine
SYNTAXES FOR THE ROUTINES
I_CALLBACK_PF_STATUS_SET
Syntax :
FORM set_pf_status USING rt_extab TYPE slis_t_extab
The table RT_EXTAB contains the function codes which are hidden in the standard interface.
I_CALLBACK_USER_COMMAND
Syntax :
FORM user_command USING r_ucomm LIKE sy-ucomm
rs_selfield TYPE slis_selfield.
The parameter r_ucomm contains the function code.
The structure rs_selfield has the details about the current cursor position.

Open SQL vs Native SQL

Question : What is Open SQL vs Native SQL?

Question :What does an EXEC SQL statement do in ABAP? What is the disadvantage of using it?

If you write a business application, there is always a database on backend. So SAP R/3 uses a database too. It is a
special database? No. SAP uses standard databases like Oracle, IBM DB2, MS SQL Server, etc. If you have a database on backend, it is inevitable that you must use SQL. SAP uses SQL to select, insert and update data inside database. However, the problem is that if you use different databases, your code whatever it is whether ABAP or not, SQL can vary. In that situation although programmers tend to use Standard SQL which is valid for all databases, the problems sometimes occur to switch one database to different database. What I am trying to say is SAP had invented a new way to solve this problem: Open SQL

Open SQL

Open SQL consists of a set of ABAP statements that perform operation on central database in the R/3 System. The results of the operations and any error messages are independent of the database system in use. Open SQL thus provides a uniform syntax and semantics for all of database systems supported by SAP. ABAP programs that only use Open SQL statements will work in any SAP R/3 System, regardless of the database system in use. Open SQL statements can work with database tables that have been created in the ABAP Dictionary.

The method actually is simple that when a programmer writes an ABAP program with Open SQL statements, the kernel SAP programs convert Open SQL statements to real / native SQL statements for database in use. So like that write once, run for all databases and even for all operating systems. Like Java’s “Write Once. Run Anywhere“. Think about Java, even the Java uses the same principal that is Java Virtual Machine which looks like SAP’s kernel programs. Right? Can we say SAP did “Write Once. Run Anywhere” before Java?

Open SQL contains the following keywords:

• SELECT - Reads data from database tables.
• INSERT - Adds lines to database tables.
• UPDATE - Changes the contents of lines of database tables.
• MODIFY - Inserts lines into database tables or changes the contents of existing lines.
• DELETE - Delete lines from database tables.
• OPEN CURSOR, FETCH, CLOSE CURSOR - Reads lines of database tables using the cursor.

All Open SQL statements fill the following two system fields with return codes:

• SY-SUBRC
  After every Open SQL statement, the system field SY-SUBRC contains 0 if the operation was successful, a value other than 0 if not.
• SY-DBCNT
  After an OPEN SQL statement, the system field SY-DBCNT contains the number of database lines processed.

Native SQL

Native SQL is real SQL for database in use. It means beside OPEN SQL, if you need you can use the native SQL for databases. Native SQL allows you to use database-specific SQL statements in an ABAP program. This means that you can use database tables that are not administered by the ABAP Dictionary, and therefore integrate data that is not part of the R/3 System.

As a rule, an ABAP program containing database-specific SQL statements will not run under different database systems. If your program will be used on more than one database platform, only use Open SQL statements.

I have never used Native SQL in my experiences more than 6 years for ABAP programming. I tried it, you can be sure it works. All ABAP programs in SAP R/3 System have been written with Open SQL. But I sometimes encountered Native SQL statements in original ABAP programs. I think if you have a different database instant in the same database, you can use Native SQL statement to connect and do operation on this database instant. Let me clarify this a little bit. Let’s assume you have an SAP R/3 system that uses Oracle database instant ORC1. You have an other application, even it uses the same database Oracle, but as normally different database instant ORC2. So like data inside ABAP program, you can use Native SQL statements to connect ORC2, non-SAP database instant, to integrate SAP R/3 and non-SAP system. It is kind of an integration activity.

If you create a table by using database tools, without ABAP Dictionary, you are not able to use Open SQL to reach this table. You just can use Native SQL to do that.

Native SQL statements bypass the R/3 database interface. There is no table logging, and no synchronization with the database buffer on the application server. For this reason, you should, wherever possible, use Open SQL to change database tables declared in the ABAP Dictionary. In particular, tables declared in the ABAP Dictionary that contain log columns with types LCHR and LRAW should only be addressed using Open SQL, since the columns contain extra, database-specific length information for the column. Native SQL does not take this information into account, and may therefore produce incorrect results. Furthermore, Native SQL does not support automatic client handling. Instead, you must treat client fields like any other.

To ensure that transactions in the R/3 System are consistent, you should not use any transaction control statements (COMMIT, ROLLBACK WORK), or any statements that set transaction parameters (isolation level…) using Native SQL.

Using Native SQL, you can

• Transfer values from ABAP fields to the database
• Read data from the database and process it in ABAP programs.

Native SQL works without the administrative data about database tables stored in the ABAP Dictionary. Consequently, it cannot perform all of the consistency check used in Open SQL. This places a larger degree responsibility on application developers to work with ABAP fields of the correct type. You should always ensure that the ABAP data type and the type of database column are identical.

Native SQL Advantages and Disadvantages - EXEC SQL statement

Advantages

• Tables are not declared in ABAP Dictionary can be accessed. (e.g. Tables belonging to sys or system user of Oracle, etc.)
• To use some of the special features supported by the database-specific SQL. (e.g. Passing hints to Oracle optimizer.)

Disadvanteges

• No syntax check is performed whatever is written between EXEC and ENDEXEC.
• ABAP program containing database-specific SQL statements will not run under different database systems.
• There is no automatic client handling for client dependent tables.
• Care has to be taken during migration to higher versions.

LOGICAL DATABASES

In general, the system reads data that will appear in a list from the database.

You can use OPEN SQL or NATIVE SQL statements to read data from the database.

The use of a logical database provides you with an alternative to having to program database accesses individually. Logical databases retrieve data records and make them available to ABAP programs.

The same logical database can be the data source for several Quick Views, queries, and programs. In the Quick View, the LDB can be specified directly as a data source. A query works with the logical database when the functional area that generated the query is defined with a logical database. In the case of type 1 programs, the LDB is entered in the attributes or called using function module LDB_PROCESS. See appendix for information on how to use the function module.

Logical databases offer several advantages:

The system generates a selection screen. The use of selection screen versions or variants provides the required flexibility.

The user does not have to know the exact structure of the tables involved (especially the foreign key dependencies); the data is made available in the correct order at GET events.

Performance improvements within logical databases directly affect all programs linked to the logical database, without having to change the programs themselves.

Maintenance can be performed at a central location.

Authorization checks can also be performed centrally.

A logical database is an ABAP program that reads predefined data from the database and makes it available to other programs.

A hierarchical structure determines the order in which the data is supplied to the programs. A logical database also provides a selection screen that checks user entries and conducts error dialogs. These can be extended in programs.

SAP provides some 200 logical databases in Release 4.6. The names of logical databases have been extended to 20 places in Release 4.0 (namespace prefix max. 10 characters).

In the case of executable programs, you can enter a logical database in the attributes.

Use the NODES statement to specify the nodes of the logical database that You want to use in the program. NODES allocates the appropriate storage space for the node - that is, a work area or a table area depending on the node type.

The logical database makes the data records available for the corresponding GET events.
The sequence in which these events are processed is determined by the structure of the logical database.

Logical databases are made up of several sub-objects. The structure determines the hierarchy, and thus the read sequence of the data records.

Node names can contain up to 14 characters. There are four different node types.

Table (type T): The node name is the name of a transparent table (this type corresponds to the concept prior to Release 4.0A). The table name must be identical to the node name. Deep types (complex) are not allowed.

DDIC type (type S): Any node name is possible. It is assigned a structure or a table type from the Dictionary. The node name can differ from the type name. Deep structures are possible.

Type groups (type C): The node type is defined in a type group. The name of the type group must be maintained in the "Type group" field. You should generally prefer DDIC types, as the other applications that use the logical database (such as SAP Query) can access them (short texts, and so on).

Dynamic nodes (type A): These nodes do not have a fixed type; they are not classified until the program runtime. Which types are generally allowed is determined when the structure is created.

Nodes are declared using language element NODES.

Processing blocks are always allocated to an event. A processing block is closed by the next event key word, the start of form routines, or by the end of the program.

The START-OF-SELECTION event is triggered before control is given to the read routine of the logical database. The END-OF-SELECTION event is triggered after all GET events have been processed - that is, all data records have been read and processed.

The GET event is triggered whenever the logical database supplies data for this node. This means that GET events are processed several times, and that data has already been read from the database for these events. The sequence in which the GET events are processed is determined by the structure of the logical database.

The GET LATE event is triggered when all subordinate nodes of node have been processed, before the data is read for the next ; that is, whenever a hierarchy level has been completed.

At the start of the event, the system automatically adds a line feed and configures the default formats (for example, INTENSIFIED ON).

CHECK statements end the current processing block.

STOP statements end program processing. However, in contrast to the EXIT statement, the processing block END-OF-SELECTION is processed first (if it exists).

If there is a STOP statement within the END-OF-SELECTION processing block, program processing ends immediately and a list is displayed.

The EXIT statement exits the program and displays the list.

You can also use the REJECT statement. The data record is not processed further. Processing continues on the same hierarchy level when the next data record is read. REJECT, unlike the CHECK statement, can also be used within a subroutine.

Use the selection include dbsel to define selection screens for logical databases. The addition FOR NODE assigns selections to individual logical nodes. The appearance of a selection screen thus directly depends on the NODES statement contained within your program.

A field selection can be defined for the individual nodes. To do this, you have to specify the addition FIELD SELECTION FOR NODE in the SELECTION-SCREEN statement. You can then use GET FIELDS to restrict the amount of data returned.

You can designate individual nodes for dynamic selection using the addition DYNAMIC SELECTIONS FOR NODE. The Dynamic selection pushbutton then appears on your selection screen. You can determine which selection fields can be set by choosing a particular selection view yourself (type: CUS) or by using the selection view delivered by SAP (type: SAP).

With large logical databases you can define several selection screen versions. Each selection screen version contains a subset of your selection criteria (language element: EXCLUDE). Specify the name of a selection screen version in the program attributes.

When you enter a logical database in the attributes of your type 1 program, the system processes the selection screen of the logical database. The concrete characteristics of the selection screen depend upon the node specified in the NODES statement. If you specify a node of type T (table), you can also declare the table work area with the TABLES statement.

If you address only subordinate nodes (in the hierarchy) of the logical database in the program (for example sflight), the selection screen criteria for the superior node in the hierarchy (spfli) also appear. You can thus restrict the dataset to be read so that it meets your specific requirements.

Note: A logical database always reads in accordance with its structure. This means that if you only need data from a node deep in the hierarchy, you will achieve better performance by programming the access yourself. This avoids unnecessary reading of the database.

If the logical database supports dynamic selections, the pushbutton for Dynamic selections appears on the selection screen. When the user presses this button, a second selection screen is displayed.
This screen allows the user to select additional database fields. The system transfers the selections directly to the logical database program and therefore to the database (dynamic selections).

he selection view determines which fields are displayed on the selection screen. Create your own view with type CUS, and have it override the view with type SAP.

Database program sapdb for logical database is a collection of subroutines, each of which is performed for specific events. For example, subroutine is processed once at the start of the database program. This program can be used to define default values for the selection screen of the LDB.

Other subroutines also exist that are processed during events PBO (Process Before Output) and PAI (Process After Input) of the selection screen. Checks, such as authorization checks (AUTHORITY-CHECK), are usually performed during event PAI.

The database accesses (SELECT statements) are programmed in the put_ subroutines. These subroutines may be processed several times, depending on which selection criteria the user specifies. The sequence in which these subroutines are processed is determined by the structure of the logical database.

Database access (SELECT statements) should be programmed with optimal performance in mind. When creating a logical database you generate the corresponding database program after first having determined its structure and selection attributes. You can find performance tips in the comment lines.

When a program that has been assigned a logical database is started, control is initially passed to the database program of the logical database. Each event has a corresponding subroutine in the database program - for example, subroutine init for event INITIALIZATION. During the interaction between the LDB and the associated program, the subroutine is always processed first, followed by the event (if there is one in the report).

Logical database programs read data from a database according to the structure declared for the logical database. They begin with the root node and then process the individual "branches" consecutively from top to bottom.

The logical database reads the data in the put_ subroutines. During event PUT, control is passed from the database program to the GET event of the associated report.

The data is made available in the corresponding work areas in the report. The processing block defined for the GET event is performed. Control then returns to the logical database.
PUT activates the next form subroutine found in the structure. This flow is continued until the report has collected all the available data.

The depth of data read in the structure depends upon a program's GET events. A logical database reads to the lowest GET event contained within the structure attributes. Only those GET events for which processing is supposed to take place are written into the report program. Logical databases read all data records found on the direct access path.

If you specify a logical database and declare additional selections in the program attributes that refer to the fields of a node not designated for dynamic selection, you must use the CHECK statement to see if the current data record fulfills the selection criteria.

If the data record does not fulfill these selection criteria, current event block processing ends.

INTERNAL TABLE

Purpose of Internal Tables

• In ABAP/4, you work mainly with tables. Tables are the essential data structures in the R/3 System. Long-life data is stored in relational database tables.


• Besides database tables, you can create internal tables which exist only during the runtime of your program. ABAP/4 provides various operations for working with internal tables. You can, for example, search for, append, insert, or delete lines.


• The number of lines in an internal table is not fixed. Depending on requirements, the system increases the size of internal tables at runtime.


• You can use internal tables to perform table calculations on subsets of database tables. For example, you can read a certain part of a database table into an internal table (see Reading Data into an Internal Table).

From the internal table, you can then calculate totals or generate a ranked list.


• Another use for internal tables is reorganizing the contents of database tables according to the needs of your program. For example, you can read data relevant for creating a telephone list from one or several large customer tables into an internal table. During the runtime of your program, you can then access this list directly without having to perform a time-consuming database query for each call.

Structure of Internal Tables

In ABAP/4, you can distinguish between internal table data types, which define the structure of internal tables, and internal table data objects, which are the actual internal tables and can be filled with data. An internal table data type is an abstract definition of a data structure which can be used to declare data objects as internal tables.

Data type

An internal table is one of the two structured data types in ABAP/4. The other structured data type is the field string. An internal table consists of any number of lines which all have the same data type. The data type of the lines can be elementary or structured.

This definition opens a variety of internal table structures which range from lines consisting of one field to lines consisting of field strings which have internal tables as components.


You can define a data type as an internal table by using the TYPES statement with the OCCURS parameter. No memory is occupied when defining a data type.

Data object

A data object which has a data type defined as an internal table is the actual internal table you work with. It occupies memory and you can fill or read its lines.
You create a data object as an internal table by using the DATA statement either with the OCCURS parameter or by referring to another internal table by using the TYPE or LIKE parameters.

Identifying Table Lines

In order to access a certain line of a table, you must specify a field or combination of fields that can be used to identify the line. In the relational data model which is used to store long-life data in the R/3 System, the minimum combination required for this purpose is known as the key. The fields that define the key are called key fields.

Internal Table Index

The index is the sequential number of a table line. It is not a table field, but is created and managed automatically by the system.


You can use the index with the DELETE, INSERT, MODIFY, LOOP, and READ statements. In these statements, you can specify the index either as literal or as variable.
After processing a particular line of an internal table, the system field SY-TABIX generally contains the index of that line.

Internal Table Key

There are two kinds of internal table keys.

Self-defined Key

When reading lines from an internal table using the READ statement, you can specify a self-defined.

Standard Key

By definition, the key fields of an internal table are those fields which are not numeric (type F, I, and P) and are not internal tables. These key fields form the standard key of an internal table.


To obtain the standard key of an internal tables with nested structures (table lines which contain field strings as components), the system breaks down the sub-structures to the level of elementary fields.