‎2014 May 12 11:31 AM
Hello Experts,
I have an FM where in i am modifying few data in data base . For this i am using modify statement. I have written commit work inside this FM soon after this Modify statement to avoid any possibility of not updating this table. Now this FM is called from many places and there are many update function module which are in stack .
Please provide syantax to use Commit work only for this FM which should not affect the Update function module stack.
BR,
Nikhil Kulkarni
‎2014 May 12 12:42 PM
Hi,
Can't you use the Call function in update task as v1 or v2 .
In this way the other update function modules will not be commited and this will be added to queue.
Regards
Sree
‎2014 May 12 12:48 PM
Hello Sreevisakh,
this is normal Function module which is being called from many places for immegiate execution. This is also configured in few Workflows.
Problem is there is a Commit work statement written inside it for after modify statement to ensure that entry gets succesfully modified in DB.
Now i want to keep this commit work local to this function module only. I.E i dont want to execute the Update function module stack.
SET LOCL , some thing like this, is there any Key word ?
BR,
Nikhil Kulkarni
‎2014 May 12 1:13 PM
Hi Nikhil,
You can start a new LUW with instruction starting new task of call function, inside it you can have your "local" commit.
Like Suhas Saha I don't agree with this type of approach by rule, the update should be dependent on the success of your main process execution. Of course I don't know the process so I admit it might be an exception.
regards,
Edgar
‎2014 May 12 1:18 PM
You can start a new LUW with instruction starting new task of call function, inside it you can have your "local" commit.
But if you trigger an aRFC a database commit will be executed. (Ref. - http://help.sap.com/abapdocu_740/en/abapcall_function_starting.htm)
I don't think this can solve the OP's problem. I would rather suggest a tRFC or a bgRFC. Anyway let's wait for the business logic the OP wants to achieve.
BR,
Suhas
‎2014 May 12 1:33 PM
Sorry, by bad.
I meant
CALL FUNCTION 'Z...' IN BACKGROUND TASK AS SEPARATE UNIT
I usually mistype it.
regards,
Edgar
‎2014 May 12 1:04 PM
Hello Nikhil,
I have written commit work inside this FM soon after this Modify statement to avoid any possibility of not updating this table.
IMO the best way to ensure the integrity of the SAP transaction is to bundle the DB changes of the table(read: in concern) together with other DB updates. This will maintain the "atomicity" of the SAP transaction, i.e., either all or none of the changes are registered in the DB.
Think of the scenario when the SAP transaction fails but your table gets updated, how would you handle it?
Afaik there is no way you can keep the update local to your FM if it is being executed in the same LUW as others. COMMIT will end the current SAP LUW and trigger the bundled DB updates
If you can provide the business logic you are trying to achieve may be the forum can provide some suitable workaround.
BR,
Suhas
‎2014 May 13 7:10 AM
Hi Nikhil,
I am not sure if there is any keywork other than commit work, to make sure whether database updated or not. But if you use commit work it will update the whole LUW.
In some case system need some times to update the database, to make sure database is updated you may use the below logic.
DO 5 TIMES.
**** Write select query to make sure data is there in DB
SELECT xyz FROM abc
INTO TABLE lt_tab
WHERE ( your CONDITION).
IF sy-subrc = 0.
EXIT.
ELSE.
WAIT UP TO 2 SECONDS.
ENDIF.
ENDDO.