LUW

[Former Member]

hello SAP Gurus,

can any one tell me what is LUW,SAP LUW and Database LUW ?

Thank you very much.

[Former Member]

Hi,

Please check this link

http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/content.htm

LUW is a logical unit of work and is the span of time during which any transaction is updated in all or nothing manner i.e they've been updated completely ro commited or thrown away(Roll Back). An Luw is nothing but a database LUW in database is updated from one screen to another

screen within a transaction which does not last longer and in SAP LUW, the system perfoms database from one transaction to another and this last longer and is usually terminated by the programmer by issuing Commit work statement.

This is a set of updates terminated by an ABAP/4 commit. A SAP LUW may last much longer than a database LUW, since most update processing extends over multiple transaction screens.The programmer terminates an update transaction by issuing a COMMIT WORK statement.

reward if helpful

raam

[former_member156446]

luw :

http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/content.htm

BD luw:

http://help.sap.com/saphelp_nw70/helpdata/en/41/7af4bca79e11d1950f0000e82de14a/content.htm

[Former Member]

Hi Vijaya!!

SAP LUW as well as Database LUW is very cleary explained in the folling link

http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4b9a79e11d1950f0000e82de14a/frameset.htm

Try this if ur doubt is still nt clear ,let ne knw.

In short

Database LUW ::

A database LUW is the mechanism used by the database to ensure that its data is always consistent

SAP LUW::

An SAP LUW is a logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW.

kindly reward if useful.

[Former Member]

hi,,

follow the links

Check these links on LUW's

http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/content.htm

http://help.sap.com/saphelp_47x200/helpdata/en/41/7af4c2a79e11d1950f0000e82de14a/frameset.htm

http://help.sap.com/saphelp_47x200/helpdata/en/41/7af4b9a79e11d1950f0000e82de14a/frameset.htm

An SAP LUW is a logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW.

There are various bundling techniques that you can use to ensure that all of the database updates belonging to an SAP LUW are made in the same single database LUW.

Let one user is modifying a record and the second user is trying to delete the same record at the same time. If the second user is successful in deleting the record, then the first user will face problem in modifying the record. To avoid such problems, SAP has introduced LUW (Logical unit of Work)

LUW is defined as Locking Mechanism to protect transaction integrity.

Types of LUWs:

Database transaction or LUW.

Update transaction or SAPLUW.

ABAP/4 Transaction.

database transaction

Database transaction or LUW is defined as a period in which operation requested must be performed as one unit.

At the end of LUW, either the database changes are committed or rolled back.

SAP LUW

One SAP LUW can have several databases LUW. So a set of database transactions either committed or rolled back.

The special ABAP/4 command ‘Commit work’ marks the end of SAP LUW.

ABAP/4 Transaction

It is made up of a set of related task combined under one transaction code.

ABAP/4 transaction functions like one complete object containing screens, menus and transaction code.

The Open SQL statements INSERT, UPDATE, MODIFY, and DELETE allow you to program database changes that extend over several dialog steps. Even if you have not explicitly programmed a database commit, the implicit database commit that occurs after a screen has been processed concludes the database LUW. The following diagram shows the individual database LUWs in a typical screen sequence:

Under this procedure, you cannot roll back the database changes from previous dialog steps. It is therefore only suitable for programs in which there is no logical relationship between the individual dialog steps.

However, the database changes in individual dialog steps normally depend on those in other dialog steps, and must therefore all be executed or rolled back together. These dependent database changes form logical units, and can be grouped into a single database LUW using the bundling techniques listed below.

A logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW is called an SAP LUW. Unlike a database LUW, an SAP LUW can span several dialog steps, and be executed using a series of different work processes. If an SAP LUW contains database changes, you should either write all of them or none at all to the database. To ensure that this happens, you must include a database commit when your transaction has ended successfully, and a database rollback in case the program detects an error. However, since database changes from a database LUW cannot be reversed in a subsequent database LUW, you must make all of the database changes for the SAP LUW in a single database LUW. To maintain data integrity, you must bundle all of you database changes in the final database LUW of the SAP LUW. The following diagram illustrates this principle:

The bundling technique for database changes within an SAP LUW ensures that you can still reverse them. It also means that you can distribute a transaction across more than one work process, and even across more than one R/3 System. The possibilities for bundling database changes within an SAP LUW are listed below:

The simplest form of bundling would be to process a whole application within a single dialog step. Here, the system checks the user’s input and updates the database without a database commit occurring within the dialog step itself. Of course, this is not suitable for complex business processes. Instead, the R/3 Basis system contains the following bundling techniques.

Bundling using Function Modules for Updates

