Transaction se37 include any implicit commit work?

Hi guys,
I'm testing bapi_material_savedata in se37. the modification to material will be save into database. The sametime this bapi can be rollback in my testing program.
So I'm wondering does bapi have any commit work inside itself. or se37 has an implicit commit work for this bapi ?
I can share my testing code
DATA: ls_headdata2 TYPE bapimathead.
DATA: ls_plantdata TYPE bapi_marc,
      ls_plantdatax TYPE bapi_marcx,
      ls_return TYPE bapiret2,
      lt_return TYPE bapi_matreturn2 OCCURS 0.
ls_headdata2-material = 'WDAIREZHOU2010691'.
ls_headdata2-sales_view ='X'.
ls_plantdata-plant = 'DCX1'.
ls_plantdata-availcheck = 'KP'.
LS_plantdata-profit_ctr = 'DCX1-1000'.
ls_plantdataX-plant = 'DCX1'.
ls_plantdataX-availcheck = 'X'.
LS_plantdataX-profit_ctr = 'X'.
CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
EXPORTING
   headdata                    = ls_headdata2
   PLANTDATA                   = ls_plantdata
   PLANTDATAX                  = ls_plantdatax
IMPORTING
   RETURN                      = ls_return
TABLES
   RETURNMESSAGES              = lt_return[] .
ROLLBACK WORK.
Any ideas, welcome
thanks,
irene

Sorry, I haven't read you question carefully. I though that it's a standard question about how to commit data created by BAPI in SE37. You are right. Unfortunately, some BAPIs have COMMIT statement inside. As far as I remember your BAPI is this case. But if you want to be sure you can use new debugger to put break point on every COMMIT statement or use SE30 to get full stack trace.
Cheers

Similar Messages

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.

