‎2011 Oct 10 2:00 PM
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
‎2011 Oct 10 2:51 PM
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).
‎2011 Oct 10 2:28 PM
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
‎2011 Oct 10 2:51 PM
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).
‎2011 Oct 11 9:56 AM
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
‎2011 Oct 10 6:50 PM
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.
‎2011 Oct 11 3:05 AM
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
‎2011 Oct 11 3:20 AM
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