TABLE TYPES IN SAP

TABLE TYPES IN SAP:

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.

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.

TYPES OF VIEWS IN SAP

TYPES OF VIEWS IN SAP:

Views :Data about an application object is often distributed on several tables. By defining a :view, you can define an application-dependent view that combines this data. The structure of such a view is defined by specifying the tables and fields used in the view. Fields that are not required can be hidden, thereby minimizing interfaces. A view can be used in ABAP programs for data selection.

The data of a view is derived from one or more tables, but not stored physically. The simplest form of deriving data is to mask out one or more fields from a base table (projection) or to include only certain entries of a base table in the view (selection). More complicated views can comprise several base tables, the individual tables being linked with a relational join operation.


The base tables of the view must be selected in the first step of a view definition. In the second step, these tables must be linked by defining the join conditions. It is also possible to use the join condition from a foreign key defined between the tables .
In the third step, you must select the fields of the base tables to be used in the view. Selection conditions that restrict the records in the view can be formulated in the fourth step.
Four different view types are supported. These differ in the way in which the view is implemented and in the methods permitted for accessing the view data.


•Database views implemented with an equivalent view on the database.
•Projection views used to hide fields of a table (only projection).
•Help views used as selection method in search helps
•Maintenance views permit you to maintain the data distributed on several tables for one application object at one time.
Database views implement an inner join. The other view types implement an outer join


The join conditions for database views can be formulated using equality relationships between any base fields. The join conditions for the other view types must be obtained from existing foreign keys. Tables therefore can only be combined in a maintenance view or help view if they are linked to one another with foreign keys.
The maintenance status whether you can only read data with the view or whether you can also insert and change data with it.


Database Views :
Data about an application object is often distributed on several database tables. A database view provides an application-specific view on such distributed data.
Database views are defined in the ABAP Dictionary. A database view is automatically created in the underlying database when it is activated.
Application programs can access the data of a database view using the database interface. You can access the data in ABAP programs with both OPEN SQL and NATIVE SQL. However, the data is actually selected in the database. Since the join operation is executed in the database in this case, you can minimize the number of database accesses in this way. Database views implement an inner join (see Inner and Outer Join )


If the database view only contains a single table, the maintenance status can be used to determine if data records can also be inserted with the view. If the database view contains more than one table, you can only read the data.
Database views should be created if want to select logically connected data from different tables simultaneously. Selection with a database view is generally faster than access to individual tables. When selecting with views, you should also ensure that there are suitable indexes on the tables contained in the view.
Since a database view is implemented in the database, a database view may only contain transparent tables.
The technical settings of a database view control whether the view data should be buffered.
Projection Views :
Projection views are used to hide fields of a table. This can minimize interfaces; for example when you access the database, you only read and write the field contents actually needed.
A projection view contains exactly one table. You cannot define selection conditions for projection views.
There is no corresponding object in the database for a projection view. The R/3 System maps the access to a projection view to the corresponding access to its base table. You can also access pooled tables and cluster tables with a projection view.
The maintenance status of the view controls how the data of the table can be accessed with the projection view.




Help Views:
You have to create a help view if a view with outer join is needed as selection method of a search help
The selection method of a search help is either a table or a view. If you have to select data from several tables for the search help, you should generally use a database view as selection method. However, a database view always implements an inner join. If you need a view with outer join for the data selection, you have to use a help view as selection method.


All the tables included in a help view must be linked with foreign keys. Only foreign keys that have certain attributes can be used here. The first table to be inserted in the help view is called the primary table of the help view. The tables added to this primary table with foreign keys are called secondary tables.
The functionality of a help view has changed significantly between Release 3.0 and Release 4.0. In Release 3.0, a help view was automatically displayed for the input help (F4 help) for all the fields that were checked against the primary table of the help view. This is no longer the case in Release 4.0.
As of Release 4.0, you must explicitly create a search help that must be linked with the fields for which it is offered (see Linking Search Helps with Screen Fields ).
Existing help views are automatically migrated to search helps when you upgrade to a release higher than 4.0.
A help view implements an outer join, i.e. all the contents of the primary table of the help view are always displayed. You therefore should not formulate a selection condition for fields in one of the secondary tables of the help view. If records of these secondary tables cannot be read as a result of this selection condition, the contents of the corresponding fields of the secondary table are displayed with initial value.

Search Helps :
The input help (F4 help) is a standard function of the R/3 System. The user can display the list of all possible input values for a screen field with the input help. The possible input values can be enhanced with further information. This is meaningful especially when the field requires the input of a formal key.
Standard Input Help Process
A user calls an input help with the following steps (some steps can be omitted, depending on the definition of the input help):
The user starts the input help to display the possible input values for a field (search field) in a screen template.
The system offers the user a number of possible search paths. The user selects one of these search paths. Each search path offers a number of restrictions to limit the number of possible input values. These values are offered in a Dialog box for value restriction when the search path is selected.
The user enters restrictions if required and then starts the search.


The system determines the values that satisfy the entered restrictions (hits) and displays them as a list (hit list).


The user selects the most suitable line from the hit list by double-clicking. The value of the search field is returned to the screen template (possibly together with other values).
Steps 2 and 3 are omitted if there is only a single search path available. In this case the dialog box for the value selection is offered immediately. You can also output the hit list directly after starting the input help. Steps 2 to 4 are omitted in this case.
Function of a Search Help
This standard process can be completely defined by creating a search help in the ABAP Dictionary. This search help only has to be assigned to the screen fields in which they should be available.
There are two types of search help:
•Elementary search helps describe a search path. The elementary search help must define where the data of the hit list should be read from (selection method), how the exchange of values between the screen template and selection method is implemented (interface of the search help) and how the online input help should be defined (online behavior of the search help).
•Collective search helpscombine several elementary search helps. A collective search help thus can offer several alternative search paths.

Maintenance Views :
Maintenance views offer easy ways to maintain complex application objects.
Data distributed on several tables often forms a logical unit, for example an application object, for the user. You want to be able to display, modify and create the data of such an application object together. Normally the user is not interested in the technical implementation of the application object, that is in the distribution of the data on several tables.
A maintenance view permits you to maintain the data of an application object together. The data is automatically distributed in the underlying database tables. The maintenance status determines which accesses to the data of the underlying tables are possible with the maintenance view.
All the tables in a maintenance view must be linked with foreign keys, that is the join conditions for maintenance views are always derived from the foreign key
cannot directly enter the join conditions as for database views.
There are some restrictions for the attributes of the foreign keys with which the tables in a maintenance view can be linked .

A standardized table maintenance transaction is provided (SM30), permitting you to maintain the data from the base tables of a maintenance view together.
Maintenance mechanisms, like screens and processing programs, must be created from the view definition with the transaction Generate Table View (SE54). This makes it possible to create easy-to-use maintenance interfaces in a simple manner.

ABAP DATA BASE UPDATES COMPLETE

OVERVIEW: DATABASE UPDATES:


You can update databases either using ABAP's Open SQL commands, or with the database-specific commands of your database's Native SQL command set.

You can access ABAP cluster databases using special ABAP commands.

You can access the data in database tables using the Open SQL commands. The command set includes operations of the Data Manipulation Language (DML). The Data Definition Language (DDL) operations are not available in Open SQL, as these functions are performed by the ABAP Dictionary.

Native SQL commands allow you to carry out both DML and DDL operations.

The commands for ABAP cluster databases enable operations to be carried out on the data in the cluster databases. The tables themselves are created in the ABAP Dictionary as transparent tables.
For general information on cluster tables, refer to the course appendix.

For further information on Native and Open SQL, see the ABAP Editor Keyword documentation for the term SQL.

Each time you access the database using Open SQL, the database interface of each work process (application server) converts this to a database-specific command. For this reason, the ABAP programs themselves are independent of the database used and can be transferred to other system platforms (with a different database system) without additional programming requirements.

SAP database tables can be buffered at the application server level. The aims of buffering are to

Reduce the time needed to access data with read accesses. Data on the application server can be accessed more quickly than data on the database.

Reduce the load on the database. Reading the data from application server buffers reduces the number of database accesses.

The buffered tables are accessed exclusively via database interface mechanisms.

