‎2010 Jan 21 2:38 PM
Hello Friends,
This is not yet another cross post on commit work. I have a doubt and could not get clear picture in SDN as well as documentation.
There is a general perception that COMMIT WORK must not be used inside user exit .
But how about calling a method from user exit and doing a commit work after performing a series of actions in that method.
Comradely,
K.Sibi
‎2010 Jan 21 2:45 PM
We don't do explicit COMMIT WORK commands in exits, or in any code used in an SAP transaction that updates the database, for one very important reason: COMMIT WORK "flushes" the update queue for the user context, shoving all the queued up updates to the database, regardless of whether or not the SAP transaction has completed all the internal table and structure builds, etc., necessary for a complete, correct database update.
A commit work in a report may be (relatively) harmless, but in an SAP update transaction, one can cause some real damage (but often just causing an abend and rollback and loss of everything the user has just entered) by inserting an explicit commit work or by writing code that results in SAP issuing a commit work at the wrong place or time. Let SAP's update programming control the COMMIT WORK process.
On the other hand, COMMIT WORK (perhaps through the COMMIT BAPI) is sometimes necessary, in cases like:
.... code
transaction or bapi call
..... more code
transaction or bapi call
COMMIT WORK... "need a document number and values just created for next step...
....more code
another transaction or bapi call....etc.
‎2010 Jan 21 2:45 PM
We don't do explicit COMMIT WORK commands in exits, or in any code used in an SAP transaction that updates the database, for one very important reason: COMMIT WORK "flushes" the update queue for the user context, shoving all the queued up updates to the database, regardless of whether or not the SAP transaction has completed all the internal table and structure builds, etc., necessary for a complete, correct database update.
A commit work in a report may be (relatively) harmless, but in an SAP update transaction, one can cause some real damage (but often just causing an abend and rollback and loss of everything the user has just entered) by inserting an explicit commit work or by writing code that results in SAP issuing a commit work at the wrong place or time. Let SAP's update programming control the COMMIT WORK process.
On the other hand, COMMIT WORK (perhaps through the COMMIT BAPI) is sometimes necessary, in cases like:
.... code
transaction or bapi call
..... more code
transaction or bapi call
COMMIT WORK... "need a document number and values just created for next step...
....more code
another transaction or bapi call....etc.
‎2010 Jan 21 2:57 PM
HI a transaction flow must adhere to its ACID properties.
Atomicity,Consistency,.......
The ACID properties of a DBMS allow safe sharing of data
and also you may be aware of the states of transaction
like start,rollback,commit,abort......
In the transaction flow diagram the commit state comes at last.
Just think if you give a commit work in between the flow and if the data gets replicated in db
and if the transaction gets aborted after the exit, does this make any sense.
In the transactional states the rollback state always comes before commit state.
Its not possible to roll back after a commit state.
You can get these details in any of the RDBMS books available.
As far as i knoe Its not recommended to give a commit in between a transactional flow( ex:in bapi,exits,badi etc )
Forum members : please correct me if im wrong.
‎2010 Jan 22 4:46 AM
Hi dave and keshav,
Thanks for your valuable reply .
I would explain the scenario in more detail.
I am writing a FM to update the status of the IDOC using' IDOC_STATUS_WRITE_TO_DATABASE' , since its not reflecting without a commit work , I am have added it .
Another thing is that i am using MODIFY custom database table based on some values of processing and even though the sy-subrc is returned as 0 and there is no change in the table , i was forced to use a commit work.
If there are any other alternative , please let me know .
Comradely ,
K.Sibi
‎2010 Jan 22 4:55 AM
Hi,
Make your FM as RFC enabled and call the FM using BACKGROUND TASK addition. This make sures that your IDOC and Z-table won't be updated in case of transaction is not saved because of some errors. Else even if your transaction is not saved, IDOC and Z-table will be updated which is not a correct way i feel.
You can try by calling the FM in UPDATE TASK as well. (Make the FM as UPDATE Module in attributes).
Thanks,
Vinod.
‎2010 Jan 22 5:10 AM
Hello Vinod,
Sorry for the inconvenience , its not a FM which i am writing .
Its a method .
Comraely ,
K.Sibi
‎2010 Jan 22 5:18 AM
Hi,
No problem. Create a new Z-FM with the same interface and call your method inside the Z-FM.
Thanks,
Vinod.
‎2010 Jan 22 5:26 AM
Try using the additin IN UPDATE TASK for the function module ...!