SAP LUW

[Former Member]

Hi.

Can anyone tell what is SAP LUW and ABAP LUW?

What is SAP and ABAP memory?

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

<b>SAP memory and ABAP memory</b><b>Using SAP memory</b>. User-specific memory retained for the duration of the session. Can only be used for simple field values.

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

<b>SAP memory</b>You 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>

rgds,

latheesh

Message was edited by: Latheesh Kaduthara

[Former Member]

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.

There is a difference between the cross-transaction SAP memory and the transaction-specific ABAP memory.

Global SAP memory

The global SAP memory is available to a user during the entire duration of a terminal session. Its contents are retained across transaction boundaries as well as external and internal sessions. The SET PARAMETER and GET PARAMETER statements allow you to write to, or read from, the SAP memory.

Input fields on screens can be linked with parameters in the SAP memory, which allows you to preassign values to the input fields on initial screens.

With general screens, the linking takes place during the definition of the screen using the Screen Painter tool. When setting the field attributes of an input field, you can specify the ID of an SPA/GPA parameter in the Parameter-ID attribute. In the checkboxes SET Parameter and GET Parameter you can specify whether the screen field is filled with the value of the SPA/GPA parameter at the time of PBO or whether the SPA/GPA parameter is filled with the user input on the screen at the time of PAI.

With selection screens, the linking is carried out using the MEMORY ID addition to the PARAMETERS or SELECT-OPTIONS statement. If you specify an SPA/GPA parameter ID, when declaring a parameter or selection criterion, the relevant input field is linked with the parameter.

Local SAP memory

The local SAP memory is available to the user throughout a transaction, within which you can also call other program units, for example using SUBMIT or CALL TRANSACTION. With SET PARAMETER you write to both the global and the local SAP memory. If the global SAP memory is changed by an external mode of the same user, the local SAP memory remains unchanged. This ensures that parameters set in the frame of a transaction remain unchanged until the end of this transaction. The local SAP memory is deleted after the transaction is ended.

ABAP memory

The contents of the ABAP memory are retained only during the lifetime of an external session (see also Organization of Modularization Units). You can retain or pass data across internal sessions. The EXPORT TO MEMORY and IMPORT FROM MEMORY statements allow you to write data to, or read data from, the ABAP memory.

Please consult Data Area and Modularization Unit Organization documentation as well.

and

Memory Structures of an ABAP Program

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)

Database commit and rollback

Within an LUW, database changes are not made until after a database commit. Prior to this, any database change can be canceled by a database rollback.

In the R/3 System, a database commit is triggered either automatically or by the ABAP/4 command COMMIT WORK or the appropriate Native SQL command for the database system.

Similarly, a database rollback is triggered either automatically or by the ABAP/4 command ROLLBACK WORK or the appropriate Native SQL command for the database system.

A database commit is triggered automatically by

each screen change, and especially after the ABAP/4 commands CALL SCREEN, CALL DIALOG, CALL TRANSACTION, MESSAGE or

a Remote Function Call

A database rollback is triggered automatically by

errors which occur at runtime or

the ABAP/4 command MESSAGE with the message type 'A'

After each database commit or rollback, the database locks set in the LUW are released (see Database Locking).

[Former Member]

LUW,

two types:

1.SAP LUW----COMMIT AT THE END OF TRANSACTION

2.DB LUW------COMMIT AFTER EVERY SCREEN

LUW AND ITS TYPES CAN BE OBTAINED FROM THE LINKS GIVEN

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

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

Database LUW vs. SAP LUW

In the case of the database, an LUW is a sequence of data operations that cannot be divided up . The operations are either carried out in full or not at all. Database LUWs are modules which go to make up the database procedures for consistent data processing. An R/3 transaction can include several database LUWs (see example above), each of which can be terminated with a database COMMIT, which is generated automatically.

By way of contrast, an LUW for the R/3 System is a business process, which cannot be divided up. The process is either executed in full or not at all. The SAP LUW of an R/3 transaction usually has to contain several database LUWs. Under normal circumstances, it contains a dialog transaction (which maps a business process), and the command for writing the data to the database (update).

In each database LUW, data is written to the database to special update tables (and not to the application tables). Once the dialog area has been completed, all of the data in a database LUW is copied to the application tables: the update request is then performed

REWARD IF USEFUL AND CLOSE THIS THREAD..

<b>2)</b>

SAP Memory :

SAP memory is a memory area to which all main sessions within a SAPgui have access. You can use SAP memory either to pass data from one program to another within a session, or to pass data from one session to another. Application programs that use SAP memory must do so using SPA/GPA parameters (also known as SET/GET parameters). These parameters can be set either for a particular user or for a particular program using the SET PARAMETER statement. Other ABAP programs can then retrieve the set parameters using the GET PARAMETER statement. The most frequent use of SPA/GPA parameters is to fill input fields on screens

ABAP/4 Memory :

ABAP memory is a memory area that all ABAP programs within the same internal session can access using the EXPORT and IMPORT statements. Data within this area remains intact during a whole sequence of program calls. To pass data

to a program which you are calling, the data needs to be placed in ABAP memory before the call is made. The internal session of the called program then replaces that of the calling program. The program called can then read from the ABAP memory. If control is then returned to the program which made the initial call, the same process operates in reverse.

Local Memory :

Data is available within program

Please reward points if it helps.

[Former Member]

hii