Database accesses with Native SQL enable database-specific commands to be used. This requires a detailed knowledge of the syntax in question. Programs that use Native SQL commands need additional programming after they are transported to different system environments (different database systems), since the syntax of the SQL commands generally varies from one database to the next.

The target quantity can be limited on the database using all the Open SQL commands discussed here.

One or more rows can be processed with a SQL command. Each command also provides the option of specifying the table name dynamically.

In addition to this, each type of operation has a syntax variant, which can be used to change individual fields in a row.

With masked field selections (WHERE LIKE ''), note that '_' masks an individual character and '%' masks a character string of any length (in line with the SQL standard).

For all Open SQL commands, you can edit data in the current client (standard). To do so, you do not specify any command additions and leave the client field non valuated.

If you want to edit data from other clients explicitly, use the SQL command with the addition CLIENT SPECIFIED and enter the number of the client in which the SQL operation is to be carried out in the WHERE clause of the command.

All Open SQL commands return confirmation of the success or failure of the database operation in the form of a return code. This is always returned by the database interface in the sy-subrc system field. The return code '0' (zero) always means that the operation has been completed successfully. All other values mean that errors have occurred. For further details, please refer to the keyword documentation for the command in question.

In addition, the sy-dbcnt system field displays the number of records for which the desired database operation was actually carried out.

Note that Open SQL commands do not perform any automatic authorization checks. You need to carry these out separately (see unit Authorization Checks).

To insert a new row in a database table, enter the command INSERT INTO VALUES . To do so, you must specify the data to be written to the database in the structure (key and non-key fields) before the command.

The structure must be typed according to the row structure of the database table to be updated (DATA TYPE ).

Rows can also be inserted for views. However, there are two restrictions here: The view may only contain fields from one table and must be created in the ABAP Dictionary with maintenance status 'read and change'.

The INSERT command has the two return codes '0' (row could be inserted) and '4' (row could not be inserted, as a row with the same key already exists).

The following ABAP short forms exist:

Short form 1: INSERT [CLIENT SPECIFIED] FROM .

Short form 2: INSERT [CLIENT SPECIFIED].

The second short form requires that the data, which is to be added to the database, be available in a table work area called . This table work area must be declared in the program with TABLES: .

The second short form is forbidden using ABAP Objects.
a database table. The internal table contains the data in the rows that are to be inserted.

The internal table must be typed to row type .

If the operation can be carried on all rows, the return code sy-subrc returns the value zero. If even one data record cannot be created, a runtime error is triggered. This means that no data record is inserted by the command.

You can prevent the runtime error occurring with the addition ACCEPTING DUPLICATE KEYS.

In the event of an error, the addition sets return code 4 instead of the runtime error. The data records that were successfully inserted are not rejected (no DB ROLLBACK)

The sy-dbcnt system field contains the number of rows that were successfully inserted in the database.

The command UPDATE SET = ... = WHERE allows you to change data in one row in a database table. After the SET command, you specify the fields in the rows whose values you want to change and the key of the database row in the WHERE clause. The key must be specified completely; each individual field must be specified with the relational operator '='.

For numeric fields, the data following the SET command may be specified in the form of a "calculation rule" carried out on the database: f = g, f = f + g, f = f - g.
The command has the two return codes 0 (row could be changed) and 4 (row could not be changed).

Rows can also be changed in views. However, there are two restrictions here: The view may only contain fields from one table and must be created in the ABAP Dictionary with maintenance status 'read and change'.

The following g short forms exist:

Short form 1: UPDATE FROM .

Short form 2: UPDATE dbtab.

With short form 1, the entire data record must have been written to the structure (key and non-key fields) before it is called up. The structure must be typed to the row type of the database table (DATA: TYPE . The short form is not field-specific, but sends the entire structure to the database interface.

The second short form requires that the data, which is to be updated in the database, be available in a table work area called . This table work area must be declared in the program with TABLES: .

The second short form is forbidden using ABAP Objects.

If identical changes are to be made to several rows in a table, use the syntax specified on the slide.

Using the WHERE clause, specify the rows for which the change is to be carried out.

The following "calculations" are also possible here for the numerical fields to be changed:

f = g, f = f + g, f = f - g.

The command has the two return codes 0 (at least one row has been changed) and 4 (no rows could be updated).

The sy-dbcnt field contains the number of updated rows in the database table.

There is a short form UPDATE SET = ... = . This requires that a table work area has been created with TABLES and changes the fields specified after SET for all rows in the current client.

The short form is forbidden using ABAP Objects.

If changes are to be made to several rows in a database table, whereby the changes for each row is determined via an internal table, use the syntax UPDATE FROM TABLE .

Here, the internal table contains the data of the rows to be changed (key and non-key fields). The internal table must have the row type .

The command has the two return codes 0 (all rows have been updated) and 4 (at least one row of the internal table was not used to update the database; the remaining rows have been updated).

The system field sy-dbcnt contains the number of rows that have been updated in the database.

The MODIFY command is SAP-specific. It includes the operations of the two commands
INSERT ... and UPDATE...:

In other words, MODIFY FROM inserts a new data record if the structure specifies a data record that does not yet exist in the database.

If the structure specifies an existing data record; the command updates the row in question.

Using the different syntax variants, you can make changes to individual rows, make similar changes to several rows, and carry out operations on sets of records.

All variants of the MODIFY... syntax have the two return codes 0 (all rows were inserted or updated) and 4 (at least one line was not inserted or updated).

The operation can also be carried out on views. However, there are two restrictions here: The view may only contain fields from one table and must be created in the ABAP Dictionary with maintenance status 'read and change'.

The field sy-dbcnt contains the number of rows that have been changed or inserted in the database.

The command DELETE FROM WHERE enables one row to be deleted from a database table. In the WHERE clause, specify all the key fields with the relational operator '='.

The command has the two return codes 0 (row has been deleted) and 4 (row has not been deleted).

A row can also be deleted from views. However, there are two restrictions here: The view may only contain fields from one table and must be created in the ABAP Dictionary with maintenance status 'read and change'.

The following short forms exist:

Short form 1: DELETE [CLIENT SPECIFIED] FROM ,

Short form 2: DELETE [CLIENT SPECIFIED].

Short form 1 requires that the structure has been filled with the key fields of the row to be deleted before it is called up. The structure must have the row type .

Short form 2 requires that the key fields of the row to be deleted be available in a table work area called . This table work area must be declared in the program with TABLES: .

The second short form is forbidden using ABAP Objects.

The command DELETE FROM WHERE enables several rows to be deleted from a database table. Here, you can specify the rows that are to be deleted with the WHERE clause.

The command has the two return codes 0 (at least one row was deleted) and 4 (no rows were deleted).

The system field sy-dbcnt contains the number of rows that have been updated on the database.

To delete several specific rows from a database using a database operation, use the statement DELETE FROM TABLE . The internal table here contains the key fields for the rows that are to be deleted. The internal table must have the row type .

The command has the two return codes 0 (all rows have been deleted) and 4 (at least one row could not be deleted, the rest have been deleted).

There are two ways of deleting all the rows from a table in the current client:

Either DELETE FROM WHERE IN with a blank internal table

or DELETE FROM WHERE LIKE '%'.

The number of rows deleted from the database is shown in the system field sy-dbcnt.

If you receive a return code other than zero from the database interface in response to an Open SQL statement for changing data in the database, you should make sure that the database is reset to the status it had before the change attempt was made. You can do this by means of a database rollback.
The database rollback undoes any changes made to the current database LUW (see the next unit).

For return codes from DB change statements (Open SQL), the most suitable means of triggering a database rollback is to send a termination dialog message (A message or X message). This triggers a database rollback and terminates the associated program.

All other message types (E,W, I) also involve a dialog but do not trigger a database rollback.

You can also trigger a database rollback using the ABAP statement ROLLBACK WORK (without terminating the program at the same time). You should not use the ROLLBACK WORK statement directly, unless you do not want to reset the program context (unlike a termination dialog message)

SAP LOCK CONCEPT

SAP LOCK CONCEPT:

If several users are competing to access the same resource or resources, you need to find a way of synchronizing the access in order to protect the consistency of your data.

Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.

Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.

It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.

Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.

The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE FROM FOR UPDATE). Other users who want to access the locked record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.

At the end of the database transaction, the database releases all of the locks that it has set during the transaction.

