implicit database commit

[Former Member]

change of screen triggers an implicit database commit..

wat does this exactly mean???

is it the SAP system behavoiur or is it that ther is some code written that triggers the commit after every screen ??

this is regarding database & SAP LUW...

[Former Member]

yes when screen changes then commit work is done implicitly......it is considered as one LUW .......it is designed like this only........SAP needs to commit work..after every LUW...it selected transitions from one screen to another as 1 LUW

[Former Member]

Are you changing the screen sequence of standard SAP process?

[christian_wohlfahrt]

Hi!

If you have a transaction with several screens, you cannot update the database directly in each screen - either you gather your updates into last step (of last screen), or you trigger your changes with call function ... in update task / perform ... on commit. Then the transaction logic will still be correct.

Have also a look at SAP's comments: <a href="http://help.sap.com/saphelp_erp2005vp/helpdata/en/41/7af4cea79e11d1950f0000e82de14a/frameset.htm">Asynchronous Update</a>

Regards,

Christian

[Former Member]

Hi bikash,

1. wat does this exactly mean

It means that whenever screen

changes,

the r/3 system, automatically

does COMMIT work,

behind the scenes.

2. is it the SAP system behavoiur

Yes, Its the SAP System behaviour.

regards,

amit m.

[Former Member]

thanks for the reply guys..

Amit n Amole, if thats the case, then how does the bundling technique work???

i mean to say that..if database LUW happens implicitly without we being able to control it, how do we restrict it from commiting for every screen and bundling them to form an SAP LUW ( an SAP LUW can have lots of database LUWs and they r bundled together to maintain the data consistency.. ) ..

awaiting ur inputs...

[Former Member]

Hi again,

1. Good Question.

2. This can be best understood with an example

3. Suppose a purchase order has

a) header details

b) line item details

c) delivery details

d) payment details

e) texts

g) ... other details

4. Which are all entered

in various different screens,

and also stored in various tables.

5. So,

instead of

entering data on each screen

and saving at that point of time only,

6. the technique used is

a) do not save using sql at each screen

b) just collect all entered data

in internal tables

c) after all proper entry, when the user presses SAVE button,

d) pass all this internal table data

to a SINGLE FM, (which is of normal type, or update type)

e) This FM will pass the SQLS,

to actually update the tables.

f) THIS BUNCHING IS CARRIED OUT IN THIS FASHION.

regards,

amit m.

[Former Member]

exactly amit...now here again i get back to my initial question...was does implicit commit means??

in this case it means that actually its a query that SAP designers have coded so that the commit happens wenever one moves to a diff screen... so we can instead comment(or suppress) that code, n instead store te values in a buffer n finally commit it after completion of the transaction...so its not the inherent behaviour of the system but the code dat does this...pl let me know if my understanding is correct....

amit, i have one more post regarding basic abap doubts..cud u pl help me in those too..!!!

thanks,

bikash

[Former Member]

Hi again,

1. we cannot change the behaviour of implicit commit.

R/3 is designed in that way.

