Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

commit work

Former Member
0 Likes
2,049

hi to all sdn people pls tell

how to use the commit work statement ia abap programs?

and one more doubt

while we r creating the screen we are giving screen attributes like screenumber ,screen type ,description .

then what is the use of screen attribute "next screen".

what will happen if we give zero in next screen.

4 REPLIES 4
Read only

abdul_hakim
Active Contributor
0 Likes
1,199

Hi Hari,

After performing the database updates(SAP LUW) You could use the ABAP Statement COMMIT WORK to confirm your database updates..

If you give zero in the next screen the screen sequence will end after your screen has been processed..ie control passed back to the next statement after CALL SCREEN <screen number>.

Cheers,

Hakim

Mark all useful answers...

Read only

Former Member
0 Likes
1,199

Hi Hari,

COMMIT WORK is used to commit the changes to the database

this will be used when we are updating records to database using a BAPI or some other method.

Even if you give Next page as 0, you can handle with code in PAI, such that from first screen it mavigates to the next page .but it is a good practice to give the next page as NEXT PAGE.

Reward Points if useful

regards

Anji

Read only

Former Member
0 Likes
1,199

Hi,

COMMIT WORK.

Executes a database commit and thus closes a logical processing unit or Logical Unit of Work ( LUW ) (see also Transaction processing ). This means that

  • all database changes are made irrevocable and cannot be reversed with ROLLBACK WORK and

  • all database locks are released.

COMMIT WORK also

  • calls the subroutines specified by PERFORM ... ON COMMIT * executes asynchronously any update requests (see CALL FUNCTION ... IN UPDATE TASK ) specified in these subroutines or started just before,

  • processes the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK ,

  • cancels all existing locks (see SAP locking concept ) if no update requests exist,

  • closes all open database cursors (see OPEN CURSOR ) and

  • resets the time slice counter to 0.

COMMIT WORK belongs to the Open SQL command set.

Return code value

The SY-SUBRC is set to 0.

Also check this info.

This statement will apply any outstanding database updates and wait until they have actually been put on the database before proceeding to the next statement.

An ordinary commit work will initiate the process to update the databases in a separate task and will press on in your abap.

COMMIT WORK: ( Asynchronous)

Your program does not wait for any acknowledgement. it just start executing the next statment after COMMIT WORK.

From SAP HELP :

COMMIT WORK

This is the standard form, which specifies asynchronous processing. Your program does not wait for the requested functions to finish processing.

COMMIT WORK AND WAIT

This form specifies synchronous processing. The commit statement waits for the requested functions to finish processing. Control returns to your program after all high priority (V1) function modules have run successfully.

The AND WAIT form is convenient for switching old programs to synchronous processing without having to re-write the code. Functionally, using AND WAIT for update-task updates is just the same as dialog-task updates with PERFORM ON COMMIT.

Commit work means suppose if u want to update all the changes up to certain level to DB then u can explicitly use this statement. If any thing will wrong automatically roll back will be takes place, means all the updations will be roll back.

Please refer to following links for commit work.

http://www.sap-img.com/fu018.htm

http://help.sap.com/saphelp_nw04/helpdata/en/d2/7849b8bec911d4b2e80050dadfb92b/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/content.htm

http://sap.ittoolbox.com/groups/technical-functional/sap-r3-dev/commit-work-and-rollback-work-871915

http://www.sapgenie.com/abap/fieldexits.htm

Regards,

Santosh

Read only

Former Member
0 Likes
1,199

<b>COMMIT</b>

Variants:

1. COMMIT WORK.

2. COMMIT CONNECTION con.

Effect

Executes a database commit and thus closes a Logical Unit of Work ( LUW) (see also Transaction Processing). This means that:

All database updates are made irrevocable and cannot be reversed with ROLLBACK WORK

All database locks are released.

COMMIT WORK belongs to the Open-SQL command set.

Variant 1

COMMIT WORK.

Addition:

... AND WAIT

Effect

COMMIT WORK also

Calls the subroutines specified by PERFORM ... ON COMMIT

Executes asynchronously any update requests (see CALL FUNCTION ... IN UPDATE TASK) specified in these subroutines or started just before

Processes the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK

Resets the time slice counter to 0.

Ensures that the locks of the SAP locking concept are handled in accordance with its SCOPE Parameter.

Executes a database commit on all database connections

Closes all open database cursors (OPEN CURSOR) on all database connections

Releases all database locks on all database connections

After the COMMIT WORK has been executed, the event RAISE_TRANSACTION_FINISHED of the class CL_SYSTEM_TRANSACTION_STATE with parameter value CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK is triggered. However, this does not apply to the COMMIT WORK at the end of the update.

The Return Code SY-SUBRC is set to 0.

Notes

All subroutines called with PERFORM ... ON COMMIT are processed in the LUW concluded by the COMMIT WORK command. All V1 update requests specified in CALL FUNCTION ... IN UPDATE TASK are also executed in one LUW. When all V1 update requests have been successfully concluded, the V2 update requests (update with start delayed ) are processed, each in one LUW. Parallel to this, the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK are each executed in one LUW per destination.

COMMIT WORK commands processed within CALL DIALOG processing do all of the following:

- A database commit on all database connections (see above),

- Close all open database cursors on all database connections

- Reset the time slice counter

- Call the function modules registered in CALL DIALOG processing using CALL FUNCTION IN BACKGROUND TASK

However, subroutines and function modules called with PERFORM ... ON COMMIT or CALL FUNCTION ... IN UPDATE TASK in CALL DIALOG processing are not executed in the calling transaction until a COMMIT WORK occurs.

Since COMMIT WORK closes all open database cursors, any attempt to continue a SELECT loop after a COMMIT WORKresults in a runtime error. For the same reason, a FETCH after a COMMIT WORK on the now closed cursors also produces a runtime error. You must therefore ensure that any open cursors are no longer used after the COMMIT WORK.

COMMIT WORK may not be used during the update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs that were registered using PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.

With batch input and CALL TRANSACTION ... USING, COMMIT WORK successfully concludes the processing.

Addition

... AND WAIT

Effect

The addition ... AND WAIT makes the program wait for the type V1 update (update with immediate start) to be executed.

The Return Code is set as follows:

SY-SUBRC = 0:

The update was performed successfully.

SY-SUBRC <> 0:

The update was not performed successfully.

Variant 2

COMMIT CONNECTION con.

Effect

The COMMIT command is not executed on the standard database, but only on the secondary database connection specified with con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection as ABAP Source Code.

On the specified secondary database connection, the database commit:

Closes all open database cursors (OPEN CURSOR)

Releases all database locks

Note

Because all open database cursors are closed with the COMMIT, the attempt to continue a SELECT loop after a COMMIT causes a runtime error. For the same reason, a FETCH after the COMMIT to the now closed cursor causes runtime error. You must ensure that open cursors are no longer used after the COMMIT. The only exception are cursors that were opened using the WITH HOLD addition.