In the R/3 System, this means that each database lock is released when a new screen is displayed, since a change of screen triggers an implicit database commits.

To keep a lock set through a series of screens (from the dialog program to the update program), the R/3 System has a global lock table at the application server level, which you can use to set logical locks for table entries.

One application server contains this lock table and a special enqueue work process, which administers all requests for logical locks in the R/3 System. All logical lock requests of the R/3 System run using this work process.

You can also use logical locks to "lock" table entries that do not yet exist on the database (inserting new lines). You cannot do this with physical database locks.

For further information, see the ABAP Editor Keyword documentation for the term Locking.
Logical locks are generated when an entry is written in the lock table. You use function modules to do this.

You can only set a lock if the relevant table entry is not already locked.

The SAP transaction receives information on the success of a lock request from a return code sent via the EXCEPTION interface of the function module. In other words, the control is returned to the program using the function module. The ABAP program does not need to wait.

The SAP transaction can react appropriately by analyzing the return code.

Another user cannot gain access to work with the same table entries that are already locked.

Depending on the bundling technique in use for database updates), the program must delete the lock entries it generated using a lock module, or have them deleted indirectly (see unit Organizing Database Updates).

If the user terminates the program that generated the lock entries (usually a dialog program), the locks are released automatically (implicitly). You can do this by entering /n in the command field, or with the statements LEAVE PROGRAM, LEAVE TO TRANSACTION, and 'A' or 'X'
Messages.

When you call an ENQUEUE function module, the dialog program tries to generate a lock entry.

The export parameters identify the table entry (or entries) that you want to lock.

The program that generates the locks (usually dialog program) analyzes the return code for lock requests and reacts accordingly.

If the lock could not be set; you should normally output an error message.

At the end of the dialog program, you can use the corresponding DEQUEUE function module to delete the entries from the lock table.

DEQUEUE function modules have no exceptions. If you try to release an entry that is not locked, this has no effect.

If you want to release all of the locks that you have set, at the end of your dialog program, you can use the function module DEQUEUE_ALL.

The lock table contains the lock arguments for each table (for lock arguments, see the following slide).

To display the lock table, use transaction SM12.

The entries in the lock table are standard. Locks are always set using the values of the key fields in a table. These form the lock argument.

You pass the values for the lock argument to the lock modules via their interface (function module IMPORT parameters).

If you fail to set any of these parameters, the system interprets it generically, that is, the lock is set for all table lines that meet the criteria specified in the other parameters. The client parameter is an exception to this rule, where the default client SY-MANDT applies.

Lock entries must be assigned to a lock mode.

There are three different lock modes:

Mode 'E' for write locks: This is set if you want to write data to the database (change, create, or delete).


Mode 'S' for read locks: This is set if you want to ensure that the data, which you are reading from the database in your program, is not changed by other users while the program is running. You do not want to change the data itself in your program.

Mode 'X' for write locks: Like mode 'E', mode 'X' is used for writing data to the database. The technical difference between mode 'X' and mode 'E' is that locks of mode 'X' are not accumulated while a program is being executed. (For further details, see the following pages).

If someone tries to lock the same data record again with a second program (different user), the various lock modes take effect as follows:

Write locks ('E' or 'X') mean that any lock attempts from other users are refused, irrespective of the mode in which the lock is attempted.

If a data record is locked in mode 'S' (shared), further locks in mode 'S' may be set by other users.

Lock attempts in other lock modes ('E' or 'X') are refused.

If you want to try to lock a data record more than once while a program is running (for example using a function module that you call up, which sets locks itself), the lock system reacts in the following way:

Mode 'E' write locks are not refused. Instead, a cumulative counter is incremented. The same applies to read locks (mode 'S').

If a data record is locked in mode 'E', a lock request generates a second lock, which is marked as a read lock.

If a data record is locked in mode 'S' and no further read locks are set by other users, a lock attempt in mode 'E' is possible. This generates a second entry in the lock table (for mode 'E').

If a data record is locked in mode 'X', all further lock requests are refused.

If you want to ensure that you are reading up-to-date data in your program (with the intention of changing and returning this to the database), you should use the following procedure for lock requests and database accesses in your program:

First, lock the data that you want to edit.

Then read the current data from the database.

In the next step, process (change) the data in your program and write this to the database.

In the final step, release the locks that you set at the beginning.

This procedure ensures that your changes run fully with lock protection and that you only read data that has been changed consistently by other programs (provided that these also use the SAP lock concept and follow the procedure described here).

Lock modules are created for lock objects and not tables.

Lock objects are maintained in the dictionary. Customer lock objects must begin with "EY" or "EZ".

A lock object is a logical object composed of a list of tables that are linked by foreign key
Relationships. Lock modules are generated for these objects and enable common lock entries to be set for all tables contained in the lock object. This allows combinations of table entries to be locked.

Example: A lock object that contains the tables SFLIGHT and SBOOK enables a flight with its bookings to be locked.

The list of tables for a lock object consists of a primary table. Further table entries are referred to as secondary tables. Only tables with foreign key relationships to the primary table can be used as secondary tables.

With lock objects, you can assign different names for the parameters that describe the fields of the lock arguments for the lock modules. The names of the table fields (key fields of the tables) are proposed by the system.

You can specify the lock mode (a write lock 'E' or 'X' or a read lock 'S') for each table. These function as default values for the lock modules.

After you have assigned tables and default lock modes, lock objects must be generated.

When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function module.

These have the names ENQUEUE_ and DEQUEUE_ respectively.

If you want to ensure that you are reading current data in your program (with the intention of changing and returning this to the database), you should use the following procedure in your program for lock requests and database accesses:

1. Lock the data that you want to edit.
2. Read the current data from the database.
3. Process (change) the data in your program and write this to the database.
4. Release the locks that you set at the beginning.

This procedure ensures that your changes run fully with lock protection and that you only read data, which has been changed consistently by other programs (with the restriction that these are also using the SAP lock concept and following the procedure described).

If you change the order of the four steps to Read -> Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date. Your program can read data before another user's program writes changes to the database. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. For this reason, you should always follow the recommended procedure.

Requesting a lock from a program is a communication step with lock administration. The
Communication step requires a certain time interval. If your program sets locks for several objects, this interval occurs more than once.

By using so-called local lock containers, you can reduce these communication intervals with lock administration. To do so, collect the required lock requests of your program and send them together to lock administration.

The locks (delayed execution) can be collected when the lock modules are called. For this purpose, qualify the IMPORT parameter_collect with 'X'. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed.

The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration.

When the lock orders of a lock container can be executed, the lock container is deleted.

If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case, none of the registered lock requests is executed. The registered locks remain in the lock container.

You can delete the contents of an existing lock container with the function module
RESET_ENQUEUE.

The specified function modules have release status internally-released.

ORGANIZING DATABASE UPDATES

ORGANIZING DATA BASE UPDATES:

If your transaction executes database updates from the dialog program, you must bundle all of your database updates into a single dialog step (usually the last). This is the only way to ensure that your database changes are processed on the all-or-nothing principle.

With database changes from the dialog program, you must save the data you want to change in the global program data until the database changes are made. This data is written to the database with the status it had for the last dialog step.

With database changes from the dialog, your program must set and release SAP locks itself.
The following order is recommended:

Lock data

Read data

Update data on the database

Release locks

Note that the lock entries must be deleted by a program. To do so, you can either call up the lock modules of the object for releasing DEQUEUE_ or the function module DEQUEUE_ALL. For more detailed information, consult the function module documentation.

Database updates from the dialog can be executed in bundled form by using the special subroutine technique PERFORM ON COMMIT.

The statement PERFORM ON COMMIT registers the subroutine that has been called up. This will not be executed until the next COMMIT WORK statement is reached.

If the database updates are encapsulated in the subroutines, they can be separated from the program logic and relocated to the end of the LUW processing.

Each subroutine registered with PERFORM ON COMMIT is only executed once per LUW. Calls can be made more than once (no errors); the subroutine, however, is only executed once.

From release 4.6 onward nested PERFORM ON COMMIT calls lead to a runtime error.

The COMMIT WORK statement carries out all subroutines registered to be executed and triggers a database commit (ends the DB LUW).

