Is 'Commit Work' statement necessary?

Is it mandatory to issue 'Commit Work' statement to terminate the program in SAP LUW? If not provided would the program go into infinite loop?

... just before the thread gets locked:
There is no such thing as an implicit commit work. The implicit commit is a database commit, that means after every process interruption as i.e. processing of any screen and the end of program execution all database activities are committed, they can not be rolled back.
The explicit ABAP statement COMMIT WORK will termiante the current LUW and, additionally start execution of all asynchronous database operations (Call function in update task), start all PERFORM ON COMMIT routines.
Most BAPI calls need a subsequent COMMIT WORK, better issued by function Call BAPI_TRANSACTION_COMMIT.
The documentation has more information. One major truth is: In 'simple' programs that do some INSERTS, UPDATES and MODYFYs on database tables, you do not need any COMMIT WORK. And if screen processing happens afterwards, you can not ROLL BACK.
Regards,
Clemens

Similar Messages

Commit work statement creating problem in CALL TRANSACTION

Hi Friends,
we are facing a problem where we need to call a standard program from a Zprogram.
we have tried the following ways.
1. Using SUBMIT statement , we are sending the parameters to the standard program, but when the standard program gives a
    dump our program cannot process further records. we are calling the submit statment in a loop. As because the standard
    program is giving dump our program is not able to process the next record in the loop and this should not be the case.
    To avoid this we have used the second method.
2. we used a CALL transaction, we have created a Tcode for the standard program and called this transaction in the calling
    program. We are passing the parameters for the standard program via BDC table. this works fine even when the standard
    program gives a dump but when ever the control   comes across a Commit work statement the the control comes back to our
   calling program with out executing the rest of the   statments after the commit.
now our concern is even though there is an commit work statement , statements after the commit work should also get executed in call transaction. Is thee any way?
Regards,
Sravan

Hi All,
I got the solution
DATA: ctu_parameters TYPE ctu_params.
ctu_parameters-dismode = 'E'.
ctu_parameters-updmode = 'A'.
ctu_parameters-racommit = 'X'. "No abortion by COMMIT WORK
CALL TRANSACTION USING itab_bdcdata OPTIONS FROM ctu_parameters.
the above code will work even if there is an commit work . This might help some others.

Need help: Sending mail to internet address without commit work statement

Dear Experts,
        I have a problem in sending mails from sap to internet address.Am using the function module
SO_NEW_DOCUMENT_SEND_API1 and am passing parameters like,
CALL FUNCTION 'SO_NEW_DOCUMENT_SEND_API1'
     EXPORTING
          DOCUMENT_TYPE = 'RAW'
          DOCUMENT_DATA = DOC_CHNG
          PUT_IN_OUTBOX = 'X'
     TABLES
          OBJECT_CONTENT = OBJCONT
          RECEIVERS      = RECLIST
     EXCEPTIONS
          TOO_MANY_RECEIVERS         = 1
          DOCUMENT_NOT_SENT          = 2
          OPERATION_NO_AUTHORIZATION = 4
          OTHERS                     = 99.
submit rsconn01 with mode = 'INT'
                    with output = 'X'
                    and return.
My problem here is,with the commit work statement after FM, the mail is triggering correctly.but if, am not using the commit work statement,at the very first time of execution mail is not triggering, and the second time of execution first mail is triggering like wise it is going.The status of the message is waiting in queue.
i have refresh receiver's list also.I want to use this concept in badi.So anyone can pls help me,how to send a mail without commit work statement.
Thanks in advance.

There is a parameter Commit_Work pass it as 'X'
<code>
CALL FUNCTION 'SO_NEW_DOCUMENT_SEND_API1'
EXPORTING
DOCUMENT_TYPE = 'RAW'
DOCUMENT_DATA = DOC_CHNG
PUT_IN_OUTBOX = 'X'
commit_work = 'X'
TABLES
OBJECT_CONTENT = OBJCONT
RECEIVERS = RECLIST
EXCEPTIONS
TOO_MANY_RECEIVERS = 1
DOCUMENT_NOT_SENT = 2
OPERATION_NO_AUTHORIZATION = 4
OTHERS = 99.
submit rsconn01 with mode = 'INT'
with output = 'X'
and return.
</code>
Edited by: Saravanan Ramasamy on Nov 11, 2009 1:31 PM

