Database table is not committing in case if big volume of data

[Former Member]

I have a Z program, developed for mass closure of orders using '/AFS/BAPI_SALESORD_CHANGE' BAPI.When i run the report for less records its working fine, but when i run with big volume of data, all the data is committing into database except for first two orders, which is a strange behaviour.

Please guide me how to avoid this problem.

Below is the sample code.

IF gt_vbap IS NOT INITIAL.
  LOOP AT gt_vbap INTO gst_vbap.
    gs_so_item-itm_number = gst_vbap-posnr.
    gs_so_item-material = gst_vbap-matnr.
    gs_so_item-reason_rej = gc_rjection.
    APPEND gs_so_item TO gt_so_item.

    gs_so_itemx-itm_number = gst_vbap-posnr.
    gs_so_itemx-updateflag = gc_update.
    gs_so_itemx-material = gc_x.
    gs_so_itemx-reason_rej = gc_x.
    APPEND gs_so_itemx TO gt_so_itemx.

    gs_order_header_inx-updateflag = gc_update.
    
      AT END OF vbeln.
        REFRESH: gt_return.
        WAIT UP TO 3 SECONDS.
        CALL FUNCTION '/AFS/BAPI_SALESORD_CHANGE'
            EXPORTING
                salesdocument = gst_vbap-vbeln
                order_header_in = gs_order_header_in
                order_header_inx = gs_order_header_inx
            TABLES
                return = gt_return
                order_item_in = gt_so_item
                order_item_inx = gt_so_itemx.

        IF sy-subrc = 0.
                COMMIT WORK AND WAIT.
        ENDIF.

[RaymondGiuseppi]

Is the

CALL FUNCTION '/AFS/BAPI_SALESORD_CHANGE'
  EXPORTING
    salesdocument = gst_vbap-vbeln
    order_header_in = gs_order_header_in
    order_header_inx = gs_order_header_inx
  TABLES
    return = gt_return
    order_item_in = gt_so_item
    order_item_inx = gt_so_itemx.

IF sy-subrc = 0.
COMMIT WORK AND WAIT.
ENDIF.

your actual code, in this case replace the sy-subrc check by a loop at table RETURN looking for error type (E) messages, and, if found, rollback work and fill a log of exceptions/errors. (You could also use BAPI_TRANSACTION_[COMMIT, ROLLBACK] FM (for some buffer refresh). Then the answer of your question will be 'execute SLG1'...

[Former Member]

Hello Raymond,

I have already tried BAPI_TRANSACTION_COMMIT and looped return tables also but still the same issue.

IF i debug the issue, i am not finding any problem as after coming out of debugger all records are commiting into database perfectly.

My problem is only when i am executing this report with big volume of data via background job, only first two records are not working and i can see those records in spool.

[RaymondGiuseppi]

• Does BAPI_TRANSACTION_COMMIT return an error in RETURN table (it can if WAIT parameter is set)
• Do you see some errors in SM13 (or some updates not yet executed)
• Are there some 'S' or 'W' messages in return, kind of 'no data changed' type

[Former Member]

All the return messages are of 'I' or 'S' type.

No updates in SM13

No error from BAPI

Kindly help me why only first two records are not committing in case of big volume of data.

[matt]

Is gt_vbap sorted by vbeln?

Is gt_vbap a sorted table? Do you have a SORT gt_vbap anywhere? Or when you select into gt_vbap, do you use ORDER BY vbeln?

If not, then the cause of your problems is using AT END OF with a table that's not sorted.

[Former Member]

I have already sorted gt_vbap by VBELN before looping the internal table.

[Former Member]

I have not used ORDER BY vbeln

[matt]

Please in future use the "code" button when you paste code. If you're pasting from an editor, using right-click "paste as plain text". Ensure your code is nicely indented and formatted and easy to read.

I've done it for you this time.