Unlike normal subroutines, those that you call using the ON COMMIT addition do not have an interface. They work instead with global data, that is, the values of the data objects at the point where the subroutine is actually run. This can also include Imports from memory.

The PERFORM ... ON COMMIT technique can also be used in the update. This will be discussed later.


Update techniques allow you to separate user dialogs from the database changes. Both are executed by different programs, which generally run in different work processes.

You work with a program that manages the user dialogs. It is referred to as a dialog program.

You use a so-called update program that updates the data received by the dialog program on the database. No dialogs run in the update programs.

Step 1: The dialog program receives the data changed by the user and writes it to a special log table.

The entries in this table function as requests. The data contained in the log table will be written to the database later by the update program.

A dialog program can write several entries to the log table.

The entries in the log table represent an LUW, in other words they will either be executed on the database together or not at all (all-or-nothing principle).

Step 2: The dialog program completes the logical data packet that was written to the log table. The SAP LUW finishes in the dialog part and informs the Basis system that a packet needs to be updated.

Step 3: A basis program reads the data associated with the LUW from the log table and supplies it to the update program.

Step 4: The update program accepts the data transferred to it and updates the database entries.

Step 5: If the update program runs successfully, a Basis program deletes all entries for the LUW from the log table.

In the event of an error, the entries remain in the log table and are flagged as errored.

The option of informing users by mail that an update action has failed can be set using the profile parameters rdisp/vb_mail_user_list and rdisp/vbmail.

The parameter rdisp/vbmail can be set to '0' (no mail is sent in the event of an error) or '1' (a mail is sent in the event of an error).

The rdisp/vb_mail_user_list parameter setting specifies who will be informed in the event of an error (rdisp/vbmail = 1) ($ACTUSER informs the user who generated the data record to be updated).

The monitor transaction for update orders is SM13.

The dialog program and the update program can be linked in various ways:

Asynchronously

Synchronously

Via a local update

Technical implementation of the update concept requires a so-called update program as well as the program that manages the user dialog. The update program tasks are carried out by special function modules called update modules.

Create an update function module by choosing the processing radio button property 'update module'.

Update modules, like other function modules, have an interface for transferring data. The interface for update function modules only includes IMPORTING and TABLES parameters. These must be typed using reference fields or structures.

Export parameters and exceptions are ignored in update modules.

The function module contains the actual database update statements.

The entries in the log file are generated from the dialog program. They are generated by calling up the associated update function module. The function module must be called using the addition IN UPDATE TASK. This ensures that the module is not executed immediately. Instead, the current data from the function module interface is written to the log table.

For every CALL FUNCTION ... IN UPDATE TASK statement in the dialog program, the system generates an entry in the log table containing the name of the update function module and the associated parameters.

All of the update requests in an SAP LUW are stored under the same update key (VB key). The update key is a unique key.

When the system reaches the next COMMIT WORK statement, a log header is generated for the corresponding log entries, concluding the set of update entries for that SAP LUW. The log header contains information on the dialog program that wrote the log entries, as well as information on the update modules to be executed.

As well as the header entry, the ABAP command COMMIT WORK ensures that the dispatcher process is informed about the availability of a further update packet.

In a dialog consisting of several steps, you can store multiple entries in the update log table that are then processed following the ABAP COMMIT WORK command.

However, you may also need to delete the update requests of the current SAP LUW using a ROLLBACK WORK statement.

In a ROLLBACK WORK statement, the system:

Deletes all form routines registered using PERFORM ON COMMIT
Deletes all database update requests from the log
Triggers a rollback on the database, followed by a database commit
Starts a new SAP LUW

With relation to database changes already completed in the dialog, the ROLLBACK WORK statement means that all changes in the current database LUW are undone.

The ROLLBACK WORK statement deletes all lock entries generated up to now from the dialog program.

The ROLLBACK WORK statement does not affect the program context, in other words all data objects (program-specific objects and objects from function groups that may be used) remain unchanged, and they are NOT reset.

You can generally only reset the data objects of your program by ending the dialog program.

Therefore, you should not use the ROLLBACK WORK statement directly. Instead, trigger an implicit rollback by sending a termination message (type A). This ensures that all of the data from the program is also reset when the program terminates.

The task of an update module is to pass the requests for database updates to the database and to evaluate their return codes.

If the database cannot successfully complete an update; the update function module must be able to react.

If you want to trigger a database rollback in the update task, you can use a termination message. This triggers an implicit database rollback.

The rollback ends the update task. The log entry belonging to the SAP LUW is flagged as containing an error. The termination message is also entered in the log.

The system sends an express mail to the relevant user, telling him or her that the update was unsuccessful. You can examine the log entry by using Transaction SM13.

You may not use the explicit ABAP statements COMMIT WORK or ROLLBACK WORK in an update module.

If your program is to run using locks, you must record the locks in the lock table. These are inherited by the update modules with the ABAP command COMMIT WORK and can then no longer be accessed by the dialog program.

To ensure that the update modules run with the protection of locks, the lock entries must not be released before the COMMIT WORK.

You do not need to release the locks explicitly in the update modules, since they are automatically released at the end of the update process by a basis program.

The locks are also released if one of the update modules triggers a database rollback by sending a termination message.

If the update modules allow failed update requests to be reprocessed (see V1 update), you should note that the data in the database tables at the point of reprocessing may be different from that at the point of the failed update attempt. Reprocessing failed update requests is only useful if the data to be updated is not dependent on the database status (e.g. writing of a document failed because of a table space overflow).

Failed update requests are reprocessed without locks.

In asynchronous update, the dialog program and update program run separately.
The dialog program writes the update requests into the log table VBLOG in the database.
You conclude the dialog part of the SAP LUW with the COMMIT WORK statement. A new SAP LUW immediately starts in the dialog program, which can carry on processing user dialogs without interruption. The dialog program does not wait for the update program to finish.

The update program is run on a special update work process. This need not be on the same Server as the corresponding dialog work process.


The SAP LUW that began in the dialog program is continued and then closed by the update Program.


The log table VBLOG can be implementing as a cluster file in your system, or be replaced with the transparent tables VBHDR, VBMOD, VBDATA, and VBERROR.

Asynchronous updates are useful in transactions where the database updates take a long time and the "perceived performance" by the shorter user dialog response time is important.

Asynchronous update is the standard technique for dialog processing.

The entries that have a HEADER can be analyzed in SM13.
In local update, the update functions are run on the same dialog process used by the dialog program containing the COMMIT WORK statement.

To do this, you must include the SET UPDATE TASK LOCAL statement in the dialog program.

The effect of this is that update requests are kept in main memory rather than being written into table VBLOG in the database.

When the system reaches the COMMIT WORK statement, the corresponding update modules are processed in the dialog work process currently being used by the dialog program. If all of the update modules run successfully, a database commit is triggered. If not, a database rollback occurs.

Once the update function modules have been processed, the dialog program resumes with a new SAP LUW.

The SET UPDATE TASK LOCAL flag can only be set if no other update requests were generated for the same LUW before the program was called up.

The SET UPDATE TASK LOCAL flag is effective until the next COMMIT WORK or ROLLBACK WORK command.

With synchronous updates, the dialog program waits for the end of the update modules. The dialog program does not begin to process the new SAP LUW until the update modules have terminated.

To switch from asynchronous to synchronous update, use the AND WAIT addition in the COMMIT WORK statement.

The entries that have a HEADER can be analyzed in SM13.

Asynchronous update is useful in transactions where subsequent user dialogs do not depend on the database updates being made immediately. Once the update task has been called, control returns directly to the user.

Local update is particularly useful for processing dialog transactions in the background. There is no contact with the database table VBLOG, and if the program is running alone on the server, local update is faster than either synchronous or asynchronous update. If, as is the usual case, several users are using the server, the speed of the program depends on the total server load.

Synchronous update is useful in transactions where you want to use the advantages of update techniques (logging, opportunity to reprocess failed update requests), but where subsequent user dialogs nevertheless do depend on the results of the update. One particular application for this technique is in "transactions within transactions" - where one transaction uses other transactions as modularization units (CALL TRANSACTION ).

When you use this method, you can determine in the call the update technique that you want the transaction to use. For further information, see the keyword documentation in the ABAP Editor for the term CALL TRANSACTION.

