How can I check if all update finished (including V2 Update)?

[Peter_Inotai]

Hi,

I have the following issue:

- in our Customer program there is a call for transaction MIR4

        SET PARAMETER ID 'RBN' FIELD rbkp-belnr.
        SET PARAMETER ID 'GJR' FIELD rbkp-gjahr.
        SET PARAMETER ID 'CHG' FIELD 'X'.
        CALL TRANSACTION 'MIR4' AND SKIP FIRST SCREEN.

- in MIR4 the user can change the Invoice from here and save/hold it

- when the user comes back to the customer transaction, all the updated values should be displayed

I have the following code

* Commit data if the Invoice was changed, otherwise select can return with the old value
        COMMIT WORK AND WAIT.

        SELECT SINGLE *
         FROM rbkp
         WHERE belnr = ls_belnr
           AND gjahr = ls_gjahr.

However even if I have the COMMIT WORK statement, sometimes the SELECT statement still returns with the old value.

I think there are some V2 updates and COMMIT WORK AND WAIT waits only for the type V1 update.

'WAIT UP TO time SECONDS' might be an option, however for large invoices it might be not a reliable way.

Any idea on this one?

Thanks in advance,

Peter Inotai

[naimesh_patel]

Hello,

Whenever you want to select new value of invoice try like this,

do.

SELECT SINGLE *

FROM rbkp

WHERE belnr = ls_belnr

AND gjahr = ls_gjahr.

if old_invoice <> new_invoice.

exit.

endif.

enddo.

But, keep in mind to exit the loop after some time.

Regards,

Naimesh

PS: Reward points, if it is useful..!

[Peter_Inotai]

Hi Naimesh,

Thanks for your answer.

It's not sure that the use will change the invoice, so I don't think it would help.

Peter

[Former Member]

Hello Peter,

I don't think it has anything to do with V2, as all the updation related to the transactions are done via V1 and any statistical updates will happen through V2. Also commit and work deals only with V1.

Just a long shot is check VBMOD also if possible.

[Peter_Inotai]

Hi Abhijit Dani,

Thanks for your suggestion. VBMOD is a good idea, however I was not able to catch the update in SM13. Even if I press refresh right after the save/post, I cannot see any entry in SM13.

Peter

[Former Member]

Hello Peter,

In that case the updates have finished without any delay and the result should be available for further use. Another option u can check is if the MIR4 is using any lock objects to lock the table. If there are any then u can check the existence of lock and if not then u can assume that the updates must have happened.

[Peter_Inotai]

Hi,

Thanks for the idea.

I couldn't find any info if V2 update keeps the lock or not.

Peter

[Former Member]

Hello Peter,

No u don't have to find lock for V2 but for the V1 process. I.e to say check if the tables which are getting updated have any locks done before updation and then check for release of them.

Hope this helps.

[Peter_Inotai]

I don't worry about V1 process, as COMMIT WORK AND WAIT will wait until the V1 related locks are released.

Peter

[Former Member]

I don't think u should even look for V2, almost sure it will not do any updates related to database in V2. It only does statistical updates and any other non important activity. As u are looking for a change in the invoice fields, it has to be updated in V1 unless it is importatn statistically like LIS or SIS.

[Peter_Inotai]

Well, in this case COMMIT WORK should do the db update and the SELECT should fetch the new value....but it's not always the case....and I have no other idea:-(

Peter

[christian_wohlfahrt]

Hi Peter!

Your commit work and wait has absolute no influence. In the transaction is already a commit work, your second commit can just trigger the changes between the first and the second - which is more or less nothing.

Instead you can try to call the transaction in a different way:

CALL TRANSACTION 'MIR4' USING bdc_data MODE 'E' UPDATE 'L'.

Here update 'L' (or 'S') will have an effect like a commit work and wait inside of MIR4. In bdc_data you just fill data for the first screen (including the first OK_CODE. Because no bdc_data for the second screen is found, the batch will stop ('no data for screen ...' message?).

If you run completely a session, the bdc-options will work - if they are still valid after an error, I can't tell.

Checking the locks of MIR4 is the next best option - but I couldn't find the locks set by MIR4 - for me it's a pure display transaction (maybe you can jump to a change, but I didn't find). I would have expected RBKP-BELNR, -GJAHR as a lock-key - but just go in one example (in change mode) and have a lock at SM12 - there you should see an matching entry, double click to see the lock object.

Try to set after returning from call transaction a lock -> booking should be complete in case of success (and remove the lock again).

Regards,

Christian

[Peter_Inotai]

Hi Christian,

Sorry for the late feedback, there were other things to fix.

Finally I got time to change it and test it and with option UPDATE 'L' it works fine.

Thanks a lot for your help.

Cheers,

Peter

[Former Member]

Hi Peter,

The best thing, in such cases, to do is rewrite your SELECT as follows

SELECT SINGLE *
         FROM rbkp <u><b>BYPASSING BUFFER</b></u>
         WHERE belnr = ls_belnr
           AND gjahr = ls_gjahr.

What BYPASSING BUFFER does is that it actually goes to the database and fetches your record where the record is there. The reason why you don't see it with normal SELECT is that, system fetches it from the buffer. In most cases the buffer is updated immediately in human timeframes, but in processing terms, it sometimes is out of sync with the actual database entries.

[ramki_maley]

Srinivas,

IMO, BYPASSING BUFFER will not have any effect since RBKP is not a buffered table.

Cheers,

Ramki.

[Former Member]

Thanks Ramki for correcting me. I didn't verify that fact. I could only explain the behaviour that Peter is seeing using this theory. Other than that the only other possibility is that the updates are really slow.

[christian_wohlfahrt]

Hi,

even if buffering would be active - in this scenario it wouldn't harm: changes by MIR4 are on same server as later the select, so buffer invalidation would be recognized.

Reason for not fetching the changes is based on not enough waiting time: a 2nd commit work will not wait for any update tasks triggered by an earlier commit.

Some alternatives for waiting are needed: lock is an option, also a select for VBHDR (maybe just for VBMANDT, VBUSR, VBDATE > today, VBSTATE) can help, but it is always a little bit tricky to get the right entries.

Regards,

Christian

[Peter_Inotai]

Hi Christian,

Thanks for your help, I'll try your suggestion and see if it helps.

Regards,

Peter