How to count " How many times the ' commit work ' Statement is executed.

Hi all sap Champions,
One of the client requirement, That is
How to count " How many times the ' commit work ' Statement is executed.
It's urgent.
Please can anybody help me for this.
Thanks
Basu

hi,
when report try like this.
declare a variable as
data: counter type i value 0.
COMMIT.
counter = counter + 1.
write:/10 counter 'NO. OF TIMES COMMIT WORKED'.

Commit work in FQevents in FICA(PERFORM commitroutine ON COMMIT )

Hello Experts,
i am trying to create an event to trigger a workflow using function module swe_event_create.
i am doing this in an FICA event 5500 after triggering this workflow i need to stop the further processing so i am using Error message statement.
when i am calling swe_event_create without commit work the event is not getting triggered .
when i checked the documentation of this event it was written that
To ensure the consistency of the system, note that you must not use the following language elements in events:
COMMIT WORK
ROLLBACK WORK
CALL FUNCTION 'DEQUEUE ALL'
Deletion of locks that you have not set yourself.
If you update additional data in an event and use the construction PERFORM commitroutine ON COMMIT to do this, note that:
At the end of the commitroutine, all internal tables from which data was updated must be initialized again to prevent a duplicate update in the next call.
A PERFORM rollbacktroutine ON ROLLBACK must also be called. In the rollbackroutine initialize the same data that is initialized at the end of the commitroutine.
If you want to carry out checks in an event, when you issue messages, note that background processing of the process terminates with warning messages. You should therefore avoid issuing warning messages if possible. However, you should definitely issue warning messages if the value of SY-BATCH is initial.
how i can use PERFORM commitroutine ON COMMIT could you please paste the code for this
also plz tell me
why my event is not getting generated without commit work . do we have any better way to do it

Hi Anit,
The FM SWE_EVENT_CREATE does its job, only when 'COMMIT WORK' is executed, after it. Now, as per the general programming guidelines (quoted in your question), you can't write COMMIT WORK in your code. You shouldn't, because it would write half baked document into database. Something that's undesirable. The workaround prescribed in the event documentation (again, as quoted in your question) allows to achieve the goal in following manner-
1. Do all calculations in your event and put the final values - that are necessary for the workflow - in global variables. Refer to the ABAP documentation for PERFORM ... ON COMMIT for choosing global variables over parameter passing.
2. Once that's done, make the call to the FM, as given below-
PERFORM start_wf ON COMMIT.   "Within the FM implementing the event 5500.
*&      Form start_wf
*       The form routine to initiate the workflow
FORM start_wf.
CALL FUNCTION 'SWE_EVENT_CREATE'
    EXPORTING
      objtype           = objtype
      objkey            = objkey
      event             = event
    TABLES
      event_container   = event_container
    EXCEPTIONS
      objtype_not_found = 1
      OTHERS            = 2.
IF sy-subrc <> 0.
    RETURN.
ENDIF.
CLEAR: objtype.
CLEAR: objkey.
CLEAR: event.
CLEAR: event_container.
"And all other global variables that are used in your call for this FM
ENDFORM.                    "start_wf
3. Note that you need to clean up the global variable set up in step 1 (also mentioned in the event documentation) . It is to ensure that some other call to the same FM doesn't use those values.
You needn't issue a COMMIT WORK statement anywhere in your code written in event 5500 implementation. The standard FMs, that update the SAP tables with document information have COMMIT WORK in them. As you have registered the FM 'start_wf' by PERFORM ... ON COMMIT, it would be executed along with the database update triggered by standard FM.

ABAP Dump on "COMMIT WORK"

The abap dump is occured in function module when the COMMIT WORK statement is executed.
This function module updates a custom table.
When creating a invoice through VF01 transaction this abap dump is occured.
But for the next time the invoice is created successfully.
What is the reason behind this.

Hi,
Refer
https://forums.sdn.sap.com/click.jspa?searchID=11053241&messageID=5085300
Regards
Kiran Sure

