How to check whether update is successful or not in update function module

[Former Member]

Hi..

I am using UPDATE FUNCTION MODULE to update a database table. I am calling the same function continuously for say fore times and then executing COMMIT statement.

Now , How can I come to know whether update is successful , if not which update task is failed.

Thanks in advance..

[Jelena]

Check sy-subrc after every UPDATE and before COMMIT. You might want to check the examples in ABAP documentation and ABAP Editor (in the menu somewhere). Pretty sure there are quite a few on handling the DB updates.

[Former Member]

Thanks for your reply..

I wanted to know if i execute four update statements (using update module) and then execute commit , how can I come to know exactly which update statements were successfully executed , and which were failed..

Can you please give more explanation on this..

Thank you...

[Sandra_Rossi]

No, don't check sy-subrc after call function in update task, as said in the ABAP documentation: "The system field sy-subrc is undefined after the statement CALL FUNCTION ... IN UPDATE TASK is executed"

[Jelena]

Sorry, I thought you were asking about a simple UPDATE. Haven't realized you meant CALL FUNCTION ... IN UPDATE TASK. It might make sense to just post the code next time. Either way, it seems this question has been answered already.

[raymond_giuseppi]

Call transaction SM13, to get list of FM called and the one that raised the error.

Note that if one of the update tasks FMs fails for a single commit, every previous successful update will be reversed/rollbacked. Perform some search in online help on COMMIT statement or database LUW concept.

[Sandra_Rossi]

In the ABAP program which does CALL FUNCTION ... IN UPDATE TASK, you may know whether the update function modules are okay only by using COMMIT WORK AND WAIT. Cf ABAP doc of COMMIT WORK:

sy-subrcMeaning0The addition AND WAIT was specified and the update of the update function modules was successful.4The addition AND WAIT was specified and the update of the update function modules was not successful.

But it doesn't mean you have to use COMMIT WORK AND WAIT : if you use COMMIT WORK alone, you must not test SY-SUBRC, but administrators regularly check transaction SM13 (cf Raymond's answer).

In the update function modules, you must not do any validation logic (they must be done before the COMMIT WORK), you must do only database operations. All possible errors must be handled and terminated by MESSAGE ... TYPE 'E' (for instance) to trigger automatically a database rollback, and the logging in SM13.

Note that CALL FUNCTION ... IN UPDATE TASK is only recording the call for later call, which is actually executed when the COMMIT WORK is reached.

[SuhaSaha]

In simple terms:

• If your application needs to know if the updates have been successful , then use synchronous updates (COMMIT WORK AND WAIT). Check SY-SUBRC after the commit.
• If the status of your updates are not important for your application, then use asynchronous updates (COMMIT WORK)

As Sandra & Raymond have already mentioned, SM13 should be regularly monitored by the admins.

A small tip: You can use BAPI_TRANSACTION_COMMIT with WAIT = 'X' because the error handling (SY-SUBRC <> 0) is already there!

[Sougata]

Thank you suhas.saha - the tip was very useful, it saved me a lot of time.

I was using cl_soap_commit_rollback=>commit_and_wait( ) after the Update Task call and when the control returned to the dialog task the sy-subrc was still 0 although an exception was raised in the update module.

However the BAPI_TRANSACTION_COMMIT with WAIT = 'X' worked well but differently. The sy-subrc inside this BAPI call returned 4 which I could then read the message type 'E' in its RETURN structure. I'm not sure why the behaviour is different between the two.

REPORT zsctest1.

PARAMETERS p_notif TYPE qmel-qmnum.

DATA lt_return TYPE qisrtreturn.
DATA ls_return TYPE bapiret2.

CALL FUNCTION 'ZFI_GL_GLMAST_UPDATE'
  IN UPDATE TASK
  EXPORTING
    iv_notification = p_notif
  EXCEPTIONS
    ex_update_error = 1
    OTHERS          = 2.

* cl_soap_commit_rollback=>commit_and_wait( ). "returns sy-subrc = 0 when an exceptn was raised in update module

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
  EXPORTING
    wait   = abap_true               " Use of Command `COMMIT AND WAIT`
  IMPORTING
    return = ls_return.              " Return Messages

cl_demo_output=>display( SWITCH #( ls_return-type
                           WHEN `E` THEN |Update was Cancelled|
                           ELSE |Update was successful|
                                 )
                       ).

Update Module:

FUNCTION ZFI_GL_GLMAST_UPDATE
  IMPORTING
    VALUE(IV_NOTIFICATION) TYPE QMEL-QMNUM
  EXCEPTIONS
    EX_UPDATE_ERROR.

  TRY.
      zcl_swf_glmast=>create( iv_notification )->maintain_masterdata( ).
    CATCH cx_bo_instance_not_found zcx_fi_general INTO DATA(lo_exception).
      "RAISE ex_update_error. "Results in a Rollback but with a Runtime error --> I don't want the Runtime error
      MESSAGE a098 WITH lo_exception->get_text( ) RAISING ex_update_error.  "Results in Rollback with no Runtime error
  ENDTRY.

ENDFUNCTION.