Do CIF BAdIs issue implicit COMMIT WORKS (for FM's called "in update task")

I am calling the CIF BAdI:
/SAPAPO/TR_TRANSFER.
In the PUSH_LANE_DATA method of this BAdI, I want to call a function module "in update task".
To trigger the actual execution of this function module, do I have to code an explicit COMMIT WORK in the BAdI or will SAP automatically generate a COMMIT WORK when the BAdI ends?

Hope you have called the FM correctly with the additional importing parameter , also check if your FM is RFC enabled then check the "pass by value" option.

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.

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 Question

I have a question for all of the guru's out there. I am updating multiple files in my Mobile Asset Process, but at some point I want to do a commit, but I only want to do the commit for one file not all of them. Is there a way to do that?
Thanks
Mike

Michael,
hope this will answer your question:
In database update processes, two things happen:
- the objects to be updated are locked
- database changes are written to the database rollback segment
Every work process or transaction runs in it's own logical unit of work (LUW).
At end of this LUW, an implicit COMMIT WORK occurs committing the rollback segment to the database. From now on, database changes become visible for all processes and users. Also all functions called with the addition IN UPDATE TASK are released for processing in an update process. An explicit COMMIT WORK at the end of active program will do the same and additionally start all FORMs called with the addition ON UPDATE.
In your case: A COMMIT WORK will commit <b>all</b> database requests as described above: There is no way to to 'selected' COMMIT.
If you process too many objects, either the database rollback segment or the lock table will overflow.
In terms of performance, it is better to wait for commit as long as possible because every commit means heavy processing for ABAP and database.
It is good practice to do a COMMIT after a certain number of objects. Some prefer 100; my personal experience says 1000 is fine.
ROLLBACK works the same way but it will clear the whole rollback segment making all changes undone. If you encounter an error after say 900 uncommited objects and a rollback is necessary, you have to start again right from the beginning.
Hope this helps you to find the best way.
Regards,
Clemens

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

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

Avoid 'commit-work'; LUW-Logic

Hello,
we have a problem in our luw! Although we do not use an explicit 'commit work' in one of our dialog-programs, a 'rollback' does not work correctly. I have tried to trace the sql-units while execution the program and find out that there are a whole of commit works in the trace-protocoll.
It looks like:
09:44:21.423       105 SAPLSEUJ PROGDIR    EXECSTM 119      1     1      0 R/3   1 UPDATE SET "RSTAT" = 'S' , "UNAM" =
09:44:21.423       944 SAPLSYDB            EXECSTA                0      0 R/3   1 COMMIT WORK
09:44:21.426       267 SAPLSYDB            EXECSTA                0      0 R/3   1 COMMIT WORK
Is there any chance to avoid such implicit commit-works?
Greetings,
Marcel

Some ABAP keywords have implicit commits. nothing can be done about them. For statements which requires explicit commits we can use the ROLLBACK WORK statement.

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.

Is there any Sound card 5.1 include stereo mix that working with MacBook Air such as Creative Labs SoundBlaster X-Fi Surround 5.1 Pro Entertainment System ? and if there any another sound card can you tell me what is it please ? Thank you.

Is there any Sound card 5.1 include stereo mix that working with MacBook Air such as Creative Labs SoundBlaster X-Fi Surround 5.1 Pro Entertainment System ? and if there any another sound card can you tell me what is it please ? Thank you.

Okay, I did my best searching and I couldn't find anything that matched all your descriptors. I did do a search on both decoder numbers. SB0256 returned very little results, but with SB0466, I was able to find this ebay listing:
http://cgi.ebay.com/ws/eBayISAPI.dll...6_fvi%3D&_rdc=
This card isn't a Champion like you suggested. And with my complete lack of knowledge, I don't know what I/O dri've bay means. But since it is PCI and the decoder matches the number you gave me, this card should be adequete, right?
Whether it works or not, my search indicated it might be very hard for me to find that card (or any PCI card for that matter). Everything I saw was out of stock. I know this is a forum for Creative, but are there any other manufacturers that will allow me to accomplish my goal, either with current cards, or discontinued cards? Thanks again
Oh, and I will vote on that thread. I probably won't wait for them to release the decoder since I need it now, but I still believe Creative should be giving the customer what they want

Calling Remote Functions Locally Triggers any Database commit(Implicit)

Hello,
Am making use of RFC enabled function module as normal function module (Calling remote function module locally).
My question is does it trigger any implicit database commit or not. Since synchronous RFC triggers database commit.
Regards,
Tenzin Choegyen

I057200 wrote:
Since synchronous RFC triggers database commit.
Let me correct the statement both synchronous as well as asynchronous RFCs trigger an implicit DB commit.
SAP documentation on synch-RFCs states:
If the content of dest is equal to the constant space, then the addition DESTINATION is ignored and a normal call CALL FUNCTION func is executed.
Please note that you should not use the DESTINATION addition or use DESTINATION space. DESTINATION none will start the FM as an RFC in the same app server.

Commit work not working in Routine for Transaction because of LUW

Hi all,
i have req to send adobe PDF as attachement by email.
Basically i am calling adobe from output type of VL02n .
Inside this i can not use commit work because of LUW.Please suggest what should i do.
so not able to send email in green status.
i am using below code
TRY.
      zlcl_send_request->set_document( zlcl_document ).
    CATCH cx_send_req_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
Email sender
TRY.
      zlcl_sender = cl_sapuser_bcs=>create( sy-uname ).
    CATCH cx_address_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
TRY.
      CALL METHOD zlcl_send_request->set_sender
        EXPORTING
          i_sender = zlcl_sender.
    CATCH cx_send_req_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
Create the Reciever address
TRY.
      zlcl_recipient = cl_cam_address_bcs=>create_internet_address(
                                         gv_email ).
    CATCH cx_address_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
TRY.
      zlcl_send_request->add_recipient( EXPORTING i_recipient =
      zlcl_recipient ).
    CATCH cx_send_req_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
TRY.
      zlcl_send_request->set_send_immediately( gc_x ).
    CATCH cx_send_req_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.
Send the mail
TRY.
      zlcl_send_request->send( ).
    CATCH cx_send_req_bcs INTO zicl_oref_cast.
      CLEAR gv_text_cast .
      gv_text_cast = zicl_oref_cast->get_text( ).
ENDTRY.

Hi
From abap help:
SY-ONCOM
On Commit flag. This system field is set to different values depending on the call status of an ABAP program. Of these, only the value of u2018Pu2019 is guaranteed. If at all, SY-ONCOM must only be queried for u2018Pu2019.
The value 'P' means that the program is already executing a subroutine started using PERFORM u2026 ON COMMIT and therefore a
further subroutine call using PERFORM ... ON COMMIT would cause a runtime error.
That means the variable SY-ONCOM has the information if a process "ON COMMIT" is working and so it determines if a dump has to be raised.
Now it's clear the meaning of that correction: if before calling a new commit the value of SY-ONCOM is changed the dump will be avoided.
I've done the following texts:
REPORT ZCOMMIT.
WRITE: 'Calling routine on commit'.
PERFORM DO_SOMETHING ON COMMIT.
COMMIT WORK.
FORM DO_SOMETHING.
DATA: ONCOM TYPE SY-UCOMM.
MOVE SY-ONCOM TO ONCOM.
SY-ONCOM = 'S'.
COMMIT WORK.
MOVE ONCOM TO SY-ONCOM.
ENDFORM.
The code above is very dangerous, because it triggeres a ricorsive loop: no dump, but the form is continuously called, just as help says SY-ONCOM is equal to P
REPORT ZCOMMIT.
WRITE: 'Calling routine on commit'.
CALL FUNCTION 'Z_MAX_COMMIT' IN UPDATE TASK.
COMMIT WORK.
FUNCTION Z_MAX_COMMIT.
DATA: ONCOM TYPE SY-UCOMM.
MOVE SY-ONCOM TO ONCOM.
SY-ONCOM = 'S'.
COMMIT WORK.
MOVE ONCOM TO SY-ONCOM.
ENDFUNCTION.
I expected the same behavior as above, but here no dump and no infinite loop, SY-ONCOM = V
Now your process working in update task, but probably many function are called, I mean the system creates a queue of functions to be run in update task, so what happens here?
I've tried this:
FUNCTION Z_MAX_COMMIT.
*"*"Function module di reg.:
*"*"Interfaccia locale:
*" IMPORTING
*"     VALUE(NO_COMMIT) TYPE FLAG DEFAULT SPACE
CHECK NO_COMMIT IS INITIAL.
DATA: ONCOM TYPE SY-UCOMM.
MOVE SY-ONCOM TO ONCOM.
SY-ONCOM = 'S'.
COMMIT WORK.
MOVE ONCOM TO SY-ONCOM.
ENDFUNCTION.
REPORT ZCOMMIT.
WRITE: 'Calling routine on commit'.
CALL FUNCTION 'Z_MAX_COMMIT' IN UPDATE TASK
EXPORTING
    NO_COMMIT = 'X'.
CALL FUNCTION 'Z_MAX_COMMIT' IN UPDATE TASK.
CALL FUNCTION 'Z_MAX_COMMIT' IN UPDATE TASK
EXPORTING
    NO_COMMIT = 'X'.
COMMIT WORK.
Here no dump and no infinite loop too, but also no impact on the rest of the functions,
I can suppose the impact will be on the saving of data on database only, because your COMMIT ends the LUW, so it's very important the routine for printing is called at the end, after all saving routines.
Max

COMMIT WORK within an user exit

Hi every one,
I got a lill question here, can i use COMMIT WORK (AND WAIT ) within a user
exit FM, if yes is do i need any thing extra. Please help.
Thanks in advance
Jahan.

Hi Jahan,
although your question has been answered, just a few words on COMMIT WORK.
During a LUW (logical unit of work, i.e. transaction) all changes of database records are done within a so-called rollback segment of the database. That means they are visible within the current LUW but invisible to other users.
This makes it easy to do all necessary changes to all tables step by step. And if any step fails, all changes can be thrown away. Thats what we call a rollback - A rollback will just dump the rollback segment.
The reason you should not COMMIT WORK in a user exit is simply you have no idea what other database changes have already been done and what other database changes may follow after the user exit. If in one of the following steps a severe error is detected, all prior changes cannot be rolled back. COMMIT WORK means that all changes still in the rollback segment of the database will be applied and finalized to the database. The rollback segment will also be dumped that there is no chance to find out details about the changes.
An Error message (Type E or A) will automatically finish the LUW without commiting the data in the rollback segment - implicit rollback.
The end of a report not caused by any error will commit the rollback segment to the database - implicit commit.
All function modules called IN UPDATE TASK will be executed in their own update process after COMMIT or DUMPED after rollback.
All form routines called as PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK will be executed only after explicit COMMIT WORK or ROLLBACK WORK.
The addition 'AND WAIT' just means that the next program statement is not executed before all update processes started with COMMIT WORK have finished.
The general rule derived from this can be:
Never do a commit or rollback in a process which is called by another process. The only place for COMMIT or ROLLBACK is at the end of reports and transactions using CALL ... IN UPDATE TASK or PERFORM ... ON COMMIT - if you call any functions you should be aware that function modules may initiate update calls and/or form calls ...ON COMMIT/ROLLBACK. An explicit COMMIT WORK at the end of a process (or ROLLBACK WORK in case of error) will be OK.
Regards,
Clemens

COMMIT WORK in enhancements.

HI ALL,
1) Can we use <b>COMMIT WORK</b> statement while coding in Enhancements(Include zx........). if not, WHY?
What are the consequences/problems of using it?
2) Any such conditions we have to follow while coding in enhancements?
Pl reply...

There is no rule not to use COMMIT WORK in enhancement.
I understand that the enhancements you are talking about are part of update programs / trxns. If some even if you don't do a COMMIT the SAP program will eventually do it. So there won't be any difference.
If you are adding an enhancement to SAP standard transaction/program which updates tables and creates data/documents, you need not do a COMMIT as it will eventually happen within the LUW

Transaction se37 include any implicit commit work?

Similar Messages

Maybe you are looking for