Database table not getting updated occassionally

[former_member232092]

Hi All,

As part of some requirement we have created a normal function module which calls MIRO using call transaction. After the call transaction is performed we are getting the invoice number and fiscal year using get parameter id and storing those values into our custom table for later use. Code is like the below.  The subroutine is inside the custom function module.

FORM calltr_miro.

  SET PARAMETER ID 'RBN' FIELD invoice_no.

  SET PARAMETER ID 'GJR' FIELD l_fyear1.

  CALL TRANSACTION 'MIRO'.

  GET PARAMETER ID 'RBN' FIELD invoice_no.

  GET PARAMETER ID 'GJR' FIELD l_fyear1.

UPDATE zheader SET belnr = invoice_no  gjahr = l_fyear1 WHERE <condition>

COMMIT WORK AND WAIT.

ENDFORM.

" CALLTR_MIRO

Now the problem is some times the custom table zheader is not getting updated with the invoice and fiscal year. Could help in solving the problem.Also could give some tips to use commit work and wait statements  in function modules.

Thanking in advance,

Regards,

Ram.

[harshsisodia31]

Hi ram,

if sy-subrc = 0.

wait up to 3 seconds.

commit work and wait.

endif.

use above statements after update.

[Private_Member_7726]

Without knowing how MIRO is programmed..., is it really guaranteed in that transaction that the user does not regain control over navigation after posting Invoice..? Or that he can not post several Invoices while in the Transaction? Because if he does, or if the user can switch to other transaction by entering T-Code in Command field, this kind of custom code can not work reliably in principle... The Z Table would be updated for last Invoice only or not at all, if user navigates away after posting... Find an appropriate Enhancement/Exit and implement your logic there, I'd say...

cheers,
Janis

[thanga_prakash]

Hello Ram,

Difference between COMMIT WORK and COMMIT WORK AND WAIT is

COMMIT WORK - Asynchronous updating

COMMIT WORK AND WAIT - Synchronous updating.

When you specify COMMIT WORK AND WAIT, there is possibility of two sy-subrc.

0 - Update successful

4- Update not successful.

So what you can do is, put a sy-subrc check after the statement COMMIT WORK AND WAIT, if the sy-subrc is 4, repeat the update until it becomes sy-subrc to 0.

Regards,

Thanga

[Private_Member_7726]

Right, but there are no asynchronous update function modules registered (called) in that form, and MIRO would have committed/rolled back before the control passes back to form. AND WAIT is superfluous there I think.

cheers,

Janis

[Former Member]

User can do whatever he wants to do in MIRO and expecting the transaction to give back only the right parameters is quite not well overthinked.

You can create e.g. SLG1 logging mechanism (or any other log-saving mechanism) to provide information about what the values of imported parameters were during the process. But the best approach should be implementing an exit in MIRO, as Janis suggested.

[Former Member]

Hi,

Janis & Jozef have already highlighted the pitfalls of this design.

My suggestion is - After calling the transaction 'MIRO' it should come back to the calling program with messages for a single  IR document. This can be done by using -CALL TRANSACTION  using bdcdata messages into msg .  This holds good, if the documents are processed in a loop.

Or use a BAPI serving the same purpose and then check the return parameters.

Advantages - You can collect all the created/changed invoices and then update Z table at one shot.

Or use some exit in the MIRO to populate the ZTABLE. (  As suggested by Janis/ Jozef )

Regards,

DPM