If you call a function module using the CALL FUNCTION... IN UPDATE TASK statement, the function module is flagged for execution using a special update work process. This means that you can write the Open SQL statements for the database changes in the function module instead of in your program, and call the function module at the point in the program where you would otherwise have included the statements. When you call a function module using the IN UPDATE TASK addition, it and its interface parameters are stored as a log entry in a special database table called VBLOG.

The function module is executed using an update work process when the program reaches the COMMIT WORK statement. After the COMMIT WORK statement, the dialog work process is free to receive further user input. The dialog part of the transaction finishes with the COMMIT WORK statement. The update part of the SAP LUW then begins, and this is the responsibility of the update work process. The SAP LUW is complete once the update process has committed or rolled back all of the database changes.

For further information about how to create function modules for use in update, refer to Creating Function Modules for Database Updates

During the update, errors only occur in exceptional cases, since the system checks for all logical errors, such as incorrect entries, in the dialog phase of the SAP LUW. If a logical error occurs, the program can terminate the update using the ROLLBACK WORK statement. Then, the function modules are not called, and the log entry is deleted from table VBLOG. Errors during the update itself are usually technical, for example, memory shortage. If a technical error occurs, the update work process triggers a database rollback, and places the log entry back into VBLOG. It then sends a mail to the user whose dialog originally generated the VBLOG entry with details of the termination. These errors must be corrected by the system administrator. After this, the returned VBLOG entries can be processed again.

For further information about update administration, see Update Administration

This technique of bundling database changes in the last database LUW of the SAP LUW allows you to update the database asynchronously, reducing the response times in the dialog work process. You can, for example, decouple the update entirely from the dialog work process and use a central update work process on a remote database server.

Bundling Using Subroutines

The statement PERFORM ON COMMIT calls a subroutine in the dialog work process. However, it is not executed until the system reaches the next COMMIT WORK statement. Here, as well, the ABAP statement COMMIT WORK defines the end of the SAP LUW, since all statements in a subroutine called with PERFORM ON COMMIT that make database changes are executed in the database LUW of the corresponding dialog step.

The advantage of this bundling technique against CALL FUNCTION... IN UPDATE TASK is better performance, since the update data does not have to be written into an extra table. The disadvantage, however, is that you cannot pass parameters in a PERFORM... ON COMMIT statement. Data is passed using global variables and ABAP memory. There is a considerable danger of data inconsistency when you use this method to pass data.

Bundling Using Function Modules in Other R/3 Systems

Function modules that you call using CALL FUNCTION... IN BACKGROUND TASK DESTINATION... are registered for background execution in another R/3 System when the program reaches the next COMMIT WORK statement (using Remote Function Call). After the COMMIT WORK, the dialog process does not wait for these function modules to be executed (asynchronous update). All of the function modules that you register in this way are executed together in a single database LUW. These updates are useful, for example, when you need to maintain identical data in more than one database.

For further details, refer to the keyword documentation.

For more details of RFC processing, refer to the Remote Communications section of the Basis Services documentation.

From a business point-of-view, an SAP logical unit of work (SAP-LUW ) consists of an SAP

transaction a user executes online (first part of LUW) and the corresponding update (second part of

LUW). In online processing, the user can proceed with the next SAP transaction after saving, usually

at the end of the transaction processing (online part). The user therefore starts an additional SAPLUW

while the update from the first SAP-LUW was running. This is asynchronous transaction

processing.

n In online processing, the user can proceed with the next SAP transaction after saving, usually at the

end of the transaction processing (online part). The user therefore starts an additional SAP-LUW

while the update from the first SAP-LUW was running. This is called asynchronous transaction

processing.

n The processing of batch input sessions, however, is synchronous. This means SAP-LUW 2 is

not started until the update for SAP-LUW 1 is completed.

Processing mode "A" for call transaction:

After the first part of the SAP-LUW is completed and the changes are marked, the next SAP-LUW

can be started immediately. This means that external data imported using call transaction could be

imported partially in parallel (overlapping import), if the update takes longer than the calling of the

next record to be processed.

n We do not recommend the use of asynchronous processing with CT; if you do use it, test it

thoroughly beforehand.

SAP Notes on updating / locks:

Ÿ Lock table 17267, 13907, 97760

Ÿ Update / repeat update 70085

When the parameter XCALL is selected, processing is through 'Call Transaction .. Using ..?. The

transactions are not stored in a batch input session, instead, processing begins immediately. If

processing with 'Call Transaction .. Using ..' was not successful, the cause of the error is logged, and

the transaction is then saved in a batch input session.

n You can use parameter ANZ_MODE to control the display mode (see CT method).

n The parameter UPDATE specifies the update mode (see CT method).

Database rollback segments are buffer areas that store the ?before image? of the database during a

