What is the need of commit work ?

[Former Member]

In a z table without using commit work data saved into the database. when I start to searching about it always explanations with sap logical unit work but not get the exact answer.

Thanks

[former_member184158]

Hello Nandha,

in SAP there is implicitly and explicitly commit work. Your data has been saved implicitly.

But when you write it then it means explicitly.

So when I use this.

INSERT target FROM TABLE itab
if p_test = abap_true. 
ROLLBACK WORK.
else.
COMMIT WORK.
Endif.

in this code, the data could be saved or not depending on the paramter test.

So here the explicitly commit work has been done.

Regards

Ebrahim

[Sandra_Rossi]

Additional informations:

• Implicit and Explicit database commits are explained in ABAP documentation - Database Commit.

• COMMIT WORK executes many operations (update task, t/bg/q/RFC) which are ended by a database commit.

[Jelena]

In layman's terms, the updates your program is doing are not actually saved in the database immediately. They are just stored temporarily in memory and COMMIT is what saves the changes in DB. As you've noticed, even if we don't have COMMIT statement, the data is still saved at the end of the program. That's because the system does it for us. If you have a simple program that, say, reads a file and fills in a Z table then you don't have to add COMMIT.

But, for example, if you have a program that performs multiple updates and after the first update you can only proceed with the next one after the first change have been committed to DB then, naturally, you have to add a COMMIT in between. There are other situations when it is needed, please refer to the documents mentioned by Sandra for more details.

Note that "database commit" is not ABAP or SAP proprietary term, it's a general DB concept.

[Former Member]

Hi, Jelena thanks for the clear explanation. Here in my case I am sending mail before creating sales order when I am sending mail a commit work happens automatically , after this work I am not able to create sales order because of the first commit work, I know we can't use two commit in a flow, but what is the background logic exist in this,(I was used update STARTING NEW TASK 'SEND_MAIL' to overcome the first commit).

[SuhaSaha]

First of all without the "relevant" code-snippet it's difficult to analyse your problem.

I was used update STARTING NEW TASK 'SEND_MAIL' to overcome the first commit

FYI, STARTING NEW TASK will trigger an implicit DB-commit!

https://help.sap.com/abapdocu_751/en/abendb_commit.htm

[horst_keller]

The ABAP statement COMMIT WORK commits the changes done during a SAP LUW. It must not mixed up with a DB-Commit.

An SAP LUW refers to a logical unit in ABAP programs that behaves like a database LUW; in other words, it produces a consistent database status when it ends. While an SAP LUW may extend across several work process changes, the database changes are executed within a single database LUW. This is done by bundling. The required database changes are not executed directly in this case. Instead, they are collected over the course of various work process changes, and then executed as a bundle in the database in the final work process of the SAP LUW. This means that only the bundle of collected database changes is subject to the LUW mechanism of the database.

The ABAP language provides several mechanisms for bundling database changes in a work process. The most important one is bundling in update function modules. You collect your change requests by calling these function modules in UPDATE TASK. The statement COMMIT WORK then kicks off the execution.

Why all this fuzz? An AS ABAP has one or multiple application servers and these, in turn, have work processes. Every ABAP program that is currently active requires a work process, and each work process is logged on to the database system as a user. A work process cannot execute more than one database LUW in parallel and, conversely, more than one work process cannot influence a single database LUW. However, an ABAP program is frequently linked with more than one work process over the course of its total runtime. At all times during which a program is inactive (e. g., because it is waiting for the user to make an entry, or it is waiting, as a client, for a task on a server to be completed), it is normally rolled out of the work process, together with its data, and the work process is occupied otherwise. As a result, a work process must always end an LUW and execute an implicit database commit when its responsibility for a program changes.

As long as you change data inside one work process, you don't have to care about SAP LUW. The changes are commited implicitly at the end of the workprocess. An explicit DB-commit can be achieved with function module DB_COMMIT

[Sandra_Rossi]

(typo: in UPGRADE TASK -> in UPDATE TASK)

[horst_keller]

Yep .......

[former_member214867]

Hi, all.

Horst wrote:

The ABAP language provides several mechanisms for bundling database changes in a work process. The most important one is bundling in update function modules. You collect your change requests by calling these function modules in UPDATE TASK. The statement COMMIT WORK then kicks off the execution.

I have a question, than use of modules in update task is better than direct updates from program and for what the technology update task has been developed?

[horst_keller]

"for what the technology update task has been developed?"

That tackles the classical transactional SAP programming model with SAP GUI (Dynpro) and it is not simple to answer in short (well I tried to in my answer below).

Another try: For technical reasons, DB change operations that are spread over several work processes (screen changes; PAI, PBO of several Dynpros) must be bundled in one Update WP. Otherwise, inconsistent data can result, e.g. when the user leaves a program before explicitly saving. If write operations on the DB are spread over several Dynpro screens, those would be commited implicitly with each screen change (because of change of WP). Therefore all write operations are collected and bundled to avoid unwanted implicit commits inbetween.

In the future other programming models will emerge and Update might become less important.

[former_member214867]

But I can transfer my DB changes at the last dialog step of my transaction and use direct update (insert, delete, modify, .. ) and my DB changes will be bundled and executed in one DB LUW.

[horst_keller]

Yep, then you simply do the bundling yourself.

The bundling techniques delivered by SAP (UPDATE TASK, PERFORM ON COMMIT, ...) are convenience tools for that.

If you do it yourself you have to keep track of the changes a user might intend to do over several screens in selfdefined itabs or whatsoever.

[former_member214867]

Thanks for an explanation, Horst.