(There is no special abap code

written in any standard programs,

for implicit commit.

2. It is the R/3 server

which DETECTS that the screen has changed

and does the commit.

regards,

amit m.

[Former Member]

hey...m confused again...

wenever R/3 detects a screen change, the COMMIT happens,ie, database changes take place n it cannot be rolled back...so how exactly r we able to control this in case of a transaction via bundling?? agreed to wat u said abt using FMs to update n group n all that...but wen R/3 itself triggers the COMMIT, then how do u roll back the changes after lets say the 3rd screen?? i mean its again not falling into place..m i going terribly wrong in my understanding somewhere???

[Former Member]

Hi again,

1. then how do u roll back the changes after lets say the 3rd screen??

Which changes are u talking about ?

2. No changes have been done

to database tables,

in secreen 1 and screen 2.

(changes have been done to screen and memory variables only,

not to any database tables)

regards,

amit m.

[Former Member]

but a database LUW gets completed after a screen is processed right?? n a COmmit happens, ie, the database is updated(thats wat a commit does right?)...i m talking about these changes that happen in a database after every screen( just forget abt wat happens in case of a transaction as of now)...so wat we r doin is getting the screen data into some buffer and then commiting to databse finally after SAVE....but my question is, wen R/3 itself COMMITS after every screen, isnt the data getting updated to the database after every screen implicitly??

pl help me understand this...

appreciate ur responses...

[Former Member]

Hi again,

1. lots of confusion

2. isnt the data getting updated to the database after every screen implicitly??

Only that data,

OF THAT PARTICULAR SESSION/PROGRAM/TCODE

will get updated (if any)

3. Each session,

has its own database luw.

regards,

amit m.

[Former Member]

Hi,

SAP has inbuild mechanism of implicitly database

commit .This depends upon backend database in use

eg.DB2 requires explicit database commit after

each select query .

Regards

Amole

[Former Member]

Hi,

we can control implicit database commit using

using

open cursor with hold while selecting data.

OPEN CURSOR WITH HOLD GV_DB_CURSOR FOR

SELECT * FROM ZCOXPRIHST

WHERE BUKRS IN S_BUKRS

AND BUDAT IN S_BUDAT.

also check below link

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

Regards,

amole

[Former Member]

Hi,

With SAP's natural behavior on perform implicit commit at every single LUW, it does came out a way on how to handle it. Because most of the time, this implicit commit could not coupe with the business operation.

<u>Bundling</u> is needed. Bear in mind, SAP std transcations are using this technique as well. There are few bundling techniques available, but i would recommend UPDATE TASK FM.

First, put all your DB operations(UPDATE, INSERT, etc) the UPDATE TASK FM. So, you need to call the FM whenver you need to have DB operation.

And, bear in mind only put the explicit COMMIT WORK at your last screen.

And for each of the UPDATE TASK FM, you need to have a return code checking after the DB operation called. for

eg: IF SY-SUBRC <> 0.
      MESSAGE A000(SABAPDOCU): 'failed to update'.
    ENDIF.

if the above execute, implicit rollback will be triggered. Immeadiately system will send you an "update termination" message. And none of the update being carried out. And you can check the log via SM13.

Hope it helps.

[christian_wohlfahrt]

Hi,

you are mixing implicit and explicit commit works. An implicit commit does not trigger the update task, but it 'finalizes' the DB changes (in case you did some in a wrong place).

Have a look at the link about the <a href="http://help.sap.com/saphelp_erp2005vp/helpdata/en/41/7af4cea79e11d1950f0000e82de14a/frameset.htm">Asynchronous Update</a>!!

There is a nice picture, which explains how changes can be done on each screen without DB updates in a wrong place. And an implicit commit has something to do with the session handling of SAP, how work processes are occupied - there is nothing you can do about the behavior (maybe buying a different software

Regards,

Christian

[Former Member]

thanks guys..i read a few documents and this is how i understand it now....

take a transaction, now it is infact a program, this program tracks down the entries that the user makes in individual screens, wen the user navigates from 1st screen, the program variables have those values entered & if there s any databse operation then ( 1st screen itself, ie Update, insert, etc ), then the databse LUW will commit that operation...but wat we do is, never use these update operations midway in a transactrion, but store all of them in some internal table(buffer) and finally put these operations in some FM with Update Task or Perform ON Commit...so these operations will get triggered only wen the program comes across an explicit COMMIT WORK statement ( doesnt implicit commit trigger these FMs ?? )..

so basically, wen we r not using any databse operations withina screen, then the implicit commit actually doesnt signify anything as there is nothing to be updated into the database...

m i going in the right direction ???

appreciate ur responses guys...

[Former Member]

Hi again,

1. i going in the right direction ???

PERFECT UNDERSTANDING !

2. The same thing

i had written earlier in my reply,

but probably, it was not well presented

as your reply !

3. Just to recapitulate,

i have written once again

6. the technique used is

<b>a) do not save using sql at each screen</b>

b) just collect all entered data

in internal tables

c) after all proper entry, when the user presses SAVE button,

d) pass all this internal table data

to a SINGLE FM, (which is of normal type, or update type)

e) This FM will pass the SQLS,

to actually update the tables.

f) THIS BUNCHING IS CARRIED OUT IN THIS FASHION.

regards,

amit m.