luw

[Former Member]

luw explain ?

[Former Member]

Hi,

A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirety or not at all. For the database system, it thus constitutes a unit.

LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.

An LUW begins

o each time you start a transaction

o when the database changes of the previous LUW have been confirmed (database commit) or

o when the database changes of the previous LUW have been cancelled (database rollback)

An LUW ends

o when the database changes have been confirmed (database commit) or

o when the database changes have been canceled (database rollback)

SAP memory and ABAP memoryUsing SAP memory. User-specific memory retained for the duration of the session. Can only be used for simple field values.

Using ABAP memory. Can be used to transfer data between internal modi. Can be used to transfer any ABAP/4 variables ( Fields, strings, internal tables, complex objects)

SAP memoryYou use the SPA/GPA parameters to pass data. These paramters are saved globally in memory. The paramters are indetified by a three-character code.

In dialog programs you can SET and GET these parameters in the attribute window of the screen field, by marking the SET and GET fields and put the name of the parameter in the ParameterId field.

In a program ( Dialog or Report ) you can use the GET PARAMETER and SET PARAMETER statements:

set parameter id 'RV1' field <fieldname>

get parameter id 'RV1' field <fieldname>

Regards,

KISHI.

[Former Member]

HI,

What is LUW or Database LUW or Database Transaction ?- A “LUW” ( logical unit of work ) is the span of time during which any database updates must be performed . Either they are all performed ( committed ) , or they are all thrown away ( rolled back ).

LUW ( or “database LUW” or “database transaction” )

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 ).

LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.

Go To the link:

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

An LUW begins

- Each time you start a transaction

- When the database changes of the previous LUW have been confirmed (database commit) or

- when the database changes of the previous LUW have been cancelled (database rollback)

An LUW ends

- When the database changes have been confirmed (database commit) or

- When the database changes have been canceled (database rollback)

What is SAP LUW or Update Transaction ?

- Update transaction ( or “SAP LUW”)

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 points if this Helps.

Kishi.

[Former Member]

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.

rewards if useful.....

Regards.....

Abhay

[Former Member]

Hi sravan,

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 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.

Reward if useful!

[seshatalpasai_madala]

Hi,

LUW: Logical Unit of Work.

Means a series of transaction that have to be executed as a WHOLE.

That is either all the transaction have to be succesfull or none.

This works on the principle of ALL or NOTHING. That is Either SAVE all or NOTHING.

SO when you modify database tables as part of a sequence of transactions and if you SAVE all the changes only it make sense so either you COMMIT it at the end of the last transaction or you do ROLLBACK on the first failure.

We have SAP LUW and DB LUW.

SAP LUW for SAP Process steps and DB LUW for DB transactions.

Regards,

Sesh

[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 was in before the transaction started.

do chek the folowing links

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

http://en.wikipedia.org/wiki/ABAP

Hope this helps to solve ur problem....

<b>do reward if useful....</b>

regards

dinesh