Error with commit work

Hi everybody.
I have a standar aplication with this instruction. If I execute the program directly, it raise an exception. But if I active the debug, stop in the line of this instruction, and press F6 to execute the "commit work", and then press F8, it work correctly. If I activate the debug at the star of program, and pres F8 directly, it raise the exception too.
Summary:
Break point at line "commit work".
Run the aplication
The execution stop at the break point
Press F8
ERROR (exception)
Break point in other previous point of the program
Run the aplication
The execution stop at the break point
Press F8
ERROR (exception)
Break point at line "commit work"
Run the aplication
The execution stop at the break point
Press F6 (it jump to the next line)
Press F8
FINISH FINE
The exception is this (is in a BSP):
An exception has occurred Exception Class CX_BOL_EXCEPTION - Access Previously Deleted Entity
Method: CL_CRM_BOL_CORE=>REREAD_ENTITY
Source Text Row: 118
And this is the code that raise the exception:
  if IV_ENTITY->MY_MANAGER_ENTRY is not bound or IV_ENTITY->CONTAINER_PROXY is not bound.
  entity does not longer exist
    raise exception type CX_BOL_EXCEPTION
      exporting
        TEXTID = CX_BOL_EXCEPTION=>ENTITY_ALREADY_FREED.
  endif.
But the commit is previos than this...
Thanks, experts

hi
chk this statement
if sy-subrc <> 0.
message s208(00) with 'Error'. --> where will the status bar msg. occur in bground
leave list-processing.
endif.
maybe the subrc might be false, and triggering this condition, which i believe will not work in background
if helpful, reward
Sathish. R