COMMIT WORK - performance problem

Dear Fellow SDNers,
I seek your help on the following problem:
Scenario : Inbound idoc which updates an Outbound delivery with Picked quantity, posts the goods issue and then creates billing document
Approach : I am using the function module SD_DELIVERY_UPDATE_PICKING to update the delivery from the idoc data and to post goods issue. Thereafter, i use BAPI_BILLINGDOC_CREATEMULTIPLE to create the billing document. Before calling this BAPI, I use a COMMIT WORK statement to update the relevant tables so as to enable invoice creation properly.
Problem: The COMMIT WORK statement takes a lot of time to execute (I have no update tasks that could lead to this), so much that the idoc (probably) has a timeout and ends up in status 64. As a result, the succeeding part of the code (after COMMIT WORK) is not executed and the billing document is not created.
When I debug this, the COMMIT WORK statement leads to a strange screen (which looks like a blank report output screen, with its title as "UPDATE CONTROL". However (of course), there is no timeout while debugging and the billing document is successfully created.
Could anyone provide some pointers to solve this problem?
regards,
Priyank

i have a custom function module Y_IDOC_INPUT_WMSPICK001 which is responsible for idoc inbound processing. SAP PI sends the inbound data to ECC and once this is done, this function module is executed.
This FM has the following code sequence inside it...
1) Call the FM SD_DELIVERY_UPDATE_PICKING
2) COMMIT WORK AND WAIT.
3) Call the BAPI_BILLINGDOC_CREATEMULTIPLE
Step1 is successfully executed, the step 2 takes a long time, and after that, the step 3 is not executed at all and the idoc ends up with a yellow light (status 64).
hope it clarifies what I am doing
regards,
Priyank

Commit Work in MIGO BADI

Hi,
Can we use COMMIT WORK statement in BADI? Hope its not advisable to use it.
I am using MB_MIGO_BADI~POST_DOCUMENT to update the GR Number in a custom table.
Sometimes the GR number is not getting updated in the custom table.
The modify statement given below does not updates the table sometime.
IF WA_ZMM_GATE_ENTRY-GR_NUMBER IS INITIAL.
      WA_ZMM_GATE_ENTRY-REFERENCE = GS_EXDATA_HEADER-REFERENCE.
      WA_ZMM_GATE_ENTRY-REFWERKS = GS_EXDATA_HEADER-WERKS.
      WA_ZMM_GATE_ENTRY-GR_NUMBER = IS_MKPF-MBLNR.
     WA_ZMM_GATE_ENTRY-GR_YEAR   = IS_MKPF-MJAHR.
     MODIFY ZMM_GATE_ENTRY FROM WA_ZMM_GATE_ENTRY .u201Dupdating the Z-table
ELSE.
      MESSAGE E901(ZMM) WITH GS_EXDATA_HEADER-GATEENTRYNO WA_ZMM_GATE_ENTRY-GR_NUMBER.
    ENDIF.
Is there any other option to replace the commit work in BADI?
Plz suggest...
Regards,
P.S.Chitra
Edited by: Chitra Karthik on Aug 10, 2010 11:19 AM

Hi,
I don't think even you do commit work it makes much difference and also Commit work also we can eliminate in the code.one more option is selecting the data from table to check whether it is updated or not.
IF WA_ZMM_GATE_ENTRY-GR_NUMBER IS INITIAL.
      WA_ZMM_GATE_ENTRY-REFERENCE = GS_EXDATA_HEADER-REFERENCE.
      WA_ZMM_GATE_ENTRY-REFWERKS = GS_EXDATA_HEADER-WERKS.
      WA_ZMM_GATE_ENTRY-GR_NUMBER = IS_MKPF-MBLNR.
     WA_ZMM_GATE_ENTRY-GR_YEAR   = IS_MKPF-MJAHR.
     MODIFY ZMM_GATE_ENTRY FROM WA_ZMM_GATE_ENTRY .u201Dupdating the Z-table