Update function modules can be separated into two groups. The group determines when the function module is processed: Function modules that are classified as V1 can be further divided into two subclasses: Start immediately or Start immediately, no restart. V2 function modules are processed asynchronously after all V1 update modules have finished running.

If you have used the Start immediately (V1) option, you can update any records that contained errors manually, using Transaction SM13. If you use the Start immediately, no restart (V1) option, this is not possible. V2 update function modules (Start delayed) can always be manually updated.

V1 update function modules do not normally run using the SAP lock concept. In other words, the V1 update program is executed with the protection of the locks from the dialog program.

Any lock entries are released at the end of the V1 update. V2 update function modules always run without logical locks.

You can also classify an update module using attribute 'Coll. run' (collective run). This option is used SAP internal only (special form of V2 update, asynchronously, start via program RSM13005).



The locks generated in the dialog program are usually inherited by the V1 update modules when the update takes place. This is controlled by the SCOPE interface parameter of the lock modules. When SCOPE = 2, the V1 update programs inherit the locks that are set in the dialog program.

2 is the default setting for SCOPE when you call a lock module.

You do not need to release the locks explicitly in your program, since they are automatically released at the end of the V1 update process.

The locks are also released if one of the V1 update modules triggers a database rollback by sending a termination message.

An SAP LUW maps updates, which are logically related and usually involve several dialog steps, to a database LUW. The database updates are encapsulated via update modules.

SAP LUWs are supported specifically by R/3:

Locks (Scope = 2)

The CALL FUNCTION IN UPDATE TASK call mechanism

The command COMMIT WORK

Type 'A' or 'X' dialog messages.

An SAP LUW can be divided into three phases (three-phase model).

Dialogs, user entries, and their input checks take place in phase 1. Calls of update modules are not allowed here, since they might be registered more than once during an error dialog (E message).

Phase 1 ends when the first update module is called. The data to be updated must be held in global program data during phase 1.

Preparations for database updates take place in phase 2. Phase 2 begins when the first update module is called and ends with the COMMIT WORK statement. The system must now respond to any errors with a type 'A' or 'X' dialog message. The COMMIT WORK that concludes phase 2 should only be set at the top level if call hierarchies are used, since the lower-level modularization units in the hierarchy are not aware of the status of the program context.

The database updates are performed in phase 3. The system must always respond to any errors in phase 3 with a type 'A' or 'X' dialog message. This leads to a ROLLBACK of the complete database LUW as well as a termination of the update.

Local update processing is activated using the ABAP command SET UPDATE TASK LOCAL. The update type can only be changed if it is processed before the first update module is called.

With local updates, the update modules are executed in the dialog work process that is currently performing the SAP LUW.

As is the case with synchronous updates; the user must wait while the update modules are being executed.

Local updates should be used for:
Transactions that are carried out in the background (batch) (CALL TRANSACTION USING)
Exception: If UN buffered number assignments and higher parallel processing is requested at the same time.
- Dialog transactions with very few database changes (3 - 5 statements) for which the dialog behavior is not critical.


Note that the fewer the number of users making changes simultaneously, the better the response time of the database.

Synchronous updates are triggered by the ABAP statement COMMIT WORK AND WAIT. With a synchronous update, the update modules are executed in an update work process.

Unlike asynchronous updates, the dialog part of the transaction is stopped while the update modules are being executed.

The success or failure of the update is displayed in system field sy-subrc once the update has been completed.

For every action on the database that prompts table updates, the record to be changed is locked physically by the database. The same applies if you are reading with SELECT ... FOR UPDATE.

Other users cannot change the same data for the duration of the lock.

To reduce the lock duration on the database, you should use the following rule to program the database updates carried out by the update modules:

First, new table entries should be created. These present the smallest 'problem' for the other users.

You should then perform table updates that are not critical to performance. As a rule, these are the tables that are accessed 'simultaneously' by as few users as possible.

Tables that are central resources in the system (which many users access at once) should always be changed as late as possible.

To lock the central tables (performance critical) for as short a time as possible, you can use PERFORM uprog ON COMMIT in the update.

For this purpose, encapsulate the changes to the central tables in FORM routines and call these up in the update using PERFORM ON COMMIT. The FORM routines are then not executed until the last update module has been processed.

After the last update module has been processed; a program executes the ABAP command COMMIT WORK, which then performs the FORM routines registered in the update

ENHANCEMENTS TO DICTIONERY ELEMENTS IN SAP

ENHANCEMENTS TO DICTIONARY ELEMENTS:


Tables and structures can be expanded in one of two different ways:

Append structures allow you to enhance tables by adding fields to them that are not part of the standard. With append structures; customers can add their own fields to any table or structure they want.

Append structures are created for use with a specific table. However, a table can have multiple append structures assigned to it.

If it is known in advance that one of the tables or structures delivered by SAP needs to have customer-specific fields added to it, the SAP application developer includes these fields in the table using a Customizing include statement.

The same Customizing include can be used in multiple tables or structures. This ensures consistency in these tables and structures whenever the include is extended.

Nonexistent Customizing includes do not lead to errors.

Append structures allow you to attach fields to a table without actually having to modify the table itself.

Append structures may only be assigned to a single table. A table may, however, have several append structures attached to it. Whenever a table is activated, the system searches for all active append structures for that table and attach them to the table. If an append structure is created or changed and then activated, the table it is assigned to is also activated, and all of the changes made to the append structure take effect in the table as well.

You can use the fields in append structures in ABAP programs just as you would any other field in the table.

Note: If you copy a table that has an append structure attached to it, the fields in the append structure become normal fields in the target table.

You create append structures in the customer namespace. This protects them from being overwritten at upgrade or during release upgrade. New versions of standard tables are loaded during upgrades.

The fields contained in active append structures are then appended to the new standard tables when these new standard tables are activated for the first time.

From Release 3.0, the field sequence in the ABAP Dictionary can differ from the field sequence in the database. Therefore, no conversion of the database table is necessary when adding an append structure or inserting fields into an existing one. All necessary structure adjustment is taken care of automatically when you adjust the database catalog (ALTER TABLE). The table's definition is changed when it is activated in the ABAP Dictionary and the new field is appended to the database table.

Pay attention to the following points when using append structures:
You cannot create append structures for pool and cluster tables.
If a table contains a long field (either of data type LCHR or LRAW), then it is not possible to expand the table with an append structure. This is because long fields of this kind must always be the last field in their respective tables. No fields from an append structure may be added after them.

If you use an append structure to expand an SAP table, the field names in your append structure must be in the customer namespace, that is, they must begin with either YY or ZZ. This prevents naming conflicts from occurring with any new fields that SAP may insert in the future.

Some of the tables and structures delivered with the R/3 standard contain special include statements:

Customizing includes. These are often inserted in those standard tables that need to have customer specific fields added to them.

In contrast to append structures, Customizing includes can be inserted into more than one table. This provides for data consistency throughout the tables and structures affected whenever the include is altered.

Customizing include programs is part of the customer namespace: all of their names begin with 'CI_'. This naming convention guarantees that nonexistent Customizing includes do not lead to errors. No code for Customizing includes is delivered with the R/3 standard.

You create Customizing includes using special Customizing transactions. Some are already part of SAP enhancements and can be created by using project management (see the unit on 'Enhancements using Customer Exits').

The Customizing include field names must lie in the customer namespace just like field names in append structures. These names must all begin with either 'YY' or 'ZZ'.

When adding the fields of a Customizing include to your database, adhere to same rules you would with append structures.

Every time they define a data element, the SAP application programmers define keywords in different lengths and a short description for each data element.

You create field exits in Project management. Field exits are processed when the user leaves a screen that contains a field which refers to a data element containing a field exit.

SAP lets you create a field exit for every input-ready screen field that has been created with reference to the ABAP Dictionary. The additional program logic is stored in a function module and is executed at a specific point in the PAI logic.

The slide shows the order in which processing takes place. Before the PAI logic of the screen is executed, the system performs the following checks: First the system checks if all the required fields have been filled in. If a required field is empty, the screen is shown again.

The system then checks that data has been entered in the correct format.

Any defined field exits are executed next. For example, by sending an error message you can have the screen sent again.

Once all the field exits have been checked, the screen is processed as normal.

Field transport
Foreign key check
Processing the PAI module

