CODEWITHSUNDEEP
commitabapopensql
Buddhika Samith
Buddhika Samith

Reputation: 295

Commit work on table using UPDATE statement

I have problem regarding the ABAP update statement. I am using the 'Commit work' on one update table statement but it is not working properly sometime it is work and sometime it is not work.

Check the statements :

UPDATE mara
SET
      zzmanu     =  wa-sales_data2-zzmanu
      zzmatnr_sf =  wa-sales_data2-zzmatnr_sf
WHERE  matnr = wa-basic_data1-matnr.

if sy-subrc eq 0.
commit work.
wait up to 2 seconds.
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.

Upvotes: 0

Views: 20275

Answers (3)

Bernhard Lascy
Bernhard Lascy

Reputation: 69

About material numbers you have to know that SAP uses an so called "Alpha-Conversion".

Alphanumeric material numbers are left bound, numerical material numbers are right bound with leading zeroes.

That might be a problem if you don't have the material number in the form you need for updates.

So Ax1123 would be AX1123 on database 123 would be 000000000000000123 on data base.

SAP uses function modules like conversion_exit_alpha_input and conversion_exit_alpha_output to switch between DB values und UI-presentation.

Upvotes: 1

Nelson Miranda
Nelson Miranda

Reputation: 5564

If SY-SUBRC is equal to '4' then the material in table MARA doesn't exist or the value of wa-basic_data1-matnr is not ready for input and you must convert it.

Sometimes the value of 'MATNR' in table 'MARA' is configured in SAP to use a range to automatically assign the number to materials in the standard transactions 'MM01' and 'MM41'. This behaviour doesn't apply in custom programs, please make sure to use the function modules 'CONVERSION_EXIT_MATN1_INPUT' and 'CONVERSION_EXIT_MATN1_OUTPUT' in this situations.

The data type 'MATNR' is a CHAR(18) and the values (in this case) are stored with zeros at the left although you see the number without those zeros. And that is because SAP internally converts for output the value so the user doesn't see those zeroes.

For example, if the value of MARA-MATNR in transaction 'SE16N' or 'MM03' is '9999999' then the real value stored is '000000000009999999'. Check the same table with transaction 'SE11' and this time you'll see the raw data. The following code can explain a little better the above:

DATA: lv_matnr TYPE matnr,
      wa_mara TYPE mara.

lv_matnr = '1234567'. " -> Not ready for input
SELECT SINGLE * FROM mara INTO wa_mara WHERE matnr eq lv_matnr.
WRITE sy-subrc. " -> sy-subrc = 4. Not found

CALL FUNCTION 'CONVERSION_EXIT_MATN1_INPUT' " Format for input
  EXPORTING
    INPUT              = lv_matnr " The value is '1234567'
  IMPORTING
    OUTPUT             = lv_matnr " The value will be formatted to '000000000001234567'
  EXCEPTIONS
    LENGTH_ERROR       = 1
    OTHERS             = 2
          .
IF SY-SUBRC <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*         WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

SELECT SINGLE * FROM mara INTO wa_mara WHERE matnr eq lv_matnr.
WRITE / sy-subrc. " -> sy-subrc = 0. Found

In your case try this;

CALL FUNCTION 'CONVERSION_EXIT_MATN1_INPUT'
  EXPORTING
    INPUT              = wa-basic_data1-matnr 
  IMPORTING
    OUTPUT             = wa-basic_data1-matnr " Add zeroes at the left
  EXCEPTIONS
    LENGTH_ERROR       = 1
    OTHERS             = 2
          .
IF SY-SUBRC <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*         WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

UPDATE mara
SET
      zzmanu     =  wa-sales_data2-zzmanu
      zzmatnr_sf =  wa-sales_data2-zzmatnr_sf
WHERE  matnr = wa-basic_data1-matnr.

if sy-subrc eq 0.
commit work.
wait up to 2 seconds.
ENDIF.

Hope it helps

Upvotes: 2

Mikael G
Mikael G

Reputation: 742

Change your commit to 

COMMIT WORK AND WAIT. 
IF SY-SUBRC NE 0.
  WRITE: / 'Update error! Check SM13'.
ENDIF.

If you check BAPI_TRANSACTION_COMMIT, it's exactly what is done when called with WAIT parameter. You could use that function module if you prefer and display the standard error message.

If your update fails, check SM13 for the cause. Most likely, it's a lock issue but there could be other reasons as well.

In any case, you should extend your logic to include object locking before the UPDATE.

Upvotes: 2

Related Questions