Problem solve Get help with specific problems with your technologies, process and projects.

Commit and rollback

Excerpted with permission from Wolfgang G. Propfe's book titled "ABAP with Style."

Excerpted with permission from Wolfgang G. Propfe's book titled "ABAP with Style." To purchase the text, click...

here. The primary reason for a COMMIT WORK is the finalization of a transaction or logical unit of work, whereby the data is actually written to the database. (Note: File operations (at least under UNIX or Windows NT) are not subject to COMMIT WORK-their data persists in case of a crash, if possibly incomplete.) Everything inserted into, changed in or deleted from the database will be lost in case of a program crash. If an ABAP ends normally, the system triggers a COMMIT WORK implicitly, but everyone who experienced a short dump will find that the prior operations on the database are gone unless committed. Some BAPIs, RFCs require an explicit COMMIT WORK, even if they end normally. The ROLLBACK WORK command is the opposite: If an abnormal situation is detected and some records have already been changed it will allow you to 'unprocess' those operations. (Note- it is not really 'unprocessing'. The database operations are not complete, and the ROLLBACK WORK only removes the pending records from the queue of database operations to be performed. Otherwise, there would be a risk of an unsuccessful attempt to 'unprocess' an operation, leaving you with inconsistent data. But for a higher level description, we chose the word to imply some kind on 'Undo'.) In most cases, the average programmer will not even encounter a ROLLBACK WORK, because you should enqueue your work to protect it from others, validate the data up-front, and then the postings should be unproblematic. We would even go so far as to say, that a ROLLBACK WORK from an ABAP programmer could indicate a sloppy program structure, where the database has been updated before all data was checked. (Note: SAP has reasons to use ROLLBACK WORK, bit it is typically behind-the-scenes and should not be necessary for most tasks.) Never insert a COMMIT WORK between the first and last table update inside a program or transaction, if the entries are logically related. The secondary reason for a COMMIT WORK , and from our experience, the more frequently used one, is to prevent a 'TIME OUT' short dump for online programs. SAP even recommends it in the 'How to correct the error' section: If possible, use COMMIT WORK to divide the program into self-contained processing units (the time count is then restarted for each unit). While most programmers catch on to the counter being restarted, some tend to ignore the wording 'self-contained'. In pure display reports, a crash could occur at any time without an impact on the data. But in the middle of processing which includes database changes, the meaning of 'self-contained' must not be overlooked. If the program updates all document headers first and then all items, a COMMIT WORK should not occur between the two operations. If a crash happened after the commit, the headers would be present in the system but the items would not exist. Suppose the program updates one header and all items belonging to it in a loop and the work is committed before the next document is processed, then you are dealing with self contained units. The existence or absence of one document should be independent of another one and therefore the data remains consistent. Be advised though, that you may still have a problem when you need to load the missing documents. Do not use COMMIT WORK in the middle of a SELECT/ENDSELECT statement of while using OPEN/CLOSE CURSOR and FETCH. You may choose to defer some processing until the data is committed (and only execute it in case it does). Note: Use PERFORM...ON COMMIT. There are four things to keep in mind: 1. If the program issues a ROLLBACK WORK, the processing will not take place. 2. You cannot issue COMMIT WORK inside those routines. 3. The execution is carried out when the COMMIT WORK occurs, which is not the time when the PERFORM is issued. This makes for an apparently non-procedural logic flow. The FORMs are processed in the order they were invoked during processing. (Note: An additional level can be specified to modify the sequencing - See F1 help.) 4. The COMMIT WORK needs to be explicit. When a program ends normally the data is written to the database (implicit commit), but the PERFORMS in the commit queue are not executed. Failure to either COMMIT or ROLLBACK while using this technique can therefore cause data inconsistencies.

This was last published in September 2002

Dig Deeper on SAP ABAP



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.