Field exits take you from a screen field with a data element reference to a function module. Field exits can be either global or local:

Global field exits are not limited to a particular screen: If a global exit's data element is used on several screens, the system goes to the function module for all these screens after activating the field exit. Here you can, for example, edit the contents, force a new entry to be made by outputting an error message, or prohibit certain users from proceeding further.

Local field exits are valid for one screen only. If you assign a screen from a specific program to a field exit, then the system will go to the appropriate function module from this screen once the exit has been activated.

You can either create a global field exit or up to 36 local field exits for a data element, but not both.

Each exit number refers to a different function module. Field exit function modules adhere to the following naming convention:

Prefix: FIELD_EXIT_
Name:
Suffix (for local field exit): _0 to _9, _A to _Z

To create field exits; choose Utilities in the ABAP Workbench. Choose Enhancements and then Project management to edit field exits and to implement customer exits. Do not create field exits directly from the Function Builder.

Choose Goto -> Global enhancements -> Field exits to start the transaction for maintaining field exits. To create a new enhancement, use the menu path Text Enhancements -> Create.

Enter the name of the data element to which your screen field refers in the modal dialog box. The Function Builder is started with a special naming convention and interface options. The system specifies the name of the field exit. Do not change this name. Create the function module in a customer function group.

The function module must be assigned to an existing customer function group.
The function module interface is fixed and cannot be changed. The function module has an import parameter INPUT and export parameter OUTPUT. The contents of the screen field are stored in parameter INPUT. The contents of OUTPUT are returned in the screen field when you leave the function module.

Field exits are not transported automatically. Therefore, you must assign the value of INPUT to OUTPUT in your source code. Otherwise the screen field would be blank after executing the field exit.

The following ABAP statements are not allowed in field exit function modules:
CALL SCREEN, CALL DIALOG, CALL TRANSACTION, SUBMIT
COMMIT WORK, ROLLBACK WORK
COMMUNICATION RECEIVE
EXIT FROM STEP-LOOP
MESSAGE I, MESSAGE W
STOP, REJECT

When you debug a screen that is referenced by a field exit, the field exit code is ignored by the debugger. As with any normal function module, you can, however, debug the field exit code in the Function Builder's test environment.

You can create local field exits that relate to a specific screen. A global field exit must already exist.

Edit the local field exit based on the global field exit.

You can create up to 36 local field exits, each of which carries a unique suffix. The system proposes a name for the function module; you should use this name.

Defining local field exits means that the function module of the global field exits initially created is no longer used. However, you must not delete it, for technical reasons. The field exits in the system would be deleted if you deleted the global function module of the field exit from the list.

You must activate the field exit as well as the function module. Also note that field exits are only taken into account during screen execution if the R/3 profile parameter abap/field exit = YES has been set for all application servers. (This profile parameter is set to 'NO' by default).

If you declare field exits for multiple screen fields, you have no control over the order in which they are processed. In particular, you cannot access the contents of other screen fields in a field exit.

LESSON 5 DATA BASE DIALOG

Database tables are administered in the ABAP Dictionary. There you can find current information about a database table's technical attributes. Database tables that have been created in the database using the same line type and name are called transparent tables in the ABAP Dictionary.

There are a couple of different ways in which you can navigate to transparent tables in the ABAP Dictionary:

Choose Tools->ABAP Workbench->Development->Dictionary to call the ABAP Dictionary directly and insert the name of the transparent table in the appropriate input field, or

Navigate directly to the ABAP Dictionary from the ABAP Editor while editing the program: This can be done by double -clicking on the name of the transparent table in the FROM clause of the SELECT statement.

You can search for database tables in several different ways:

Application hierarchy and the Repository Information System: You may choose application components from the application hierarchy and branch directly to the information system. There you can search for database tables according to their short texts (among other criteria).

If you have the name of a program that accesses the database table:

Input field on a screen: If you know of a program that contains a screen with input fields connected to the table you are looking for, choose F1->Technical info. and then navigate to to the ABAP Dictionary by double -clicking on the technical name of the screen field. This is often a field in a structure. Double -click on the data element and then use the where-used list function to search for transparent tables according to the field type.

Debugger: If you know the name of a program that accesses the database table that you are looking for, you can start this program in debugging mode and set a breakpoint at the SELECT statement.

Editor: Look for the SELECT statement

Object List in the Object Navigator: Pick out the subroutines that encapsulate the database accesses.

If you know of a structure field in the ABAP Dictionary.

Double-click on the data element and then use the where -used list function to search for transparent tables according to the field type.

As soon as you navigate to the definition of a database table in the ABAP Dictionary, information about all of the table's technical attributes is available.

The following information is of interest for enhancing the performance of database accesses:

Key Fields: If the lines requested from the database are being retrieved according to key fields, the Database Optimizer can perform access using a primary index. Checkboxes are on for all key fields.

Secondary Indexes: You may also use secondary indexes to select specific lines. These are displayed in a dialog box whenever you choose the 'Indexes' pushbutton. You can choose an index from the dialog box by simply double -clicking on it. The system then displays a screen with additional information about that index.

You use the Open SQL statement SELECT to read data from the database.

Underlying the SELECT statement is a complex logic that allows you to access many different types of database table.

The statement contains a series of clauses, each of which has a different task:

The SELECT clause specifies

Whether the result of the selection is to be a single line or several lines.

The fields that should be included in the result.

Whether the result may contain two or more identical lines.

The INTO clause specifies the internal data object in the program into which you want to place the selected data.

The FROM clause specifies the source of the data (database table or view).

The WHERE clause specifies conditions that selection results must fulfill. Thus, it actually
determines what lines are included in the results table.

For information about other clauses, refer to the keyword documentation in the ABAP Editor
for the SELECT statement.

Open SQL statements are a subset of Standard SQL that is fully integrated in the ABAP language.

They allow you to access the database in a uniform way from your programs, regardless of the database system being used. Open SQL statements are converted into database-specific SQL statements by the database interface .

The SELECT SINGLE* statement allows you to read a single line from a database table. To ensure that you read a unique entry, all of the key fields must be filled by the WHERE clause.

The informs the database interface that all columns in that line of the database table should be read.

If only a specific cross-section of columns is desired, a structure can be inserted instead.

The name of a structure to which you want the database interface to copy a data record is inserted after the INTO clause.

The structure should have a structure identical to the columns of the database table being read and be left-justified.

If you use the CORRESPONDING FIELDS OF addition in the INTO clause, you can fill the target work area component by component.

The system only fills those components that have identical names to columns in the database table. If you do not use this addition, the system fills the work area from the left-hand end without any regard for its structure.

If the system finds a table entry matching your conditions, SY-SUBRC has the value 0.


The SINGLE addition tells the database that only one line needs to be read. The database can then terminate the search as soon as it has found that line. Therefore, SELECT SINGLE produces better performance for single -record access than a SELECT loop if you supply values for all key fields.

If you do not use the addition SINGLE with the SELECT statement, the system reads multiple records from the database. The field list determines the columns whose data is to be read from the database.

The number of lines to be read can be restricted using the WHERE clause. The restrictions contained in the WHERE clause should either be made according to the database table's key fields or according to a secondary index. Further information about key fields and secondary indexes can be found in the ABAP Dictionary. For example, double -clicking on the database table included in the FROM clause will take you directly to the Dictionary.

You may only enter the names of the database table fields you want to be read in the WHERE clause.

Multiple logical conditions can be added to the WHERE clause using AND or OR.

The database delivers data to the database interface in packages. The ABAP runtime system copies the data records to the target area line by line using a loop.
It also provides for the sequential processing of all of the statements between SELECT and ENDSELECT.

SY-SUBRC = 0 if the system was able to select at least one entry. After the SELECT statement is executed in each loop pass, the system field SY-DBCNT contains the number of lines read. After the ENDSELECT statement, it contains the total number of lines read.

The addition INTO TABLE causes the ABAP runtime system to copy the contents of the database interface directly to the internal table itab. This is called an array fetch.

Since an array fetch is not logically a loop, no ENDSELECT statement is used.

SY-SUBRC = 0 if the system was able to read at least one table entry.

For further information about array fetch and internal tables, refer to the Internal Tables unit of this course.