Within a main session, when ever you start an application program, it opens up an internal sessions with in the main session. The internal session has a memory area that contains the ABAP program and its associated data. So when ever you want to pass data between two internal sessions, then you can use <b>ABAP Memory</b> (i.e import, export).

When comes to <b>SAP memory</b> (also known as <b>global memory</b>), if the data has to be passed b/w two main sessions, we can use SAP Memory(SPA/GPA Parameters). SAP Memory can also be used to pass data b/w internal sessions.

<b>SAP Memory</b> :

SAP memory is a memory area to which all main sessions within a SAPgui have access. You can use SAP memory either to pass data from one program to another within a session, or to pass data from one session to another. Application programs that use SAP memory must do so using SPA/GPA parameters (also known as SET/GET parameters). These parameters can be set either for a particular user or for a particular program using the SET PARAMETER statement. Other ABAP programs can then retrieve the set parameters using the GET PARAMETER statement. The most frequent use of SPA/GPA parameters is to fill input fields on screens

<b>ABAP/4 Memory</b> :

ABAP memory is a memory area that all ABAP programs within the same internal session can access using the EXPORT and IMPORT statements. Data within this area remains intact during a whole sequence of program calls. To pass data

to a program which you are calling, the data needs to be placed in ABAP memory before the call is made. The internal session of the called program then replaces that of the calling program. The program called can then read from the ABAP memory. If control is then returned to the program which made the initial call, the same process operates in reverse.

<b>Local Memory</b> :

Data is available within program

<b>SAP memory</b>

The SAP memory, otherwise known as the global memory, is available to a user during the entire duration of a terminal session. Its contents are retained across transaction boundaries as well as external and internal sessions. The SET PARAMETER and GET PARAMETER statements allow you to write to, or read from, the SAP memory.

<b>

ABAP/4 memory </b>

The contents of the ABAP/4 memory are retained only during the lifetime of an external session (see also Organization of Modularization Units). You can retain or pass data across internal sessions. The EXPORT TO MEMORY and IMPORT FROM MEMORY statements allow you to write data to, or read data from, the ABAP memory.

check this links

<b>http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4bca79e11d1950f0000e82de14a/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/content.htm</b>;

Database LUW and SAP LUW

In the case of the database, an LUW is a sequence of data operations that cannot be divided up . The operations are either carried out in full or not at all. Database LUWs are modules which go to make up the database procedures for consistent data processing. An R/3 transaction can include several database LUWs (see example above), each of which can be terminated with a database COMMIT, which is generated automatically.

By way of contrast, an LUW for the R/3 System is a business process, which cannot be divided up. The process is either executed in full or not at all. The SAP LUW of an R/3 transaction usually has to contain several database LUWs. Under normal circumstances, it contains a dialog transaction (which maps a business process), and the command for writing the data to the database (update).

In each database LUW, data is written to the database to special update tables (and not to the application tables). Once the dialog area has been completed, all of the data in a database LUW is copied to the application tables: the update request is then performed

Regards

Naresh

[Former Member]

Hi,

In the case of the database, an LUW is a sequence of data operations that cannot be divided up . The operations are either carried out in full or not at all. Database LUWs are modules which go to make up the database procedures for consistent data processing. An R/3 transaction can include several database LUWs (see example above), each of which can be terminated with a database COMMIT, which is generated automatically.

By way of contrast, an LUW for the R/3 System is a business process, which cannot be divided up. The process is either executed in full or not at all. The SAP LUW of an R/3 transaction usually has to contain several database LUWs. Under normal circumstances, it contains a dialog transaction (which maps a business process), and the command for writing the data to the database (update).

In each database LUW, data is written to the database to special update tables (and not to the application tables). Once the dialog area has been completed, all of the data in a database LUW is copied to the application tables: the update request is then performed

[former_member181962]

Check the following links:

There is nothing like abap luw .ONly sap luw is there.

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

Diff between sap and abap memmory

Regards,

Ravi

[Former Member]

hi

good

go through this

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:

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:

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.

-

---

ABAP LUW

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

SAP Memory

SAP memory is a memory area to which all main sessions within a SAPgui have access. You can use SAP memory either to pass data from one program to another within a session, or to pass data from one session to another. Application programs that use SAP memory must do so using SPA/GPA parameters (also known as SET/GET parameters). These parameters can be set either for a particular user or for a particular program using the SET PARAMETER statement. Other ABAP programs can then retrieve the set parameters using the GET PARAMETER statement. The most frequent use of SPA/GPA parameters is to fill input fields on screens

ABAP/4 Memory

ABAP memory is a memory area that all ABAP programs within the same internal session can access using the EXPORT and IMPORT statements. Data within this area remains intact during a whole sequence of program calls. To pass data

to a program which you are calling, the data needs to be placed in ABAP memory before the call is made. The internal session of the called program then replaces that of the calling program. The program called can then read from the ABAP memory. If control is then returned to the program which made the initial call, the same process operates in reverse.

SAP memory

The SAP memory, otherwise known as the global memory, is available to a user during the entire duration of a terminal session. Its contents are retained across transaction boundaries as well as external and internal sessions. The SET PARAMETER and GET PARAMETER statements allow you to write to, or read from, the SAP memory.

ABAP/4 memory

The contents of the ABAP/4 memory are retained only during the lifetime of an external session (see also Organization of Modularization Units). You can retain or pass data across internal sessions. The EXPORT TO MEMORY and IMPORT FROM MEMORY statements allow you to write data to, or read data from, the ABAP memory.

THANKS

MRUTYUN