Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Understanding commit and rollback

Former Member
0 Likes
1,074

Dear all,

I have been doing lot of readings on LUW.Rather it has made me more confused.I have two questions.

Prob 1.

perform routine1 on commit.

perform routine2 on commit.

commit work and wait.

Does this means that all update statements in routine 1 and routine 2 are bundled and commit wil happen only once

on reaching commoit work and wait.

Secondly in this section of code ,i am trying to update a Z table from an internal table.Here in my opinion if i used

SET SCREEN 0,it is equal to commit also as it indicates dialog change. Is it true ?

But i used commit work and wait for a synchronized commit. Is this a better way ?.

Prob2.

loop at t_zlcdetail into wa_zlcdetail.

modify zsendlc from wa_zlcdetail.

endloop.

commit work and wait.

Here how to provide rollback,incase things do not meet well.

7 REPLIES 7
Read only

Former Member
0 Likes
1,042

Hello Aditya,

a PERFOMR ..ON COMMIT is executed on COMMIT WORK. Keep in mind that the data may change from executing PERFORM statement until performing the COMMIT_WORK.

If you execute an ROLLBACK WORK the FORM-routines are not executed.

SET SCREEN 0 doesn't perform a COMMIT WORK. If this would do so, every time a screen changes, a COMMIT WORK would be performed. This is not the case.

Regards

Elmar

Read only

0 Likes
1,042

I read in books that every dialog change makes an implicit commit.Then why not ?

Read only

0 Likes
1,042

Second thing, if you see this loop where i can ensure that something gone wrong with updating table.

We do not have try catch here.like when to call rollback here,how i know things didn;t work out well?

Read only

0 Likes
1,042

Hi,

There is something called a call stack where every command that is executed is stored here with an address assigned to it.

So when a subroutine is called, it has to know to which point it has to return back exactly. During the time of the call, all the data is stored and the return address is also stored here in the return address. Once the call is done, it goes to another address (where the FORM...ENDFORM is written), executes that and then returns to the address as specified in the stack.

The same goes with a dialog screen change too.

I think you are referring to this.

It is not a literal COMMIT on the database table.

Before I answer your second question

- It is not advisable to modify your database table in a loop unless it is unavoidable. Its an expensive affair coz you hit your database for every record. So it is always better to accumulate all the data into an internal table and then insert them into the database.

So as to when you want to use ROLLBACK, it totally depends on how you want your functionality to work. The MODIFY or INSERT (for database table updates and insert) have a sy-subrc value associated. So when it is 4, you can do a ROLLBACK.

But it is always advisable to validate your data for all possible scenarios and then insert them into the database.

@Others

Please correct me if I'm wrong.

Read only

0 Likes
1,042

Netwick say i use this example code

PERFORM FORMA ON COMMIT.

PERFORM FORMB ON COMMIT.

COMMIT WORK AND WAIT.

FORM A

UPDATE ZMSEG WHERE MBLNR = 'X'. //sy-subrc = 0

UPDATE ZMSEG WHERE MBLNR = 'Y'. //sy- subrc = 4

END FORM

FORM B

UPDATE ZMKPF WHERE MBLNR = 'X'. //sy-subrc = 0

UPDATE ZMKPF WHERE MBLNR = 'Y'. //sy-subrc = 0

END FORM

Where to check here as we see sy-subrc = 4 in second update query. How to rollback now.

Read only

0 Likes
1,042

My second question is how this code should ideally behave ?

Read only

0 Likes
1,042

>Hello Aditya,

>a PERFOMR ..ON COMMIT is executed on COMMIT WORK. Keep in mind that the data may change from executing PERFORM >statement until performing the COMMIT_WORK.

>If you execute an ROLLBACK WORK the FORM-routines are not executed.

>SET SCREEN 0 doesn't perform a COMMIT WORK. If this would do so, every time a screen changes, a COMMIT WORK would be >performed. This is not the case.

>Regards

>Elmar

No Mr Elmar implicit DB commit happend with every screen change.