IF sy-subrc eq 0.
do.
select gr_number from ZMM_GATE_ENTRY where reference = GS_EXDATA_HEADER-REFERENCE.
if sy-subrc eq 0 and if gr_number is not initial. (record Found)-> means updated.
exit.
else.
MODIFY ZMM_GATE_ENTRY FROM WA_ZMM_GATE_ENTRY.
endif.
enddo.
endif.
ELSE.
      MESSAGE E901(ZMM) WITH GS_EXDATA_HEADER-GATEENTRYNO WA_ZMM_GATE_ENTRY-GR_NUMBER.
    ENDIF.
Regards,
Nagaraj

COMMIT WORK: Timing of DB commit and update modules

Hi all,
Does anyone know categorically the order of starting the asynchronous update modules (CALL FUNCTION ... IN UPDATE TASK) and the database commit, when a COMMIT WORK is done?
Does COMMIT WORK:
- Do PERFORM ... ON COMMIT
- Start asynchronous update processing
- Do database commit
Or does it:
- Do PERFORM ... ON COMMIT
- Do database commit
- Start asynchronous update processing
My reason for asking is some code (not written by me!) that essentially raises CREATED workflow events in the update task, but performs the corresponding database inserts in the current work process.
It looks like we are getting the situation that sometimes the table entries do not exist when the update modules exist, which in turn suggests to me that perhaps the asynchronous update modules are started just before the database commit that is done when a COMMIT WORK statement is executed.
Cheers,
Scott

Christian,
Before the update module execution. Here's some code to highlight and let's assume it runs in a dialog process. And to everyone else, yes, I know this is a poor way to implement updates!
INSERT INTO zmyobject VALUES lv_myobject.
CALL FUNCTION 'SWE_EVENT_CREATE_IN_UPD_TASK'
IN UPDATE TASK
EXPORTING
    objtype = 'ZMYOBJECT'
    objkey = lv_myobject-key
    event   = 'CREATED'.
COMMIT WORK.
So I meant to ask the question of whether we could guarantee that the new record in table ZMYOBJECT would be committed to the database <i>before</i> the update module was executed. It really is a theoretical question though it did not begin as one.
I do not believe the answer to this problem can be determined by debugging, because given that these two steps occur so close in time to one another, by the time the update module appeared in the debugger, it would be unrealistic to expect that the DB insert performed in the dialog process had not been committed yet.
I might be wrong, but I really don't think you're going to find ABAP logic embedded in SAPMSSY0 or elsewhere that invokes the update modules or performs a DB commit. Rather, it is my suspicion that the COMMIT WORK statement works like this:
- Drop into the kernel
- Does a callback to SAPMSSY0 to execute form %_BEFORE_COMMIT to raise a static OO event
- Does a callback to SAPMSSY0 to execute form %_COMMIT and thereby process any PERFORM ... ON COMMIT
- Does a database commit
- Does a callback to SAPMSSY0 to execute form %_AFTER_COMMIT to raise another static OO event
Further, I believe that it is the database commit that now makes the queued CALL FUNCTION ... IN UPDATE TASK now visible in VBLOG to other processes.
Lastly, and this is of course wild speculation, I suspect that it is an update process running somewhere else that detects the new entries in VBLOG and grabs them for processing.
So, I'm kind of changing my position from earlier to state that I believe the COMMIT WORK statement does not directly trigger the update modules at all, rather it just does the database commit and this makes visible the pending update modules to the dispatcher / update work processes which probably grab the update LUW's on a first come first served basis.
At least, that is how I would design it :-).
Cheers,
Scott

Commit work issue inside userexit while triggering sender proxy

Dear All,
We have a situation where in, a sender proxy is triggered inside the Userexit of a transaction. When we try to execute the proxy in a test program, the XML message is not reaching XI unless a commit work statement is put immediately after Proxy call method. But this solution cannot be incorporated inside the Userexit as that will commit the whole transaction. Also there are number of other methods triggered inside the Userexit after the Proxy is triggered.
Kindly respond to the below queries:
1. Is there a Standard commit after a userexit is triggered? if yes, shall that solve the problem?
2. Is there any solution other than commit work statement?
Thanks in Advance,
Zafar Ali