database logical unit of work (LUW) (DB - LUW = database processing step). The ?before image? is

the change information needed to restore the database to a consistent state, if an error occurs during

this small processing step.

n The call of BDC_INSERT to fill the batch input session causes database changes that fill the

rollback segments. To restrict the growth of these segments, we recommend you trigger a database

commit at regular intervals (every 100 or 1000 loops). To do this, use the ABAP command

COMMIT WORK, which resets the rollback segments

cheers,

sharad.

[Former Member]

Hi,

Database Logical Unit of Work (LUW)

From the point of view of database programming, a database LUW is an inseparable sequence of database operations that ends with a database commit. The database LUW is either fully executed by the database system or not at all. Once a database LUW has been successfully executed, the database will be in a consistent state. If an error occurs within a database LUW, all of the database changes since the beginning of the database LUW are reversed. This leaves the

database in the state it had before the transaction started.

The database changes that occur within a database LUW are not actually written to the database until after the database commit. Until this happens, you can use a database rollback to reverse the changes. In the R/3 System, database commits and rollbacks can be triggered either implicitly or using explicit commands.

Implicit Database Commits in the R/3 System

A work process can only execute a single database LUW. The consequence of this is that a work process must always end a database LUW when it finishes its work for a user or an external call.

There are four cases in which work processes trigger an implicit database commit:

When a dialog step is completed Control changes from the work process back to the SAPgui.

When a function module is called in another work process (RFC).

Control passes to the other work process.

When the called function module (RFC) in the other work process ends.

Control returns to the calling work process.

Error dialogs (information, warning, or error messages) in dialog steps.

Explicit Database Commits in the R/3 System

There are two ways to trigger an explicit database commit in your application programs:

Call the function module DB_COMMIT

The sole task of this function module is to start a database commit.

Use the ABAP statement COMMIT WORK

This statement starts a database commit, but also performs other tasks (refer to the keyword documentation for COMMIT WORK).

Implicit Database Rollbacks in the R/3 System

The following cases lead to an implicit database rollback:

Runtime error in an application program

This occurs whenever an application program has to terminate because of an

unforeseen situation (for example, trying to divide by zero).

Termination message

Termination messages are generated using the ABAP statement MESSAGE with the message type A or X. In certain cases (updates), they are also generated with message types I, W, and E. These messages end the current application program.

Explicit Database Rollbacks in the R/3 System

You can trigger a database rollback explicitly using the ABAP statement ROLLBACK WORK. This statement starts a database rollback, but also performs other tasks (refer to the keyword documentation for COMMIT WORK).

From the above, we can draw up the following list of points at which database LUWs begin and end.

A Database LUW Begins

Each time a dialog step starts (when the dialog step is sent to the work process).

Whenever the previous database LUW ends in a database commit.

Whenever the previous database LUW ends in a database rollback.

A Database LUW Ends

Each time a database commit occurs. This writes all of the changes to the database.

Each time a database rollback occurs. This reverses all of the changes made during the

LUW.

Database LUWs and Database Locks

As well as the database changes made within it, a database LUW also consists of database locks. The database system uses locks to ensure that two or more users cannot change the same data simultaneously, since this could lead to inconsistent data being written to the database. A database lock can only be active for the duration of a database LUW. They are automatically released when the database LUW ends. In order to program SAP LUWs, we need a lock mechanism within the R/3 System that allows us to create locks with a longer lifetime.

SAP LUW

The Open SQL statements INSERT, UPDATE, MODIFY, and DELETE allow you to program database changes that extend over several dialog steps. Even if you have not explicitly programmed a database commit, the implicit database commit that occurs after a screen has been processed concludes the database LUW.

Under this procedure, you cannot roll back the database changes from previous dialog steps. It is therefore only suitable for programs in which there is no logical relationship between the individual dialog steps.

However, the database changes in individual dialog steps normally depend on those in other dialog steps, and must therefore all be executed or rolled back together. These dependent database changes form logical units, and can be grouped into a single database LUW using the bundling techniques listed below.

A logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW is called an SAP LUW. Unlike a database LUW, an SAP LUW can span several dialog steps, and be executed using a series of different work processes. If an SAP LUW contains database changes, you should either write all of them or none at all to the database. To ensure that this happens, you must include a database commit when your transaction has ended successfully, and a database rollback in case the program detects an error. However, since database changes from a database LUW cannot be reversed in a subsequent database LUW, you must make all of the database changes for the SAP LUW in a single database LUW. To maintain data integrity, you must bundle all of you database changes in the final database LUW of the SAP LUW.

The bundling technique for database changes within an SAP LUW ensures that you can still reverse them. It also means that you can distribute a transaction across more than one work process, and even across more than one R/3 System. The possibilities for bundling database changes within an SAP LUW are listed below:

