Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

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

Former Member
0 Kudos
220

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.
8 REPLIES 8

raymond_giuseppi
Active Contributor
0 Kudos
77

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

0 Kudos
77

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.

0 Kudos
77
  • 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

0 Kudos
77

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.

0 Kudos
77

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.

0 Kudos
77

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

0 Kudos
77

I have not used ORDER BY vbeln

matt
Active Contributor
0 Kudos
77

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.