Hi,
Any userexit is part of a standard SAP program, every Standard SAP program esp any transaction like VA01, MIRO, ME21n etc will certainly have a commit work at the end of the transaction. or there will be a implicit commit work after a dialog step.
So when that commit work is executed, the proxy call wil be sent for sure.
So it will work if you don't put commit work in the userexit immediately after the proxy call.
regards,
Advait.

BAPI_REQUISITION_CREATE Problem with COMMIT WORK AND WAIT

I ran into an issue and wanted to get your opinions about what might be happening.
This is my original code that did not work correctly using COMMIT WORK AND WAIT. After the select statement, lv_count was zero even though there were PR items that had been created. I'm thinking that the database update was not complete, but why would that be?
    CALL FUNCTION 'BAPI_REQUISITION_CREATE'
      IMPORTING
        number            = lv_number
      TABLES
        requisition_items = gt_reqitem
        return            = gt_return.
*   Purchase requisition has been created
    IF lv_number IS NOT INITIAL.
      COMMIT WORK AND WAIT.
*     Get number of items in PR
      SELECT COUNT( DISTINCT bnfpo ) INTO lv_count
        FROM eban
        WHERE banfn = lv_number.
This is my corrected code that works. I removed the AND WAIT from the commit statement and added a separate wait statement. I now get the correct number of PR items that were created.
    CALL FUNCTION 'BAPI_REQUISITION_CREATE'
      IMPORTING
        number            = lv_number
      TABLES
        requisition_items = gt_reqitem
        return            = gt_return.
*   Purchase requisition has been created
    IF lv_number IS NOT INITIAL.
      COMMIT WORK.
      WAIT UP TO 1 SECONDS.
*     Get number of items in PR
      SELECT COUNT( DISTINCT bnfpo ) INTO lv_count
        FROM eban
        WHERE banfn = lv_number.
Any ideas?
Brenda

Brenda Bankert wrote:
Yes, I was able to see the message in RETURN and no, I am not calling the FM in a loop. My program calls it one time.
> Brenda
If you were able to see the message 'Purchase requisition number & created' it means that the macro macro_end is getting executed within which the COMMIT WORK statement is encapsulated.
I have quickly developed a dirty program to test the behaviour of 'SET UPDATE TASK LOCAL' and it seems to work as expected.
Everytime I executed the below program with 'SET UPDATE TASK LOCAL', I see the value of lv_count as 1000, however if I execute the below program with out the statement 'SET UPDATE TASK LOCAL' the value of count varies everytime, typically around 10 - 15, however the database is successfully updated with all the 1000 entries, this makes me believe that the 'SET UPDATE TASK LOCAL' statement will infact make the subsequent COMMIT synchronous.
REPORT zytest.
DATA:
ls_zytest    TYPE zytest,
ls_db_zytest TYPE zytest,
lv_numc04    TYPE numc4 VALUE 1001,
lv_count     TYPE i,
lv_index     TYPE i.
DO 1000 TIMES.
lv_index = sy-index.
CLEAR ls_zytest.
lv_numc04 = lv_numc04 + 1.
CONCATENATE 'KF00' lv_numc04 INTO ls_zytest-keyfield1.
CONCATENATE 'KF00' lv_numc04 INTO ls_zytest-keyfield2.
SET UPDATE TASK LOCAL.
CALL FUNCTION 'ZYTEST_BAPI'
    EXPORTING
      is_zytest = ls_zytest.
SELECT SINGLE * FROM zytest INTO ls_db_zytest WHERE keyfield1 = ls_zytest-keyfield1
                                                  AND keyfield2 = ls_zytest-keyfield2.
IF sy-subrc IS INITIAL.
    WRITE:/ lv_index, ls_db_zytest-keyfield1,ls_db_zytest-keyfield2.
    lv_count = lv_count + 1.
ENDIF.
ENDDO.
WRITE:/ lv_count.
FUNCTION zytest_bapi .
*"*"Local Interface:
*" IMPORTING
*"     REFERENCE(IS_ZYTEST) TYPE ZYTEST
DATA: transaction_id LIKE arfctid.
clear transaction_id.
macro_start.
CALL FUNCTION 'ZYTEST_UPDATE' IN UPDATE TASK
    EXPORTING
      is_zytest = is_zytest.