The program must contain a data object with a suitable type for each column that is required from a database table. For reasons of program maintenance, you must use the corresponding Dictionary objects to assign types to the data objects. The INTO clause specifies the data object into which you want to place the data from the database table. There are two different ways to do this:

Flat structure: You define a structure in your program that has the fields in the same sequence as the field list in the SELECT clause. Then you enter the structure name in the INTO clause. The contents are copied by position. The structure field names are disregarded.

Single data objects: You enter a set of data objects in the INTO clause.

If you use the INTO CORRESPONDING FIELDS clause, the data is placed in the structure fields that have the same name.

Advantages of this construction:

The structure does not have to be structured in the same way as the field list and does not need to be left-justified


This construction is easy to maintain, since extending the field list does not require other changes to be made to the program, as long as there is a field in the structure that has the same name and type.

Disadvantages of this construction:

INTO CORRESPONDING FIELDS is more runtime-intensive than INTO. The runtime may therefore be longer.

If you want to place data into internal table columns of the same name using an array fetch, use INTO CORRESPONDING FIELDS OF TABLE .

The SAP authorization concept recognizes a large number of different authorizations. These are all managed centrally in the user master record for every user.

Authorizations are not directly assigned to users, but stored in work center descriptions (profiles).

These profiles are generated using the Profile Generator, which administers the profiles as activity groups.

Users can belong to one or more activity groups and are then assigned the authorizations contained in those activity groups.

Release 4.6 contains a large number of pre-defined activity groups. You can use these as is or copy and tailor them to your specific needs.

You should carry out an authorization check before accessing the database. The AUTHORITYCHECK statement first checks whether the user has the authorization containing all the required values. You then check the code value in the system field SY-SUBRC. If this value is 0, the user has the required authorization and the program can continue. If the value is not 0, the user does not possess the required authorization and you should display a message and take the appropriate action.

All data in the SAP system must be protected from unauthorized access by users who do not explicitly have permission to access it.

The system administrator assigns user authorization when maintaining user master data. During this process, you should determine exactly which data users are allowed to access and what kind of access should be allowed.

This is carried out by an authorization object composed of the fields 'Activity' and 'Airline carrier' that has to be addressed both during the authorization assignment process and whenever your program performs an authorization check.

Authorization objects simply define the combination of fields that need to be addressed
simultaneously and serve as templates for both authorizations and authorization checks.

They are organized into object classes in order to make it easier to find and administer them; one object class or several may exist in each application. You call the authorization object maintenance transaction from the 'Development' menu in the ABAP Workbench.

A complete list of all development objects, sorted according to class and including their corresponding fields and documentation, is part of this transaction.

When making authorization checks in programs, you specify the object and values the user needs in an authorization to be able to access the object. You do not have to specify the name of the authorization.

Important: The Authority-Check statement performs the authority check and returns an appropriate return code value in SY-SUBRC. When checking this return code, you can specify the consequences of a missing authorization (for example: terminate the program or display a message and skip some lines of code).


You must specify all fields of the object in an AUTHORITY-CHECK, otherwise you receive a return code not equal to zero. If you do not want to carry out a check for a particular field, enter DUMMY after the field name.

The most important return codes for AUTHORITY-CHECK are:


0: The user has an authorization containing the required values.
4: The user does not have the required authorization.
8: The check could not successfully be carried out since not all fields of the object were
specified.

The keyword documentation for AUTHORITY-CHECK contains a complete list of return codes.

You can only specify a single field after the FIELD addition, not a selection table. There are function modules which carry out the AUTHORITY-CHECK for all values in the selection table.
If reusable components that encapsulate complex data retrieval are available , then you must use them. There are four techniques available for doing this.


Methods of global classes
Methods of business objects
Function modules
Logical databases are data retrieval programs delivered by SAP that return data in a hierarchically logical sequence.

You can find information on the various techniques in the Reuse Components unit.
Views are application-specific views of different ABAP Dictionary tables. Views can contain a selection of fields from a single very large table or fields from several different tables.


Views allow you to gather information from the fields of different tables and present it to users in the form they require when working with the R/3 System.

Views are mainly used for programming with ABAP and for F4 online help.


If there are no components available that are suitable for your purposes, you can carry out complex database access using ABAP-OPEN- SQL statements. To do this you have to compare the merits of various techniques, as using an unsuitable technique can result in considerable performance problems.

LESSON 12 ABAP DICTIONARY

ABAP DICTIONARY:


The ABAP Dictionary permits a central management of all the data definitions used in the R/3 System.

In the ABAP Dictionary you can create user-defined types (data elements, structures and table types) for use in ABAP programs or in interfaces of function modules. Database objects such as tables and database views can also be defined in the ABAP Dictionary and created with this definition in the database.

The ABAP Dictionary also provides a number of services that support program development. For example, setting and releasing locks, defining an input help (F4 help) and attaching a field help (F1 help) to a screen field are supported.

Tables and database views can be defined in the ABAP Dictionary.

These objects are created in the underlying database with this definition. Changes in the definition of a table or database view a re also automatically made in the database.

Indexes can be defined in the ABAP Dictionary to speed up access to data in a table. These indexes are also created in the database.

There are three different type categories in the ABAP Dictionary:

Data elements: Describe an elementary type by defining the data type, length and possibly decimal places.

Structures: Consist of components that can have any type.

Table types: Describe the structure of an internal table.

Any complex user-defined type can be built from these basic types.

Example: The data of an employee is stored in a structure EMPLOYEE with the components NAME, ADDRESS and TELEPHONE. Component NAME is also a structure with components FIRST NAME and LAST NAME. Both of these components are elementary, i.e. their type is defined by a data element. The type of component ADDRESS is also defined by a structure whose components are also structures. Component TELEPHONE is defined by a table type (since an employee can have more than one telephone number).

Types are used for example in ABAP programs or to define the types of interface parameters of function modules.

The ABAP Dictionary supports program development with a number of services:

Input helps (F4 helps) for screen fields can be defined with search helps.

Screen fields can easily be assigned a field help (F1 help) by creating documentation for the data element.

An input check that ensures that the values entered are consistent can easily be defined for screen fields using foreign keys.

The ABAP Dictionary provides support when you set and release locks. To do so, you must create lock objects in the ABAP Dictionary. Function modules for setting and releasing locks are automatically generated from these lock objects; these can then be linked into the application program.

The performance when accessing this data can be improved for database objects (tables, views) with buffering settings.

By logging, you can switch on the automatic recording of changes to the table entries.

The ABAP Dictionary is actively integrated in the development and runtime environments. Each change takes immediate effect in the relevant ABAP programs and screens.
Examples:

When a program or screen is generated, the ABAP interpreter and the screen interpreter access the type definitions stored in the ABAP Dictionary.

The ABAP tools and the Screen Painter use the information stored in the ABAP Dictionary to support you during program development. An example of this is the Get from Dictionary function in the Screen Painter, with which you can place fields of a table or structure defined in the ABAP Dictionary in a screen.

The database interface uses the information about tables or database views stored in the ABAP Dictionary to access the data of these objects.

The structure of the objects of application development are mapped in tables on the underlying relational database.

The attributes of these objects correspond to fields of the table.

A table consists of columns (fields) and rows (entries). It has a name and different attributes, such as delivery class and maintenance authorization.

A field has a unique name and attributes; for example it can be a key field.

A table has one or more key fields, called the primary key.

The values of these key fields uniquely identify a table entry.

You must specify a reference table for fields containing a currency (data type CURR) or quantity (data type QUAN). It must contain a field (reference field ) with the format for currency keys (data type CUKY) or the format for units (data type UNIT). The field is only assigned to the reference field at program runtime.

The basic objects for defining data in the ABAP Dictionary are tables, data elements and domains. The domain is used for the technical definition of a table field (for example field type and length) and the data element is used for the semantic definition (for example short description).

A domain describes the value range of a field. It is defined by its data type and length. The value range can be limited by specifying fixed values.

A data element describes the meaning of a domain in a certain business context. It contains primarily the field help (F1 documentation) and the field labels in the screen.

A field is not an independent object. It is table -dependent and can only be maintained within a table.

You can enter the data type and number of places directly for a field. No data element is required in this case. Instead the data type and number of places is defined by specifying a direct type .

The data type attributes of a data element can also be defined by specifying a built-in type , where the data type and number of places is entered directly.


