Commit Work

[jitendra_it]

Hi All,

I am calling a FM from abap program. FM inserts a record in ztable.  If I do NOT use commit work , still record gets saved in DB. Please help me in knowing where commit work is executed.

below is code :

Program : ZTEST

WRITE : 'calling'

call FUNCTION 'ZUPDATE' .

WRITE : 'done'.

FM : ZUPDATE

FUNCTION ZUPDATE.

DATA:  wa type ztest.

wa-roll = '80'.

wa-name =  'test'.

insert ztest from wa.

ENDFUNCTION.

[former_member213851]

Hi Jitendra,

Can u  share code inside FM ZUPDATE...

[Former Member]

Hi Jitendra,

This is due to the implicit commit. Read about SAP LUW.

http://help.sap.com/saphelp_46c/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/frameset.htm

As well as the COMMIT WORK and ROLLBACK WORK statements, there are other situations where data is implicitly written to the database or rolled back, and where database LUWs therefore begin and end.

http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb3b64358411d1829f0000e829fbfe/content.htm

Thanks,

Shambu

[Former Member]

Hi Jitendra ,

    This above is just a custom function module which you have created normally without update task and not remote enabled function module also.

When you create a function module with update task the commit work makes the difference.

The below screen shots give better idea .

With Regards,

Sudhir S

[Clemenss]

Hi Jitendra Soni,

as suggested, read the help.

Shortly taken: Every interruption of a running program (screen processing, message output, RFC call or regular program end) triggers a so-called implicit database commit.

ABAP COMMIT WORK triggers execution of update modules (functions called 'IN UPDATE TASK'), and execution of PERFORM ON COMMIT.

Don't worry - also very experienced users just do not understand this.

Regards

Clemens

[Former Member]

Hi Clemens,

So suppose, I have

INSERT INTO zsflight VALUES wa_zsflight.

The new row is inserted immediately after this statement (I checked this in the debugger). It does not wait until it encounters a COMMIT WORK statement.

From your post, I understand that this is because of an implicit COMMIT that gets triggered whenever there is an interruption.

So in the above INSERT statement, what is causing that interruption? There is no screen change, there is no message, no RFC...Also the insertion of the new row happened before the program even ended (as mentioned earlier, I checked this while the prog was in debugger mode). What is the cause of this implicit COMMIT?

Another question I have is - when would an explicit COMMIT WORK statement be necessary?

Thanks for your time and effort.

[RaymondGiuseppi]

If you are using the old debugger you are performing lot of implicit db_commit. (Cause the debug used to be executed in same session)

In old versions documentation, there was the following warning in documentation

Never use the debugging function in a production system.  Use it only in those test systems in which a potential data inconsistency is unimportant.  The problem:  the debugging facility can force an unwanted database commit, which may result in inconsistent data in the database. 

Regards,

Raymond

[Former Member]

Hi Raymond,

Thanks for the reply.

I was using the new debugger. So does the warning you mentioned, apply even to the new debugger? Will it cause implicit commits?

Thanks for your time and effort.

[RaymondGiuseppi]

The new debugger should not generate db commit, how did you check that the data was inserted in database, did you use another small report performing a SELECT bypassing buffer or a toll like SE16(n) ?

The data will be commit-ed in database at first implicit commit, like when displaying a screen at the end of the program.

Regards,

Raymond

[Former Member]

Its pretty simple concept of synchronous and asynchronous processing of data.

If the update is synchronous, you do not need to write a commit work as this is done by implicit commit. Remember execution comes back to the calling program.

If the update is asynchronous, like any update using a BAPI, then you have to write explicitly commit to make the system understand that the values are to be written to database now.

Thanks,

Anubhav

[Former Member]

If the update is synchronous, you do not need to write a commit work as this is done by implicit commit. Remember execution comes back to the calling program.

How does implicit commit make an update synchronous?

Thanks,
Venkat.

Message was edited by: Venkat Gowrishankar

[Former Member]

Hi Venkat,

Implicit commit has no role in making a process synchronous or asynchronous.. Rather its the other way. If you are updating database in any synchronous process, it does not matter you write commit work or not. Data will be written to database because the commit work is executed implicitly for synchronous processes. However, in asynchronous processes you have to write explicitly commit as there are no internal sessions or transaction calls or any other change which may cause an implicit commit.

Get some info from sap help on LUWs & how types of function modules work - Normal, Update & RFC. This will give some more clarity to this concept of commit work.

Thanks

Anubhav

[Former Member]

Hi Anubhav,

Get some info from sap help on LUWs & how types of function modules work - Normal, Update & RFC. This will give some more clarity to this concept of commit work.

Thanks for the tip, Maybe you too should have a look  .

Thanks,

Venkat.

[RaymondGiuseppi]

If you actually want to "control" the update via commit work and not an implicit database commit :

- change function module Z_UPDATE and declare it as an update module.

- change main program with

call FUNCTION 'Z_UPDATE'  IN UPDATE TASK.

then executing  COMMIT WORK, ROLLBACK WORK or none of those.

Regards,

Raymond

[former_member286481]

Hello,

Inside the FM 'Z_UPDATE' the insert statement will perform an implicit commit. Hence the explicit commit statement COMMIT WORK not needed here.

Thanks,

Karthik