Similar Messages

  • DUMP with Commit work and wait

    Hi all!! I need your help again!!
    I have this:
      WAIT UP TO 1 SECONDS.
                          UPDATE zpsc_ofertes
                          SET status = 'ENTRA'
                              status_v = 'CO/AA'
                          WHERE oferta = zpsc_ofertes-oferta
    AND versio = var_vers_destino.
    CALL FUNCTION 'STATUS_UPDATE_ON_COMMIT'.
        COMMIT WORK AND WAIT.
    CALL FUNCTION 'BUFFER_REFRESH_ALL'
    That code creates a dump... Why could be this problem??
    Thanks!!

    Let's see.
    The current application triggered a termination with a short dump.
    ¿Qué ha sucedido?
    The current application program detected a situation which really
    should not occur. Therefore, a termination with a short dump was
    triggered on purpose by the key word MESSAGE (type X).
    ¿Qué puede hacer?
    Print out the error message (using the "Print" function)
    and make a note of the actions and input that caused the
    error.
    To resolve the problem, contact your SAP system administrator.
    You can use transaction ST22 (ABAP Dump Analysis) to view and administer
    termination messages, especially those beyond their normal deletion
    date.
    The code...
    000010   *
    000020   ***INCLUDE LPS_BAPIF01 .
    000030   *
    000040   *&
    000050   *&      Form  CHK_PRECOMMIT
    000060   *&
    000070   *       check precommit
    000080   *
    000090   FORM chk_precommit.
    000100
    000110     DATA: chk_precommit_ok TYPE c,
    000120           chk_error        type c.
    000130
    000140     CALL FUNCTION 'PS_FLAG_GET_GLOBAL_FLAGS'
    000150          IMPORTING
    000160               e_precommit_ok = chk_precommit_ok
    000170               e_error        = chk_error.
    000180
    000190     IF chk_precommit_ok = space.
    000200   *   Precommit wurde noch nicht aufgerufen.
         >       MESSAGE x030(cnif_pi).
    000220     ELSEIF chk_precommit_ok <> 'Y'.
    000230   *   Precommit wurde nicht erfolgreich durchlaufen.
    000240       MESSAGE x033(cnif_pi).
    000250     elseif not chk_error is initial.
    000260   *   At least one single BAPI failed
    000270       MESSAGE x056(cnif_pi).
    000280     ENDIF.
    000290
    000300   * commit work was called successfully after the precommit
    000310     PERFORM ps_bapi_init_global_variables.
    000320
    000330   ENDFORM.                    " CHK_PRECOMMIT
    000340

  • 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

  • "Problem" with COMMIT WORK AND WAIT

    Hi everyone!
    I'm facing the following situation:
    I have a Z program that calls MIGO, via CALL TRANSACTION. The only thing I do when calling this is filling a few fields, so the user has to complete the  operation before going back to Z program.
    When someone executes MIGO in the normal way, I mean, without a CALL TRANSACTION command, there was a additional step, a modification made in the standard code for someone before. But this part of the code didn't execute when calling MIGO via CALL TRANSCATION.
    What I have found out is that just before this code inserted, there was a COMMIT WORK AND WAIT command, and was exactly in this point that, when using the first aproach, it leaves MIGO.
    Is there a way to execute the entire process in MIGO,  I mean , do not leave it at COMMIT command? I've tried to pass at CALL TRANSACTION command diferent UPDATE parameters (i.e: 'S', 'A' and 'L'), but it didn´t work as well.
    I hope you could get the point!
    Thanks in advance!
    Raphael

    I've just found out something interesting about that.
    When I make a CALL TRANSACTION, without passing a table bdcdata, the transaction doesn't leave at the COMMIT WORK command.
    So,  I think it won't work with the bdcdata!
    Raphael

  • Issue with Commit Work and Wait.

    Hi All,
    None of the programs are working in my system which are calling BAPI BAPI_TRANSACTION_COMMIT.
    On COMMIT WORK AND WAIT statement, the process is going into indefinite loop. Everything was fine till last Thursday and there are no updates or patch level change or notes applied in the system.
    Please advice.

    <div style="text-align:left">We tried everything but still the issue is there.</div>
    Normally it's much easier to get help if you try to be as detailed as possible when explaining the problem and what exactly you have tried. No offense, but tried everything most likely translates into almost everything...
    Some information/checks I'd be looking for:
    <ul style="list-style:square!important">
    <li>What functions are (or coding is) involved? Are they all standard or custom?</li>
    <li>Have you tried update debugging and/or the usual traces (runtime analysis, SQL trace, etc.)?</li>
    <li>What do you see in the process overview?</li>
    <li>What about system log, developer trace, database logs/alerts, etc.?</li>
    </ul>
    Obviously my list is much too short and incomplete - yours must be longer. If you share your results (including your exchange with SAP) I suspect you have a better chance (though of course no guarantee) of somebody providing a valuable clue.
    Not sure if it's just me, but the part that sounds so odd and suspicious is that you only mention commits via BAPI_TRANSACTION_COMMIT. As this is just a wrapper around a COMMIT WORK I'm tempted to think it's the functionality that's invoked before (i.e. linked to the registered update functions/modules). Without any additional knowledge though, my first shot was for general update problems (which you ruled out).

  • Reg. Error in Commit work in FM "SO_NEW_DOCUMENT_ATT_SEND_API1"

    Dear Experts,
    My requirement is that i need to send the PDF attachment via Outlook Express as Mail. I am using the FM "SO_NEW_DOCUMENT_ATT_SEND_API1" for sending to Outlook Express. Here i need to check "Commit work" flag. Else it will not be sent to the mail. When i do this, i am getting the short dump saying "MESSAGE_TYPE_X" - Pre_commit check.
    Is the above issue related to any configuration settings done by Basis. I checked the forum but i could not get suitable post.
    Kindly help me in this regard.
    Regards,
    Ramesh Manoharan

    Hi Ramesh,
    Check subrc and RETRN_CODE value for the table RECEIVERS. If subrc is inintial and Return_code is fine.
    Then check with your basis team. They might need to do some config change.
    I have used used a Z-FM to do this job. Find the code below.
    FUNCTION z_send_pdf_2_email .
    *"*"Local Interface:
    *"  IMPORTING
    *"     VALUE(EMAILID) TYPE  INTAD
    *"     VALUE(SUBJECT) TYPE  CHAR200
    *"     VALUE(ATTACH_NAME) TYPE  CHAR200
    *"     VALUE(PONUM) TYPE  EBELN
    *"     VALUE(PODATE) TYPE  BEDAT
    *"  EXPORTING
    *"     REFERENCE(RETURN) TYPE  SUBRC
    *"  TABLES
    *"      I_OTF STRUCTURE  ITCOO
      TYPES : t_record  TYPE solisti1,
              t_objpack TYPE sopcklsti1,
              t_objtxt  TYPE solisti1,
              t_reclist TYPE somlreci1.
      DATA : l_lines_bin TYPE i,
             l_lines_txt TYPE i,
             l_len_in TYPE sood-objlen,
             l_date TYPE char10,
             i_record TYPE TABLE OF t_record,
             i_objpack TYPE TABLE OF t_objpack,
             i_objtxt TYPE TABLE OF t_objtxt,
             i_objbin TYPE TABLE OF t_objtxt,
             i_reclist TYPE TABLE OF t_reclist,
             i_tline TYPE TABLE OF tline,
             w_record TYPE t_record,
             w_objpack TYPE t_objpack,
             w_objtxt TYPE t_objtxt,
             w_objbin TYPE t_objtxt,
             w_reclist TYPE t_reclist,
             w_tline TYPE tline,
             w_doc_chng TYPE sodocchgi1,
             w_buffer TYPE string,
             w_objhead TYPE soli_tab.
      CONSTANTS: c_smart(5) TYPE c VALUE 'SMART',
               c_u TYPE c VALUE 'U',
               c_raw(3) TYPE c VALUE 'RAW',
               c_f TYPE c VALUE 'F',
               c_pdf(3) TYPE c VALUE'PDF',
               c_x TYPE c VALUE 'X'.
    * Convert OTF data to PDF
      CALL FUNCTION 'CONVERT_OTF'
        EXPORTING
          format                = c_pdf
          max_linewidth         = 132
        IMPORTING
          bin_filesize          = l_len_in
        TABLES
          otf                   = i_otf
          lines                 = i_tline
        EXCEPTIONS
          err_max_linewidth     = 1
          err_format            = 2
          err_conv_not_possible = 3
          err_bad_otf           = 4
          OTHERS                = 5.
      IF sy-subrc <> 0.
    * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
    *         WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
      ENDIF.
      LOOP AT i_tline INTO w_tline.
        TRANSLATE w_tline USING '~'.
        CONCATENATE w_buffer w_tline INTO w_buffer.
      ENDLOOP.
      TRANSLATE w_buffer USING '~'.
      DO.
        w_record = w_buffer.
        APPEND w_record TO i_record.
        SHIFT w_buffer LEFT BY 255 PLACES.
        IF w_buffer IS INITIAL.
          EXIT.
        ENDIF.
      ENDDO.
    * Attachment
      REFRESH: i_reclist,
      i_objtxt,
      i_objbin,
      i_objpack.
      CLEAR w_objhead.
      i_objbin[] = i_record[].
      CONCATENATE podate+6(2) '.' podate+4(2) '.' podate(4) INTO l_date.
    * Create Message Body Title and Description
      w_objtxt = text-003.
      APPEND w_objtxt TO i_objtxt.
      CLEAR w_objtxt.
      CONCATENATE l_date text-004 ponum text-005 INTO w_objtxt SEPARATED BY space.
      APPEND w_objtxt TO i_objtxt.
      CLEAR: w_objtxt, l_date.
      w_objtxt = text-006.
      APPEND w_objtxt TO i_objtxt.
      CLEAR w_objtxt.
      w_objtxt = space.
      APPEND w_objtxt TO i_objtxt.
      CLEAR w_objtxt.
      w_objtxt = text-007.
      APPEND w_objtxt TO i_objtxt.
      CLEAR w_objtxt.
      w_objtxt = space.
      APPEND w_objtxt TO i_objtxt.
      CLEAR w_objtxt.
      w_objtxt = text-008.
      APPEND w_objtxt TO i_objtxt.
      CLEAR w_objtxt.
      DESCRIBE TABLE i_objtxt LINES l_lines_txt.
      READ TABLE i_objtxt INTO w_objtxt INDEX l_lines_txt.
      w_doc_chng-obj_name = subject.
      w_doc_chng-expiry_dat = sy-datum + 10.
      w_doc_chng-obj_descr = subject.
      w_doc_chng-sensitivty = c_f.
      w_doc_chng-doc_size = l_lines_txt * 255.
    *Main Text
      CLEAR w_objpack-transf_bin.
      w_objpack-head_start = 1.
      w_objpack-head_num = 0.
      w_objpack-body_start = 1.
      w_objpack-body_num = l_lines_txt.
      w_objpack-doc_type = c_raw.
      APPEND w_objpack TO i_objpack.
      CLEAR w_objpack.
    * Attachment (pdf-Attachment)
      w_objpack-transf_bin = c_x.
      w_objpack-head_start = 1.
      w_objpack-head_num = 0.
      w_objpack-body_start = 1.
      DESCRIBE TABLE i_objbin LINES l_lines_bin.
      READ TABLE i_objbin INTO w_objbin INDEX l_lines_bin.
      w_objpack-doc_size = l_lines_bin * 255 .
      w_objpack-body_num = l_lines_bin.
      w_objpack-doc_type = c_pdf.
      w_objpack-obj_name = c_smart.
      w_objpack-obj_descr = attach_name.
      APPEND w_objpack TO i_objpack.
      CLEAR w_reclist.
      w_reclist-receiver = emailid.
      w_reclist-rec_type = c_u.
      APPEND w_reclist TO i_reclist.
      CLEAR:w_reclist.
    * Send Mail
      CALL FUNCTION 'SO_NEW_DOCUMENT_ATT_SEND_API1'
        EXPORTING
          document_data              = w_doc_chng
          put_in_outbox              = c_x
    *      commit_work                = c_x
        TABLES
          packing_list               = i_objpack
          object_header              = w_objhead
          contents_bin               = i_objbin
          contents_txt               = i_objtxt
          receivers                  = i_reclist
        EXCEPTIONS
          too_many_receivers         = 1
          document_not_sent          = 2
          document_type_not_exist    = 3
          operation_no_authorization = 4
          parameter_error            = 5
          x_error                    = 6
          enqueue_error              = 7
          OTHERS                     = 8.
      IF sy-subrc <> 0.
      ENDIF.
      READ TABLE i_reclist INTO w_reclist INDEX 1.
      IF sy-subrc IS INITIAL.
        return = w_reclist-retrn_code.
      ENDIF.
    *Clear Refresh Data
      CLEAR: l_lines_bin,
             l_lines_txt,
             l_len_in,
             i_record,
             i_objpack,
             i_objtxt,
             i_objbin,
             i_reclist,
             i_tline,
             w_record,
             w_objpack,
             w_objtxt,
             w_objbin,
             w_reclist,
             w_tline,
             w_doc_chng,
             w_buffer,
             w_objhead.
      REFRESH:i_record,
             i_objpack,
             i_objtxt,
             i_objbin,
             i_reclist,
             i_tline.
    ENDFUNCTION.

  • Problem with COMMIT WORKS command

    Hello all,
    I’ve a little problem. It seams that I don’t understand how ‘commit work’ command works. When I’m calling transaction with USING parameter:
    CALL TRANSACTION 'FPSA' USING itab_bdcdata.
    When inside of that transaction ‘Commit works’ occur, than commit is being executed and transaction is ending which is not good, because there is still code left that should be executed.
    When I run transaction without USING
    CALL TRANSACTION 'FPSA'
    Everything works fine. I’ve tried using UPDATE addition in CALL FUNCTION, but without result. Does anybody know what is the problem?

    This is meant to work exactly as you described:
    A transaction called with CALL TRANSACTION USING returns right after COMMIT occurs - if you don't provide any additional options.
    There is a way to make such transaction continue with the code after the commit. You just have to use "OPTIONS FROM" addition of the "CALL TRANSACTION" statement - parameter RACOMMIT.
    For more information put the cursor on CALL TRANSACTION statement in your abap code and press F1.
    regards
    good luck

  • Invalid number error - with comma separated values

    FUNCTION fn_check_value(
    p_ids_in IN VARCHAR2
    RETURN NUMBER
    IS
    v_nCheckValue NUMBER;
    CURSOR vCur
    IS
    SELECT COUNT(*)
    FROM t1
    WHERE col_id IN (p_ids_in); -- col_id is number field
    BEGIN
    OPEN vCur;
    FETCH vCur INTO v_nCheckValue;
    CLOSE vCur;
    Return v_nCheckValue;
    END fn_check_value;
    I get following error when the input is 3,4. Works fine with single value
    Execution failed: ORA-01722: invalid number

    If you have more than one number in the list being passed in through p_ids_in then you could try the following
    CURSOR vCur
    IS
    SELECT COUNT(*)
    FROM t1
    where
    INSTR(chr(44) || p_ids_in || chr(44), chr(44) || col_id || chr(44) ) > 0;
    This will do pattern matching and will return a true if the pattern matches.
    For example, if p_ids_in = '3,4'
    then INSTR (',3,4' , ',3,') > 0 will return a true.
    This approach is useful if you have more than one value inside a string.
    Shakti
    (http://www.impact-sol.com)
    (Developers of Guggi Oracle - Tool for DBAs and Developers)

  • Error with disp+work.exe in Cluster

    Hi!
    I have installed SAP Solution Manager 4.0 on Windows as MS Cluster.
    After Kernel Upgrade the central instance (disp+work.exe) does not start and stopped after a while.
    Fri Feb 22 16:04:13 2008
    SAP HA Trace: Build in SAP Microsoft Cluster library '700, patch 148, changelist 963918' initialized
    Initializing SAPControl Webservice
    SapSSLInit failed => https support disabled
    Starting WebService Named Pipe thread
    Starting WebService thread
    Webservice named pipe thread started, listening on port
    .\pipe\sapcontrol_02
    Webservice thread started, listening on port 50213
    FRTG\sspadm is starting SAP System at 2008/02/22 16:04:53
    SAP HA Trace: FindClusterResource: SAP resource not found [sapwinha.cpp, line 334]
    SAP HA Trace: SAP_HA_FindSAPInstance returns: SAP_HA_NOT_CLUSTERED [sapwinha.cpp, line 907]
    FRTG\sspadm is stopping SAP System at 2008/02/22 16:08:07
    Any helpful information will be appreciated.
    Thank you
    regards

    Thom,
    Check this thread.  Are you using a DB control in your start profile?  The solution sounds suspicious but you might give it a try.  They may have actually changed something else without informing the author.
    Re: central instance error mscs abap unknown
    jwise

  • 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 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 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

  • 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

  • Continue behind COMMIT WORK.

    Hi all,
    I am facing problem with COMMIT WORK in my STANDARD SAP modification for executing ABAP Proxy. The problem is that the program doesnt continue after COMMIT WORK (messages, screens), but return to the initial screen.
    Is there any way to commit data sent via proxy and then continue (with next proxy calling, processing screens etc)?
    Thank you very much.
    Frantisek Holas, CZ

    Hi,
    I solved the problem myself.
    http://help.sap.com/saphelp_nw70/helpdata/EN/41/7af4e3a79e11d1950f0000e82de14a/frameset.htm
    http://help.sap.com/saphelp_nw70/helpdata/EN/41/7af4e3a79e11d1950f0000e82de14a/frameset.htm
    The point of solve the problem is place certain statements following with commit into standalone report, that you can call with SUBMIT command, passing value from ABAP memory or via select-option, as explained in documentation for SUBMIT STATEMENT.
    The trick of this solution is that calling new report via submit creates new SAP LUW, which can contain COMMIT WORK, that commit ONLY SAP LUW of the called report. When the report finishes and you return to the calling report/fm/trasaction/..., the SAP LUW of the calling rept/fm/transaction/... continue not affected by this COMMIT.
    It helped me to solve my problem.

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

Maybe you are looking for

  • Sales order item ontime delivery status at order level in Cube

    Hi Guys,   We have a requirement, currently we have sales order item information in cube where we have some thing called OTD status this status is based on actual GI date and requested date so we have 3 staus at each sales order item level ontime, ea

  • Sequence in combination with function

    Hi, I have an issue with a sequence in combination with a function. I want to generate some kind of an inventory material report that contains some kind of a material ID (a non-repeating, auto-incrementing number, gaps allowed). However I have to kee

  • Photo Software and Apps

      Photo Software and Apps After you have uploaded your digital photos to your computer, you are almost ready to start editing. With many options for photo editing software, the possibilities are seemingly endless. There are many different tasks and o

  • Real-time process slowly filling up Postgres DB space

    I have a real-time job which takes data from a JMS queue, processes the data, and then applies inserts/updates to an Oracle DB. In the task definition for the process Results drill down is set = "None" yet the Postgres DB grows substantially as the j

  • Add label on y-axis and x-axis in excel using Report Generation toolkit

    Hello, I want to add label in x-axis(Date/Time) and y-axis(Temperature O=oC) There are only header and data array connection, how can i add label to the chart? Thank you.