A transparent table is automatically created on the database when it is activated in the ABAP Dictionary. At this time the database-independent description of the table in the ABAP Dictionary is translated into the language of the database system used.

The database table has the same name as the table in the ABAP Dictionary. The fields also have the same name in both the database and 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. This permits you to insert new fields without having to convert the table. When a new field is added, the adjustment is made by changing the database catalog (ALTER TABLE). The new field is added to the database table, whatever the position of the new field in the ABAP Dictionary.


ABAP programs can access a transparent table in two ways. One way is to access the data contained in the table with OPEN SQL (or EXEC SQL). With the other method, the table defines a structured type that is accessed when variables (or more complex types) are defined.

You can also create a structured type in the ABAP Dictionary for which there is no corresponding object in the database. Such types are called structures. Structures can also be used to define the types of variables.

Structures can be included in tables or other structures to avoid redundant structure definitions.

A table may only be included as an entire table.

A chain of includes may only contain one database table. The table in which you are including belongs to the include chain. This means that you may not include a transparent table in a transparent table.

Includes may contain further includes.

Foreign key definitions are generally imparted from the include to the including table. The attributes of the foreign key definition are passed from the include to the including table so that the foreign key depends on the definition in the include.

You must maintain the technical settings when you define a transparent table in the ABAP Dictionary.

The technical settings are used to individually optimize the storage requirements and accessing behavior of database tables.

The technical settings can be used to define how the table should be handled when it is created on the database, whether the table should be buffered and whether changes to entries should be logged.

The table is automatically created on the database when it is activated in the ABAP Dictionary. The storage area to be selected (tablespace) and space allocation settings are determined from the settings for the data class and size category.

The settings for buffering define whether and how the table should be buffered.

You can define whether changes to the table entries should be logged.

The data class logically defines the physical area of the database (for ORACLE the tablespace) in which your table should be stored. If you choose the data class correctly, the table will automatically be created in the appropriate area on the database when it is activated in the ABAP Dictionary.

The most important data classes are master data, transaction data, organizational data and system data.

Master data is data that is rarely modified. An example of master data is the data of an address file, for example the name, address and telephone number.

Transaction data is data that is frequently modified. An example is the material stock of a warehouse, which can change after each purchase order.

Organizational data is data that is defined during customizing when the system is installed and that is rarely modified thereafter. The country keys are an example.

System data is data that the R/3 System itself needs. The program sources are an example.

Further data classes, called customer data classes (USR, USR1), are provided for customers. These should be used for customer developments. Special storage areas must be allocated in the database.

The size category describes the expected storage requirements for the table on the database.

An initial extent is reserved when a table is created on the database. The size of the initial extent is identical for all size categories. If the table needs more space for data at a later time, extents are added. These additional extents have a fixed size that is determined by the size category specified in the ABAP Dictionary.

You can choose a size category from 0 to 4. A fixed extent size, which depends on the database system used, is assigned to each category.

Correctly assigning a size category therefore ensures that you do not create a large number of small extents. It also prevents storage space from being wasted when creating extents that are too large.

Modifications to the entries of a table can be recorded and stored using logging.

To activate logging, the corresponding field must be selected in the technical settings. Logging, however, only will take place if the R/3 System was started with a profile containing parameter 'rec/client'. Only selecting the flag in the ABAP Dictionary is not sufficient to trigger logging.


Parameter 'rec/client' can have the following settings:
rec/client = ALL All clients should be logged.
rec/client = 000[...] Only the specified clients should be logged.
rec/client = OFF Logging is not enabled on this system.

The data modifications are logged independently of the update. The logs can be displayed with the Transaction Table History (SCU3).

Logging creates a 'bottleneck' in the system:

Additional write access for each modification to tables being logged.

This can result in lock situations although the users are accessing different application tables!

LESSON 13 PERFORMANCE DURING TABLE ACCESS

PERFORMANCE DURING TABLE ACCESS:


Advantages and disadvantages of the method of buffer synchronization:
Ÿ
Advantage:

The load on the network is kept to a minimum. If the buffers were to be synchronized immediately after each modification, each server would have to inform all other servers about each modification to a buffered table via the network. This would have a negative effect on the performance.


ŸDisadvantage :

The local buffers of the application servers can contain obsolete data between the
moments of synchronization.

This means that:
Ÿ
Only those tables which are written very infrequently (read mostly) or for which such temporary inconsistencies are of no importance may be buffered.


Ÿ Tables whose entries change frequently should not be buffered. Otherwise there would be a constant invalidation and reload, which would have a negative effect on the performance.

LESSON 15 DEPENDENCIES OF DICTIONARY OBJECTS

DEPENDENCIES OF DICTIONARY OBJECTS"

During development, you sometimes need to change an (active) object already used by the system.

Such changes are supported in the ABAP Dictionary by separating the active and inactive versions.

The active version of an ABAP Dictionary object is the version that the components of the runtime environment (for example ABAP processor, database interface) access. This version is not initially changed.

An inactive version is created when an active object is changed. The inactive version can be saved without checking. It has no effect on the runtime system.

At the end of the development process, the inactive version can be made the active version. This is done by activation. The inactive version of the object is first checked for consistency. If it is consistent, the inactive version replaces the active one. From now on, the runtime system uses the new active version.

The above example shows how the object status changes. An active structure contains three fields. A field is added to this structure in the ABAP Dictionary. After this action, there is an active version with three fields and an inactive version with four fields. During activation, the active version is overwritten with the inactive version. The inactive version thus becomes the active version. After this action there is only the active version with four fields.

The information about a structure (or table) is distributed in the ABAP Dictionary in domains, data elements, and the structure definition. The runtime object (nametab) combines this information into a structure in a form that is optimized for access from ABAP programs. The runtime object is created when the structure is activated.

The runtime objects of the structures are buffered so that the ABAP runtime system can quickly access this information.

The runtime object contains information about the overall structure (e.g. number of fields) and the individual structure fields (field name, position of the field in the structure, data type, length, number of decimal places, reference field, reference table, check table, conversion routine, etc.).

The runtime object of a table contains further information needed by the database interface for accessing the table data (client dependence, buffering, key fields, etc.).

Runtime objects are created for all ABAP Dictionary objects that can be used as types in ABAP programs. These are data elements, table types and views, as well as structures and tables.

If an object that is already active is modified, this can affect other objects that use it (directly or indirectly). These objects using another object are called dependent objects. On the one hand, it might be necessary to adjust the runtime objects of these dependent objects to the changes. On the other hand, a change might sometimes make a dependent object inconsistent.

For this reason, the dependent objects are determined and activated (if necessary) when an active object is activated. The active versions of the dependent objects are activated again. In particular, new and inactive versions of objects using the changed object are not changed.

Example: When you change a domain, for example its data type, all the data ele ments, structures and tables referring to this domain must be activated again. This activation is automatically triggered when the domain is activated. This ensures that all affected runtime objects are adjusted to the changed type information.

If an ABAP Dictionary object has a table as dependent object, its database object as well as its runtime object might have to be adjusted when the dependent object is activated. The method used here will be discussed in the next unit.

Changing an ABAP Dictionary object might also affect its dependent objects. Before making a critical change (such as changing the data type or deleting a field) you should therefore define the set of objects affected in order to estimate the implications of the planned action.

There is a where -used list for each ABAP Dictionary object with which you can find all the objects that refer to this object. You can call the where-used list from the maintenance transaction of the object.

You can find direct and indirect usages of an ABAP Dictionary object with the where-used list. You also have to define which usage object types should be included in the search (e.g. all structures and tables using a data element). You can also search for usages that are not ABAP Dictionary objects (e.g. all programs using a table). The search can also be limited by development class or user namespace.

If an object is probably used by several objects, you should perform the search in the background.

The Repository Information System ABAP Dictionary is part of the general Repository Information System. It helps you search for ABAP Dictionary objects and their users.

The where-used list for Repository objects can be called from the information system. The information system also enables you to search for objects by their attributes.
In addition to the object-specific search criteria (e.g. buffering type for tables), you can search for all objects by development class, short description or author and date of last change.

The object lists created by the Repository Information System are entirely integrated in the ABAP Workbench. They permit you to navigate directly to the maintenance transactions of the objects found.