Commit work sets sy-subrc 0

I
Commit work sets sy-subrc always to zero.
In this case how can we know if commit work fails.
Please provide more details and efficient usage of commit statements in a report

Hi,
Usage of commit statements is as follows:
COMMIT WORK.
Addition
u2026 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 u2026 ON COMMIT ,
executes asynchronously any update requests (see CALL FUNCTION u2026 IN UPDATE TASK ) specified in these subroutines or started just before,
processes the function modules specified in CALL FUNCTION u2026 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 u2026 ON COMMIT are processed in the LUW concluded by the COMMIT WORK command. All V1 update requests specified in CALL FUNCTION u2026 IN UPDATE TASK are also executed in one LUW . When all V1 update requests have been successfully concluded, the V2 update requests (u201Dupdate with start delayedu201D) are processed, each in one LUW . Parallel to this, the function modules specified in CALL FUNCTION u2026 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 u2026 ON COMMIT or CALL FUNCTION u2026 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 u2026 USING , COMMIT WORK successfully concludes the processing.
Addition
u2026 AND WAIT
Effect
The addition u2026 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 u2026 ON COMMIT .
COMMIT_IN_POSTING : COMMIT WORK is not allowed in the update task.
Hope it will help you.
Feel free to ask any doubt.
Regards
Aparna

Similar Messages

How can i set the IDOC Status to 03 without doing a "COMMIT WORK"

Hello Geeks,
I want to set the status of the Outgoing IDOC to 03 , without doing a "COMMIT WORK" . Actually only after i do a commit work are my IDOCs dispatched. But with a commit work the IDOCs are dispatched immidiately. I do not want to dispatch it immidiately. Instead i want to hol the IDOCs till my LUW finishes , but the IDOC status should be set to "03" instead of "30".
Thanks,
Bashir

Hi,
After collecting all the idocs which are under status 30, run the program RSEOUT00 to change the status from 30 to 03.
If you want to do this process automatically then set the program RSEOUT00 in background.
Regards,
Lokeswari.

How to execute Update Module FM after final commit work for a T-code.

Hello Folks,
I have a bit complex issue with my current object.
We have modified MM41/MM42 transactions and added a subscreen to fulfill the requirement.
We have designed the subscreen and embedded the same to MM41/MM42 through SPRO configuration.
Now for update business logic,i am trying to execute one Function module(Update Module) in update Task...so that it will be executed once after the final commit work will be done for MM41/MM42.
But its not executing.
To fulfill my requirement i need to execute the FM only after Final Commit work for MM41/MM42.
Please suggest in this regard.
Even i can see few BADI's which are triggering through MM01/MM02 but not through MM41/MM42.
BADI_ARTICLE_REF_RT
BADI_MATERIAL_CHECK
BADI_MAT_F_SPEC_SEL
Code with which i am trying is given below.
After PAI event of the subscreen---
1:        MODULE USER_COMMAND_9001.
2:       MODULE user_command_9001 INPUT.
                    PERFORM sub_save_mara ON COMMIT.
          ENDMODULE.
3:       FORM sub_save_mara.
                     CALL FUNCTION 'ZMMUPDATE_MARA_APPEND_STRUCT' "IN UPDATE TASK
                                    EXPORTING
                                             materialno = gv_matnr
                                             appendmara = ty_zzmara.
         ENDFORM.                    "sub_save_mara
4:                FUNCTION zmmupdate_mara_append_struct.
                  ""Update Function Module:
                   ""Local Interface:
                  *" IMPORTING
               *"     VALUE(MATERIALNO) TYPE MATNR
               *"     VALUE(APPENDMARA) TYPE ZZMARA
Data Declaration for Local use
DATA : w_mara TYPE mara.
Selecting the latest values for the material.
SELECT SINGLE * FROM mara INTO w_mara WHERE matnr = materialno.
IF sy-subrc = 0.
Move the ZZMARA values to structure MARA
    MOVE-CORRESPONDING appendmara TO w_mara.
Update the values in table MARA.
    MODIFY mara FROM w_mara.
ENDIF.
ENDFUNCTION.
Kindly suggest.Thanks in advance.
Regards
Ansumesh