macro_end.
ENDFUNCTION.
FUNCTION ZYTEST_UPDATE.
*"*"Update Function Module:
*"*"Local Interface:
*" IMPORTING
*"     VALUE(IS_ZYTEST) TYPE ZYTEST
INSERT zytest from is_zytest.
ENDFUNCTION.
definition of the database table 'ZYTEST'
MANDT     MANDT
KEYFIELD1     CHAR20
KEYFIELD2     CHAR20
NONKEYFIELD     CHAR50
-Rajesh

COMMIT WORK AND WAIT USE

Hi Friends,
what is mean by COMMIT WORK AND WAIT.
when we use ths syntax...??
situation pls.
regards,
venu.

Hi,
To apply the changes made to the runtime objects of persistent classes to the actual persistent objects in the database, execute the COMMIT WORK statement. (Alternatively, use COMMIT WORK AND WAIT or SET UPDATE TASK LOCAL). Unless you are executing an object-oriented transaction from within the Transaction Service, you must include the COMMIT WORK statement explicitly in the program. Otherwise, it is encapsulated in the Transaction Service. (If you explicitly include the COMMIT WORK statement as described here, the t op-level transaction runs in compatibility mode).
The function of the COMMIT WORK statement is extended when you use it in conjunction with Object Services. Before COMMIT WORK closes the SAP LUW and triggers an update, it calls internal methods of the Persistence Service. These methods bundle the changes made to managed objects of the Persistence Service and pass them to a special update function module using CALL FUNCTION ... IN UPDATE TASK. Thus the Persistence Service works with traditional update methods. The update module is usually registered after any update modules that have already been registered. The update is then triggered and the update task executes the update module in the order in which they were registered.
After the system executes the COMMIT WORK statement, it sets the attributes of each persistent object in the ABAP program to initial. (That is, it calls the IF_OS_STATE~INVALIDATE method).
Local Update
If you want to change managed objects directly, rather than using the update module, you must change the update mode of the implicitly used Transaction Service. That is, the following statements must be executed before the COMMIT WORK statement:
DATA TM type ref to IF_OS_TRANSACTION_MANAGER.
DATA T type ref to IF_OS_TRANSACTION.
TM = CL_OS_SYSTEM=>GET_TRANSACTION_MANAGER( ).
T = TM->GET_CURRENT_TRANSACTION( ).
T->SET_MODE_UPDATE( OSCON_DMODE_DIRECT ).
COMMIT WORK.
To ensure database consistency, the local update is activated internally using SET UPDATE TASK LOCAL. In such cases, the system raises an exception if there are already update modules registered in the update task. You can only register additional classical update modules after setting the mode. They will then also be updated locally.
COMMIT
Basic form
COMMIT WORK.
Addition
... AND WAIT
Effect
Executes a database commit and thus closes a logical processing unit or Logical Unit of Work ( LUW ) (see also Transaction processing ). This means that
all database changes are made irrevocable and cannot be reversed with ROLLBACK WORK and
all database locks are released.
COMMIT WORK also
calls the subroutines specified by PERFORM ... ON COMMIT ,
executes asynchronously any update requests (see CALL FUNCTION ... IN UPDATE TASK ) specified in these subroutines or started just before,
processes the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK ,
cancels all existing locks (see SAP locking concept ) if no update requests exist,
closes all open database cursors (see OPEN CURSOR ) and
resets the time slice counter to 0.
COMMIT WORK belongs to the Open SQL command set.
Return code value
The SY-SUBRC is set to 0.
Notes
All subroutines called with PERFORM ... ON COMMIT are processed in the LUW concluded by the COMMIT WORK command. All V1 update requests specified in CALL FUNCTION ... IN UPDATE TASK are also executed in one LUW . When all V1 update requests have been successfully concluded, the V2 update requests ("update with start delayed") are processed, each in one LUW . Parallel to this, the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK are each executed in one LUW per destination.
COMMIT WORK commands processed within CALL DIALOG processing
- execute a database commit (see above),
- close all open database cursors,
- reset the time slice counter and
- call the function modules specified by CALL FUNCTION IN
BACKGROUND TASK in the CALL DIALOG processing.
However, subroutines and function modules called with PERFORM ... ON COMMIT or CALL FUNCTION ... IN UPDATE TASK in the CALL DIALOG processing are not executed in the calling transaction until a COMMIT WORK occurs.
Since COMMIT WORK closes all open database cursors, any attempt to continue a SELECT loop after a COMMIT WORK results in a runtime error. For the same reason, a FETCH after a COMMIT WORK on the now closed cursors also produces a runtime error. You must therefore ensure that any open cursors are no longer used after the COMMIT WORK .
With batch input and CALL TRANSACTION ... USING , COMMIT WORK successfully concludes the processing.
Addition
... AND WAIT
Effect
The addition ... AND WAIT makes the program wait until the type V1 updates have been completed.
The return code value is set as follows:
SY-SUBRC = 0 The update was successfully performed.
SY-SUBRC <> 0 The update could not be successfully performed.
Note
Runtime errors
COMMIT_IN_PERFORM_ON_COMMIT : COMMIT WORK is not allowed in a FORM callled with PERFORM ... ON COMMIT .
COMMIT_IN_POSTING : COMMIT WORK is not allowed in the update task.
if its useful reward points

