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

Commit and Rollback

Former Member
0 Likes
3,032

Hi all,

I am facing this problem. I am writing a custom report working on several custom tables. I cannot update all tables with one query, so I have to do it in sequence. Operation are:

1) function to get a number from numeration

2) custom table A update

3) function to get a number from numeration obj 1

4) custom table B update

5) function to get a number from numeration obj 2

6) custom table C update

7) function to get a number from numeration obj 3

😎 custom table D update

9) function to get a number from numeration obj 4

10) custom table E update

11) BAPI to create sales order

But one operation can fail, and what I would like to do, is to rollback on updated table until error. I thought that simply writing

ROLLBACK WORK

all operations on custom table would be rolled back, but it not happens.

Note that bapi to create salesorder is called as follows:

CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT1'
    EXPORTING
      order_header_in = order_header_in
      without_commit  = 'X'
...

Am i missing or misunderstanding something in use of rollback work statement ?

thanks for the help

regards

Gabriele

1 ACCEPTED SOLUTION
Read only

arseni_gallardo
Active Participant
0 Likes
2,037

Gabriele,

You should take into account that certain operation lead to an implicit database commit (an information message, for example). Please check that your code before the BAPI does not do any of the following. It would also be a good idea to check if there is any user exit o BAdI implementation in the sales order creation that is doing an explicit COMMIT.

    • Implicit Database Commits

The implicit database commits in an ABAP system are caused by the fact that the SAP system is logged on to the database system via its work processes. A work process can only ever execute a single database LUW but cannot interfere with the database LUWs belonging to other work processes. Since an ABAP program can be executed by different work processes during its runtime, the database LUW for the current work process must be completed each time an action takes place that leads to a change of work process. As a result, a database commit is performed implicitly in the following situation:

*Completion of a dialog step

The program waits for a user action and does not occupy a work process during this time. The next free work process is assigned to the program in the next dialog step.

*Calling a function module in a synchronous or asynchronous Remote Function Call

The current work process hands over control to a different work process or system.

*Completion of a function module accessed with a synchronous Remote Function Call in a separate work process

The calling program is assigned a new work process.

*Execution of a RECEIVE statement in a callback routine specified in an asynchronous RFC

The current work process is interrupted so that the data can be received from the other application server.

*Interruption of the current work process with a WAIT statement.

After interruption, the program is assigned the next free work process.

*Sending error and information messages and warnings.

These messages interrupt the current dialog step (see above).

6 REPLIES 6
Read only

Former Member
0 Likes
2,037

Hi

I've tried this simple code:

<ZTABLE> = ......

INSERT <ZTABLE>.

ROLLBACK WORK.

It works fine, if I try to see the new record by SE16, I can't see it

You should check what's in fm to get the number, perhaps they do a COMMIT

Max

Read only

arseni_gallardo
Active Participant
0 Likes
2,038

Gabriele,

You should take into account that certain operation lead to an implicit database commit (an information message, for example). Please check that your code before the BAPI does not do any of the following. It would also be a good idea to check if there is any user exit o BAdI implementation in the sales order creation that is doing an explicit COMMIT.

    • Implicit Database Commits

The implicit database commits in an ABAP system are caused by the fact that the SAP system is logged on to the database system via its work processes. A work process can only ever execute a single database LUW but cannot interfere with the database LUWs belonging to other work processes. Since an ABAP program can be executed by different work processes during its runtime, the database LUW for the current work process must be completed each time an action takes place that leads to a change of work process. As a result, a database commit is performed implicitly in the following situation:

*Completion of a dialog step

The program waits for a user action and does not occupy a work process during this time. The next free work process is assigned to the program in the next dialog step.

*Calling a function module in a synchronous or asynchronous Remote Function Call

The current work process hands over control to a different work process or system.

*Completion of a function module accessed with a synchronous Remote Function Call in a separate work process

The calling program is assigned a new work process.

*Execution of a RECEIVE statement in a callback routine specified in an asynchronous RFC

The current work process is interrupted so that the data can be received from the other application server.

*Interruption of the current work process with a WAIT statement.

After interruption, the program is assigned the next free work process.

*Sending error and information messages and warnings.

These messages interrupt the current dialog step (see above).

Read only

0 Likes
2,037

thank you

the problem was the message: when I got problems, I warned user and then rolled back. Now first rollback and after warn user.

thank you very much

regards

Gabriele

Read only

0 Likes
2,037

You can try putting your logic in a form or function module.

call the function module in update task.

or call the form as perform FORMNAME on commit.

Assuming there is no internal commit work triggered at any point until the end.

Read only

Former Member
0 Likes
2,037

Gabriele,

If you have checked that you are not using an explicit commit and still entries are getting saved in database, which means an implicit commit is happening, it is better to manually Delete the entries of the prior operations in case of any error since they are only custom tables.

Also, do check that is it a prerequisite for you in your function calls or BAPI to have such entries in database tables ? If not, why not play only with internal tables and do the database updates only after the successful bapi call.

Regards,

Diwakar

Read only

Subhankar
Active Contributor
0 Likes
2,037

SAP provided the statement IN UPDATE TASK or perform XXXX on commit to avoid this issue.

Better to create one custom function module and write the code to update the tables. Note here do not put any commit work and rollback work statement. then call the FM in IN UPDATE TASK.

I will suggest to check the F1 help for IN UPDATE TASK then you will get the idea of database LUW and SAP LUW.

thanks

Subhankar