Hi..
The code given by me will work fine provided the Final commit should happen.
Because to execute FM with update task,final commit work should happen which is mandatory and after that it will call the update task.
In my case final commit work was not happeneing because..SAP standard program was not able to detect wether there is any change in my sub-screen or not as the standard program & my custom program,subscreens are different.
As it was not able to detect the change,so final commit was not happening and hence update task also.
To provide the reference of change in my subscreen to standard program ,i set a flag as per the change in the subscreen
And exported the same to memory.
Then Implemented one enhacement spot in MATERIAL_CHANGE_CHECK_RETAIL Fm where i have Imported the flag value.
Based on my custom flag value,i have set one standard flag FLG_AENDERUNG_GES which tells SAP standard program for MM42 wether any change has happened or not.
The above solved my purpose.
Regards
Ansumesh

Lock and Commit work in INBOUND IDOC

Hi Experts,
Problem is about lock and commit work
i need to receive idoc for Good receipt for purchase order.
For one Purchase Order i can receive many good receipt Idoc at the same time and when first came in Lock the Purchase Order and further idoc came after give Errors becouse purchase Order is lock.
Problem is not the serialization (the sequence is correct), but is the lock.
Any idea on how to fix this issue? (maybe there is some std settings??)
Cheers
Boris

Hello Guys
the packetsize is already set to 1 but the problem still again..... and where i can find this setting   "in Customizing choose Engineering Change Management ® Define statuses for master record". ?
Any way i try in function module in inbound to check the lock object with this sample code:
      DO 30 TIMES.
        CALL FUNCTION 'ENQUEUE_EMEKKOS'
         EXPORTING
           mode_ekko            = 'S'
           mandt                = sy-mandt
           ebeln                = goodsmvt_item-po_number
           _scope               = '2'
         EXCEPTIONS
           foreign_lock         = 1
           system_failure       = 2
           OTHERS               = 3.
        IF sy-subrc <> 0.
          WAIT UP TO 1 SECONDS.
        ELSE.
          EXIT.
        ENDIF.
      ENDDO.
but also with this....problem syill again...
thanks
Boris

COMMIT WORK and WAIT FOR n SECONDS

I am designing a WebDynpro Java application. It makes an update call followed immediately by a display call which should return the data that was just updated. However, it appears that there is some DB latency involved and the data takes a few seconds to update. The application displays old data if the display call is performed too quickly after the update call.
All suggestions I could find point to having a Thread sleep on the Java side for a few seconds or have a WAIT FOR n SECONDS and/or COMMIT WORK AND WAIT statement in the ABAP function module. Neither of these solutions is acceptable in a company-wide application where database latency could vary significantly based on traffic.
I tried all kinds of functions (i.e. BAPI_TRANSACTION_COMMIT) as well as various forms of COMMIT WORK... nothing except a WAIT works correctly. There must be a statement out there that waits for the database write to be complete! How is this solved without picking an arbitrary WAIT time? What am I missing?
Thanks in advance!

You can write the other way.
declare one variable
data : wa_try type i.
wa_try = 10. -> set as 10 ,even you do not get value ,keep on incresing.
after BAPI FM
you can call comitt fm.
after BAPI_TRANSACTION_COMITT
just use simple logic.
do wa_try.
select * from table into table
where record = bapi fm record ( You get in RET2 Message).
if sy-subrc eq 0.
exit.
endif.
Thanks
Seshu

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.

* 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.

Differences between Commit work, Logical Unit of Work and Roll back work

Hi all,
Can any one explain me in details what is the difference between Commit Work, Logical Unit of Work and Roll back work. Pls explain by providing some example.
and also explain me where and when these are used and what are the importance of using these.
Thanks in advance.
Regards
Ramana Prasad.T

Hi Ramana Prasad,
A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirety or not at all. For the database system, it thus constitutes a unit.
LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.
An LUW begins
o each time you start a transaction
o when the database changes of the previous LUW have been confirmed (database
commit) or
o when the database changes of the previous LUW have been cancelled (database rollback)
An LUW ends
o when the database changes have been confirmed (database commit) or
o when the database changes have been canceled (database rollback)
COMMIT WORK.
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.
ROLLBACK WORK.
Closes a logical processing unit by reversing all database changes made since the last COMMIT .
You use this statement if you cannot be certain that all the database changes have been executed correctly.
The update routines are not performed.
ROLLBACK WORK belongs to the Open SQL command set.
Note
If the ROLLBACK statement occurs within a SELECT loop, the processing cannot continue because the database cursor is invalid. After the ROLLBACK statement, you should therefore ensure that all SELECT processing has been explicitly terminated.
<b>Plz. Avoid Duplicate Threads.</b>
Hope this resolves your query.
Reward all the helpful answers.
Regards