Commit Work - LUW

We have a requirement where an output type triggers an form routine which in turn calls 'VL02N' transaction to create Handling Unit and PGI.
The output type does not allow to call these transactions, so we used call function method to call these transactions.
These call function method can either be called using background task or using destination parameters.
The problems that we occur using a queue is:
1. How to capture the exception?
2. Where commit work should be provided as output type form routine doesn't allow commit work statement also.
3. When to update IDOC status as all these transactions occur sequence in a queue.
But, when used as a queue, time delay occurs and we can't be certain when the complete process of HU and PGI will occur.
Is there any other method apart from these to use call transactions.

Hi Krishnan,
As an alternative, what you can do is to have a Z table which is to be updated in the output processing form.
and have another stand alone program which is to be triggered after this, which reads the Z tables with the relevant information and call the transaction from there.

Doubt in COMMIT WORK

I have the below code, where the commit work is after the loop.
LOOP AT itab INTO str.
UPDATE dtab FROM str.
ENDLOOP.
COMMIT WORK.
As per my understanding an update work process will be created after the COMMIT WORK. Is this can be viewed in SM50 ?
In case the work process created is not processed and ON HOLD. If i try to update the dtab table again, is there is a possibility I can get a lock error since the last work process in not processed.
Regards,
Thanga

Hi Thanga,
If you are not using update task ( CALL FUNCTION IN UPDATE TASK ) / background tasks(CALL FUNCTION IN BACKGROUND TASK ), then commit work statement is optional. System will do implicit commit after the program ends. However to be on the safer side, you should explicitly code it.
https://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm
Please note that - If you are directly updating the table in your program without using update task, no entry exists in SM13- Monitor Update task.
Regards,
DPM

* Commit work on table using UPDATE statement.*

HI,
   This is Anil . I have problem regarding Commit work and Wait up to 2 seconds.
I am using Commit work on one Update table statement but it is not working . While doing debugging it is working
(means it is updating Table.) but while running the transaction directly it is not updating the table.
Check the statements :
Commit work.
Some Select stmt on <table>.
IF <condition.>
Update <table > statement.
if sy-subrc EQ 0.
    Commit work . ( This is not working while running transaction mean it is not updating table. While debuggint it it updating table.)
     wait up to 2 seconds.
endif.
endif.
Will that above Commit work causing any problem or what is the reason it is not updating table.
Please give some suggestion in this case.
Regards,
Anilreddy.

Hi
the below code with commit work is working finr for me.
only thing i suggest is to check sy-subrc value.
commit work.
update spfli set test = '1234' where carrid = 'AA'.
if sy-subrc eq 0.
commit work.
wait up to 2 seconds.
endif.
write: / sy-subrc.

Is 'Commit Work' statement necessary?

Similar Messages

Maybe you are looking for