Be Nice Now…..
There are some legitimate cases where you may want to wait a short while in your program for something to happen. One thing I use a wait on is when I have a program running and it encounters a lock. This is ok when you are displaying a single record – you just tell the user that it’s locked. However, if you are compiling an editable ALV grid for example you don’t want to stop them editing some records because one is locked.
What I do is wat a second or so, and try again. If the record is still locked I wait a little longer, before after a certain number of times giving up and continuing on with the next record, flagging the failed record as not locked.
But when you wait are you polite or do you still hog the work process ??
Instead of using the ‘WAIT’ statement use the ‘ENQUE_SLEEP function module. The function module releases the work process for another task to use. The WAIT does not….
Are you sure? I just tested with a test program and checked in SM50 to see if a process is reserved or not.
I see the opposite. Or does this only work in background processing and not dialog?
also why is this function module only used in 1 sap standard report (RPMEN1FI)
I first came across this about 20 years ago and I was struck by the fact that the WP was released. I've tried to find the original documentation for this but I have had no luck unfortunately but I'll keep looking.
I would rather prefer the ENQUE_SLEEP over WAIT as WAIT triggers explicit COMMIT WORK and does Rollout/Rollin for all loaded programs every time it gets executed.
As this help page mentioned: WAIT UNTIL - Application Development on AS ABAP - SAP Library
These would become costly when you wait for 1 seconds for 100 times.
Also, due the COMMIT WORK - Operation on DB, you will not be able to use the WAIT when you are selecting the data using the FETCH NEXT CURSOR as it would be closed after WAIT.
Why not use the wait = abap_true parameter of enqueue function?
Hello Clemens .. It would work if the WAIT for to check lock. If you have to WAIT to see if some other event, like File is moved by another 3rd party app.
It's just teh 'WAIT UNTIL' version that triggers a switch in the WP, but they both cause a commit work.
not a COMMIT WORK but a database COMMIT. COMMIT WORK will also trigger all queued UPDATE tasks, i.e. execution of FUNCTIONs called IN UPDATE TASK or FORMs calls with PERFORM ON COMMIT.
In many cases results may be comparable but frequently it makes a difference.
Every interruption of a process, i.e. screen output (such as messages or dialog screens), every RFC call, every WAIT and every transactions(reports) end will cause a database commit.