Since release 5.0 : commit work in ZXPADU02 is not working !

Hello everybody,
I try to send documents in FM ZXPADU02 following bcs_example, but the commit work has no effect. I set it like this
CALL METHOD send_request->send(
              EXPORTING
                i_with_error_screen = 'X'
              RECEIVING
                result              = sent_to_all ).
            commit work.
This sentence was working till 4.6c, but since we migrate to 5.0, the commit work is no more working. Sending documents via smartforms (in the same user exit) works because instead of using commit work, we set bcs_commit = 'X' in output-options.
We have no problem with commit work in normal reports, but I think that used in a user exit, the behavior has been changed since we are on ERP2004.
Any idea ?
Jean-Paul

Hello,
Of course, the code is activ, the sendmail is a very small part of it. I try to put many things with commit work (also commit work and wait). I set it almost ... everywhere include in the standard program SAPFP50M just after the CALL CUSTOMER-FUNCTION '002', no result. Nothing is done and when debugging sy-subrc is always at 0 after the commit.
Regards.
jp

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

Exception triggering Commit work.

Hi ,
I need to update a seris of tables and they must be transactional, i.e. all the data must be updated or not.
I have the following code.
*Fetch and Update Reference Profile Data
me->process_rp_data( ).
*Fetch and Update Request Data
me->process_req_data( ).
*Fetch and Update Collateral Data
me->process_coll_data( ).
*Fetch and Update Project Data
me->process_project_data( ).
IF i_update_flag IS INITIAL.
    ROLLBACK WORK.
ELSE.
    COMMIT WORK.
ENDIF.
in all the above four methods there are update statements like below
TRY .
      UPDATE (i_table_name) SET bp_number = sur_bp WHERE (lt_dyn_cond).
      IF sy-subrc NE 0.
        me->raise_exception( EXPORTING i_text_id    = zcx_rms_dedupe_process_excptns=>error_in_update
                                       i_bp_num     = vic_bp
                                       i_guid       = i_guid
                                       i_table_name = i_table_name
                                       i_process    = i_process ).
      ENDIF.
    CATCH cx_sy_dynamic_osql_error.
      me->raise_exception( EXPORTING i_text_id    = zcx_rms_dedupe_process_excptns=>error_in_update
                                     i_bp_num     = vic_bp
                                     i_guid       = i_guid
                                     i_table_name = i_table_name
                                     i_process    = i_process ).
ENDTRY.
If in the third method, if the exception cx_sy_dynamic_osql_error is raised all the data that is updated in the first two methods are commited. Can any one help how to overcome this situtation. I do not want the data to be committed
Regards

