IN SAP ABAP TABLE TYPES

TABLE TYPES

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.

SAP ABAP TYPES OF VIEWS

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.

SAP 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 ABAP 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 locked 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.