The simplest form of bundling would be to process a whole application within a single dialog step. Here, the system checks the user’s input and updates the database without a database commit occurring within the dialog step itself. Of course, this is not suitable for complex business processes. Instead, the R/3 Basis system contains the following bundling techniques.

Bundling using Function Modules for Updates

If you call a function module using the CALL FUNCTION... IN UPDATE TASK statement, the function module is flagged for execution using a special update work process. This means that you can write the Open SQL statements for the database changes in the function module instead of in your program, and call the function module at the point in the program where you would otherwise have included the statements. When you call a function module using the IN UPDATE

TASK addition, it and its interface parameters are stored as a log entry in a special database table called VBLOG.

The function module is executed using an update work process when the program reaches the COMMIT WORK statement. After the COMMIT WORK statement, the dialog work process is free to receive further user input. The dialog part of the transaction finishes with the COMMIT WORK statement. The update part of the SAP LUW then begins, and this is the responsibility of the update work process. The SAP LUW is complete once the update process has committed or rolled back all of the database changes.

During the update, errors only occur in exceptional cases, since the system checks for all logical errors, such as incorrect entries, in the dialog phase of the SAP LUW. If a logical error occurs, the program can terminate the update using the ROLLBACK WORK statement. Then, the function modules are not called, and the log entry is deleted from table VBLOG. Errors during the update itself are usually technical, for example, memory shortage. If a technical error occurs, the

update work process triggers a database rollback, and places the log entry back into VBLOG. It then sends a mail to the user whose dialog originally generated the VBLOG entry with details of the termination. These errors must be corrected by the system administrator. After this, the returned VBLOG entries can be processed again. This technique of bundling database changes in the last database LUW of the SAP LUW allows you to update the database asynchronously, reducing the response times in the dialog work process. You can, for example, decouple the update entirely from the dialog work process and

use a central update work process on a remote database server.

Bundling Using Subroutines

The statement PERFORM ON COMMIT calls a subroutine in the dialog work process. However, it is not executed until the system reaches the next COMMIT WORK statement. Here, as well, the ABAP statement COMMIT WORK defines the end of the SAP LUW, since all statements in a subroutine called with PERFORM ON COMMIT that make database changes are executed in the

database LUW of the corresponding dialog step.

Bundling Using Function Modules in Other R/3 Systems

Function modules that you call using CALL FUNCTION... IN BACKGROUND TASK DESTINATION... are registered for background execution in another R/3 System when the program reaches the next COMMIT WORK statement (using Remote Function Call). After the COMMIT WORK, the dialog process does not wait for these function modules to be executed (asynchronous update). All of the function modules that you register in this way are executed together in a single database LUW. These updates are useful, for example, when you need to

maintain identical data in more than one database.

Regards,

Raj.

[Former Member]

An SAP LUW is a logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW. In an application program, you end an SAP LUW with either the COMMIT WORK or ROLLBACK WORK statement. An SAP transaction is an application program that you start using a transaction code. It may contain one or more SAP LUWs. Whenever the system reaches a COMMIT WORK or ROLLBACK WORK statement that is not at the end of the last dialog step of the SAP transaction, it opens a new SAP LUW.

http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4b9a79e11d1950f0000e82de14a/frameset.htm

http://help.sap.com/saphelp_47x200/helpdata/en/41/7af4b9a79e11d1950f0000e82de14a/frameset.htm

Check out these links. Hope these help

Regards.

[Former Member]

hi,

A “LUW”(logical unit of work) is the span of time during which any database updates must be performed in an “all or nothing” manner .Either they are all performed (committed),or they are all thrown away (rolled back).

Two types of LUW are:

1) DB LUW - A database LUW is the mechanism used by the database to ensure that its data is always consistent. A database LUW is an inseparable sequence of database operations that ends with a database commit. The database LUW is either fully executed by the database system or not at all. Once a database LUW has been successfully executed, the database will be in a consistent state. If an error occurs within a database LUW, all of the database changes since the beginning of the database LUW are reversed. This leaves the database in the state it had before the transaction started.

This is the set of updates terminated by a database commit. A LUW lasts, at most, from one screen change to the next (because the SAP system triggers database commits automatically at every screen change).

2) SAP LUW - A logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW is called an SAP LUW. Unlike a database LUW, an SAP LUW can span several dialog steps, and be executed using a series of different work processes.This

is a set of updates terminated by an ABAP/4 commit. A SAP LUW may last much longer than a database LUW, since most update processing extends over multiple transaction screens. The programmer terminates an update transaction by issuing a COMMIT WORK statement.

pls reward if helpful.

Edited by: Rajyalakshmi Attili on Apr 24, 2008 1:19 PM