Hi,
My main question is that the why Exception I am raising is triggering a database commit. I am not even displaing an information message. I am simply outputing a write statement
[DataBase Commit|http://help.sap.com/saphelp_nw70/helpdata/en/41/7af4bca79e11d1950f0000e82de14a/content.htm]
Gives more information on Database commit but it does not mention this case. So wanted to know my mistake.

Commit work functionality

Hello all,
can anyone explain me what is commit work mean.
Thanks & Regards
venkata prasad

Hello
Check this
Syntax Diagram
COMMIT
Basic form
COMMIT WORK.
Addition:
... AND WAIT
Effect
Executes a database commit and thus closes a Logical Unit of Work ( LUW) (see also Transaction Processing). This means that
all database updates 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,
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.
The return code 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 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 called with PERFORM ... ON COMMIT.
COMMIT_IN_POSTING: COMMIT WORK is not allowed in the update task.
Additional help
Making Database Changes Permanent
If useful reward.
Vasanth

CO54: Message is not sent to any destination: Commit Work is getting failed

Hello,
While processing the Messages from XFP to SAP Update is getting terminated due to the use of Commit Work. SAP Note 147467 - Update termination when sending process messages has been referred which is for 4.6C, but we are in ECC6.0.
While processing the message in second iteration Commit Work triggres and Update happens in the data base.
Following Issue is only concerned with Nested HUs
T-Code used CO54
Following are the analysis:
it looks like u201CCreate and Post a Physical Inventory Docu201D is failing in the initial processing because the inventory doc is created when the Transfer Order to the PSA (or the TO from the PSA) is not yet completed (quant is still locked somehow).
CO54, process message category=ZHU_CONS: HU to be consumed is a nested pallet (unpacking/ repacking and TOs to/from) and qty to consume is greater that HU qty in SAP (creation of a physical inventory doc is required).
1. The error occurs while clearing the inventory posting for the physical inventory document.
2. The surprising factor is the u201CProcess Messageu201D is not processed correctly for the first time.
3. Indeed it is successfully processed without any error if you do process it second time.
Error Log from C054 T-Code.
02.08.2010                                         Dynamic List Display                                                1
Type
Message text
LTxt
Message category: ZHU_CONS ---    Process message: 100000000000000621   "Send to All Destinations" Is Active
Message to be sent to destination:
ZHGI ZPP_0285_XFP_GOODSISSUE Individual Processing Is Active
=> Message will be sent to destination (check log for destination)
Message category: ZHU_CONS ---    Process message: 100000000000000621   "Send to All Destinations" Is Active
Message destination ZPP_0285_XFP_GOODSISSUE triggered COMMIT WORK
Input parameters OK, passed to source field structure
Step 0: Now checking if scenario with HU
Step 2: Scenario with HU, Now checking if HU nested
Step 3: HU nested, checking if HU in repack area
Step 4: HU not in repack area, moving it to repack area
HU moved to repack area, TO number 0000000873
Step 5: Depacking nested HU...
Nested HU depacked, HU pallet n°: 00176127111000461994
Steps 6-7: Moving back HUs to supply storage type / bin...
HU 00376127111000462001 moved back to original area with TO number 0000000875
Steps 6-7: Moving back HUs to supply storage type / bin...
No need to move back HU 00176127111000461994 (not in table LEIN)
Step 8: Checking if HU fully used and quantity matches HU system quantity
HU not fully used but picked quantity > HU quantity: inventory necessary
Step 9: Inventory needed, creating physical inventory document...
Physical inventory document 0000000126 created
Step 10: Adding weighted quantity on inventory document...
Weighted quantity entered in document 0000000126
Step 11: Posting rectification in inventory document 0000000126...
Physical inventory document 0000000126 rectified
Error: rectification for doc 0000000126 not updated in DB!
=> Destination ZHGI ZPP_0285_XFP_GOODSISSUE can currently not process the message
=> Message is not sent to any destination
The errors in SM13 for this contain the program SAPLZPP_0285_HUINV_ENH (creating/changing the HUM physical inventory doc). WM Function module L_LK01_VERARBEITEN is also involved.
From SM13, it displays the following piece of code in include LL03TF2M (read the LEIN table=Storage Units table):
WHEN CON_LK01_NACH.
       IF (LEIN-LGTYP = LK01-NLTYP AND
             LEIN-LGPLA = LK01-NLPLA) OR
              NOT P_LEDUM IS INITIAL.
       ELSE.
Das ist der Fall einer TA-Quittierung wo Von-Hu = Nach-HU ist und sofort die WA-Buchung erfolgt. Dann steht die HU noch auf dem Von-Platz, daher darf hier kein Fehler kommen, sondern es wird ein. Flag gesetzt, daß verhindert daß die LE fortgeschrieben wird.
         FLG_NO_LE_UPDATE = CON_X.
        MESSAGE A558 WITH P_LENUM.
       ENDIF.
Translation in English of the German text via Google:
"This is the case where confirmation of a TO source-HU = destination-HU, and now the WA (Good Issue?)- made book. Then, the HU is still on the From-space may therefore come here not a mistake, but it sets a flag that prevents that the LE is updated."
Thanks and Regards,
Prabhjot Singh
Edited by: Prabhjot Singh on Aug 2, 2010 4:39 PM

Hope you have carried out following things in Production ( Please refer to SAP help before actually doing it in production).
1. Transport the predefined characteristics from the SAP reference client (000) to your logon client.
2. Adopt Predefined Message Categories - In this step, you copy the process message categories supplied by SAP from internal tables as Customizing settings in your plants.

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 sets sy-subrc 0

Similar Messages

Maybe you are looking for